Groundwork for optional PEAP certificates FreeRADIUS support

gistfile1.txt

This document is to feel around the edges of adding support for
ad-hoc certificate handling and extended invalid
certificate handling when using EAP-PEAP-* methods

Current state of affairs:

AFAIK only one client supplicant that can claim any level of market share,
wpa_supplicant, currently supports configuring EAP-PEAP 802.1x
authentication to both use an inner method such as MSCHAPc2 and also
at the same time provide a client certificate.  Note that this does not
apply to Andriod systems where UI restrictions prevent responsible
security setup, and even in the case of Linux, GUI tools do not allow
setting these options... they must be configured currently through
directly altering wpa_supplicant configuration files.

FreeRADIUS already supports mixed certificate use with PEAP (some
clients presenting client certificates, some not) if there is a means
available to decide which hosts and/or usernames should present a certificate
and which hosts/users should not be asked for one.  This is controlled
dynamically via unlang policy with the EAP-TLS-Require-Client-Cert attribute
in the "control" attribute set.  However, as currently implemented FreeRADIUS
can only require a valid certificate, or not ask for a certificate... there is
no middle ground.

OpenSSL, used in server mode by FreeRADIUS to handle PEAP tunnel setup, allows
for a hybrid mode where a certificate is requested, but if none is provided the
connection proceeds anyway.  Whether to ask for a certificate is controlled by the
SSL_VERIFY_CLIENT flag and whether to fail if no certificate is offered is
controlled separately by the SSL_VERIFY_FAIL_IF_NO_PEER_CERT.

FreeRADIUS supports running external commands for certificate validation,
recommending the OpenSSL "verify" commandline tool.  This tool, in turn,
supports a continue-on-error model where validation continues to run even
after encountering a deal-breaking condition.  This allows user-visibility of
multiple problems in a certificate, rather than only reporting the first
problem encountered... the same approach used in many modern compiler UIs.
This is very beneficial for the purposes of this proposal.

Goal:

Increase policy flexibility in mixed cert/certless PEAP environments.  Allow
service providers to accept hosts with no certificate or certificate problems
and then use unlang policy to direct such hosts to self-remediation servers, or
otherwise arbitrate their access privileges, rather than simply rejecting
connections from these hosts.

Use case:

In environments where users have a high degree of control over their own
machines (they are allowed to upgrade, multiboot, and configure them as they
please) and where help desk staff is limited, ensuring that the majorty of
systems on the network have their wireless profiles configured as securely as
possible for any given OS/supplicant and minimum NAC requirements have been
met in the common, non-pathological case requires users to self-remediate.
Such self-remediation must be easily accessible (e.g. through a web captive
portal) and in some cases should not require a resident agent, as users are
more reluctant to install a service than run a one-time assessment.  Problems
with resident agents or third-party supplicants may cause users to seek out
insecure workarounds.

Note that highly secured environments do not have these issues as all machines
are joined to a domain or MDM and users do not have administrative privileges
on "their" machines.

Use of a client side certificate for machine-level NAC can be used to decouple
user identities from machine identities where multiple users may use a single
machine, or to independently assess multiple operating systems running on
the same host either concurrently, or in a multi-boot scenario.

Again, in a fully managed environment, this can be acheived through
central domain administration facilities.  When operating outside this paradigm,
however, less secure mechanisms such as relying on completely unauthenticated
CSID are often employed.

Without a client-side certificate NAC enforcement in remote VPN scenarios
requires complicated workarounds, because there is no MAC-address-based CSID
offered in these cases.  Encoding the CSID in a certificate allows use of a MAC
address to be secured barring theft of the certificate.  Retaining user passwords
or other inner method rather than relying entirely on certificates increases the
number of authentication factors (which can be leveraged as security benefit,
though it can also be a liability due to insistence by users for SSO between
wireless access and privileges for other services.)

The inability of most commodity operating systems to use client certificates
with PEAP has acted as a barrier for adoption of the practice even on systems
which are fully capable of doing so.  If a gradual phase-in of this approach
on thise systems where it is supported is to ever occur, we must reduce
any additional barriers.  The current FreeRADIUS implementation efffectively
presents one such barrier, but that can be changed.



Hypothetical policy:

1) All machines that present no certificate are sent to a provisional
access VLAN and/or policy domain.  If a machine is later determined to be
cert-capable by OS fingerprinting mechanisms, the machine is moved to a
remediation VLAN via dynamic authorization (or administrators are alerted,
or whatnot.)  Windows/Apple/Andriod remain in provisional access or
are moved to appropriate VLAN/policy domains as deemed appropriate.

2) Machines that present a certificate that is invalid only because
it has expired are sent to a VLAN/policy domain allowing access only to
SCEP or other automatic enrollment services, such that they may request
a new certificate and perhaps undergo NAC re-assessment.

3) Machines with certificates that have additional problems are quarantined
and administrative alerts are issued.  Note that the ability to view
all problems with a certificate rather than the first cause for failure,
mentioned above, plays a critical role here.

4) Machines with a valid certificate are placed in an appropriate operational
VLAN/policy-domain, perhaps afforded more trust due to their compliance
as attested by the presence of the certificate.

In all cases the inner authentication method must also pass, so no machine
gets any access unless a user presents valid credentials.  Also in cases
2, 3 and 4, attributes in the certificate may be used for policy purposes,
though in case 3, care must be taken about the consequences of trusting
data in an invalid certificate.  In case 2, use of certificate attributes
may merit concern if the certificate is unreasonably old either by
cryptographic measures or general plausibility.

Proposal:

1) Add a control item and tls section directive that allows causes FreeRADIUS
to set SSL_VERIFY_PEER without setting SSL_VERIFY_FAIL_IF_NO_PEER_CERT

2) Add an option to parse output of "openssl verify" and fill out additional
attributes with a list of the failure codes, and one attribute with the
return code, but proceed anyway.  Consider what to require of alternate
commands other than "openssl verify" so that they can mimic this behavior.

3) When the feature in 1) is active, populate TLS-* attributes whether or
not a validation failed, taking care for pathology in the input data.  If no
certificate was offered by the client, leave the attributes empty.

4) Add some sensible unlang policies for anticipated common tasks such
as: checking definitively that no certificate was offered by the client,
checking if the only reason a certificate failed to validate was expiry,
or checking whether the failure reason was due to a revocation, and
convenient textual representations for error codes/causes.

5) Examine the x509 standard extensions and ensure we cover those that
might reasonably be used in new situations we allow into unlang, and
add new TLS-* attribues for them if necessary.

Open questions:

1) Is it possible to access the multi-cause failure information from an
OpenSSL verification without forking and using the CLI utility (efficiency concern)

2) All code paths must be examined by which a cert-less client may fall
through to code expecting a certificate to have been offered by the client.
Consideration for not creating security issues in old configurations made
before this feature add should be exercised, and default configurations
once the feature is activated should error on the safe side.  Based on the
answer to this we may want to restrict use of the new option to only those
cases where an external command is used for verification.