About the Extensible Authentication Protocol
Steel-Belted Radius Carrier supports the Extensible Authentication Protocol (EAP), an open-ended standard for communication between network access devices and servers that provides for future extensibility of authentication protocols.
EAP allows specialized knowledge about authentication protocols to be taken out of a NAD so that it acts solely as a conduit between the authentication server and client. This means that new types of authentication can be supported by adding the appropriate functionality to server and client, without any changes to PPP or network access devices. When the authentication process is complete, the RADIUS server simply informs the NAD of the result.
Steel-Belted Radius Carrier supports several EAP authentication mechanisms, such as TTLS, TLS, PEAP, LEAP, AKA, MD5-Challenge, and Generic Token. Support for EAP has been designed to anticipate other authentication types as they become available.
For technical details about EAP, see RFC 2284, PPP Extensible Authentication Protocol (EAP), and RFC 2869, RADIUS Extensions.
Handling EAP Requests
The flow of RADIUS packets in an EAP environment is quite different from the transactions using standard user credentials (for example, PAP or CHAP).
Standard user credentials involve the transmission of a RADIUS request from the NAD to Steel-Belted Radius Carrier and a response (either an Accept or Reject) from the server back to the NAD.
With EAP, the first packet sent from the NAD to Steel-Belted Radius Carrier contains an EAP-Message attribute containing an EAP Identity Response. This is a signal sent by the system being authenticated that it wants to be authenticated by means of EAP. It is now up to Steel-Belted Radius Carrier to select the EAP protocol with which it is to authenticate the end user.
The contents of the User-Name attribute is the only guideline available to Steel-Belted Radius Carrier in selecting the appropriate EAP protocol. If Steel-Belted Radius Carrier selects an EAP protocol that is not supported by the client, the client has the opportunity to send an EAP-NAK, and to request a specific alternate protocol.
Automatic EAP Helpers
Automatic EAP helpers serve as intermediaries between EAP and traditional authentication methods. These helper modules may be configured (using an associated .eap file) to work with existing authentication methods to shield the authentication methods from the particulars of the selected EAP protocol.
Table 33 indicates whether each EAP type is implemented as an EAP helper or as an authentication method in Steel-Belted Radius Carrier.
Whether an automatic EAP helper can be used in conjunction with a specific authentication method depends on what types of credentials the authentication method supports.
The automatic EAP helper that implements EAP MD5-Challenge generates CHAP credentials, while the helper that implements LEAP generates MS-CHAP v2 credentials. As such, EAP MD5-Challenge can be used only with authentication methods that support CHAP, and LEAP can be used only with authentication methods that support MS-CHAP v2.
Table 34 summarizes the support for MS-CHAP v2 and CHAP in the Steel-Belted Radius Carrier authentication methods.
Authentication Request Routing
The order in which authentication methods and automatic EAP helpers are called to handle an authentication request depends on two factors:
- The ordered list of enabled authentication methods (viewable in the Authentication Policies panel in SBR Administrator). Refer to Order of Authentication Methods184 for information on defining the order of authentication methods for an authentication policy.
- The EAP-related configuration for each of the enabled authentication methods in the eap.ini file, which you configure from the Authentication Policies panel.
When Steel-Belted Radius Carrier receives an authentication request that does not contain EAP credentials, it passes the request to each enabled authentication method until one of the methods claims the request.
The EAP settings in the eap.ini file come into play only when a request with EAP credentials is received. An authentication request contains EAP credentials if it includes one or more EAP-Message attributes and contains no other form of user credentials (for example, User-Password).
EAP-Only Setting
When an authentication method's EAP-Only setting is 1, Steel-Belted Radius Carrier prevents the authentication method from being called for any request that does not contain EAP credentials. Under this setting, the authentication method is also bypassed if an authentication request specifically requests an EAP protocol that is not listed in the authentication method's EAP-Type list in the eap.ini file.
 |
NOTE: The PEAP authentication method plug-in converts the inner EAP/Generic Token credentials to PAP for security reasons. If you are using SecurID with PEAP, set the EAP-Only setting to 0. |
First-Handle-Via-Auto-EAP Setting
If your configuration involves clients using more than one EAP protocol, Steel-Belted Radius Carrier must select an initial EAP protocol with which to proceed when receiving an authentication request with EAP credentials.
Selecting the incorrect EAP protocol is not fatal; the client simply sends an EAP- NAK in response to the server's selected protocol and suggests an alternate one. After one additional network round-trip, the correct EAP protocol becomes active.
Depending on the capabilities of the authentication methods being used, you may be able to cut out this additional network round-trip that affects a portion of your EAP-based authentication requests.
If an authentication method can check for the existence of a user and can retrieve the user's password information with only the information available in the authentication request (for example, the username), it is said to be prefetch-capable. A prefetch-capable authentication method (Table 35) can determine whether a user exists in its database before committing to a specific EAP protocol.
If your authentication method is prefetch-capable, set First-Handle-Via-Auto-EAP to 0, indicating that the authentication method has the first chance to handle the request. Also set First-Handle-Via-Auto-EAP to 0 if the authentication method can handle EAP credentials directly, without an automatic helper EAP method.
By configuring the authentication method to be called first, Steel-Belted Radius Carrier can delay selection of an EAP protocol until it has ascertained whether the user exists in a particular authentication method's database. This is a useful technique when you plan to use more than one EAP protocol, but you do not know which one the client wants. Even in this scenario, automatic EAP helpers may still end up performing the EAP protocol processing; they take over after the authentication method has retrieved a user's password information, rather than before.
The goal of an automatic EAP helper is to generate credentials against which traditional authentication methods (ones that do not understand EAP) can operate. After an automatic EAP helper has generated these credentials, the authentication method that triggered the use of the helper is checked first for a password/credential match. If a match is not present, the same traditional credentials are passed to all remaining enabled authentication methods in the master list (in the order in which they appear in the list).
Yes, if password does not need to be used as an input parameter in the SQL statement |
|
EAP-NAK Notifications
If you are supporting only one type of client or only one EAP protocol, Steel-Belted Radius Carrier selects that EAP protocol for all EAP-based authentication requests it receives. If you are planning to support multiple EAP protocols and do not intend to maintain databases that track the appropriate EAP protocol on a user-by-user basis, Steel-Belted Radius Carrier automatically selects the appropriate EAP protocol for you.
When multiple EAP protocols are in play, configure each authentication method you plan to use with all the EAP protocols that may be used with it. In this configuration, when Steel-Belted Radius Carrier receives an authentication request containing EAP information, it chooses the first EAP protocol listed for the first authentication method that claims the request. If the client requires a different EAP protocol, it sends back an EAP-NAK that specifies the EAP protocol it wants to use.
After receiving an EAP-NAK, Steel-Belted Radius Carrier performs a scan of the authentication methods, in search of the first authentication method that has the requested EAP protocol listed (the authentication method may support this EAP protocol directly or with the help of an automatic EAP helper).
If the requested EAP protocol does not appear in any of the authentication methods' lists of supported EAP protocols, Steel-Belted Radius Carrier rejects the authentication request.
Reauthenticating Connections
Most access points understand only a limited number of attributes that may be included in a RADIUS response to signal that the user has been accepted. The Session-Timeout attribute is of particular significance in a WLAN realm because it instructs the Access Point how long the user can remain connected to a WLAN before having to reauthenticate with Steel-Belted Radius Carrier.
You can configure your choice of Session-Timeout settings using standard Steel-Belted Radius Carrier reply-list items on a user-by-user basis. If you are using EAP-TLS or EAP-TTLS to authenticate users, you can also have these plug-ins automatically generate Session-Timeout attributes based on policies set in their configuration files. This level of control is necessary for EAP-TLS and EAP-TTLS as these plug-ins also support session resumption, a quicker method of reauthenticating users. The value in the Session-Timeout attribute may need to be dynamically calculated in these cases.
Certificates
A certificate is an electronic data structure used to identify an individual, a server, a company, or some other entity, and to associate that identity with a public key and an associated private key. Like a passport, a certificate provides generally recognized proof of an entity's identity. Certificates bind public key values to entities, so that remote users of an entity's public key can be certain the associated private key is owned by the correct person or system. Certificates help prevent the use of fake public keys for impersonation. Only the public key certified by the certificate works with the corresponding private key possessed by the entity identified by the certificate. The most widely accepted format for certificates is defined by the ITU-T X.509 international standard, which is described in RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
Certificate authorities (CAs) are entities that validate identities and issue certificates. An organization that wants to serve as its own CA can issue its own certificates, or an organization can purchase certificates from a trusted third-party CA. The methods used to validate an identity vary depending on the policies of a given CA. In general, before issuing a certificate, a CA must verify the identity of the entity and must digitally sign the certificate to ensure it cannot be modified. This ensures that a certificate issued by a CA binds a particular public key to the name of the entity the certificate identifies (such as the name of an employee).
In addition to a public key, a certificate includes the name of the entity it identifies, an expiration date, the name and URI of the CA that issued the certificate, a serial number, and the digital signature of the issuing CA, which creates a mathematical relationship between the signing CA certificate's public key and the public key of the certificate it signs. The CA's digital signature allows the certificate to function as a letter of introduction for users who know and trust the CA but do not know the entity identified by the certificate.
Because a certificate's expiration date is part of its signed contents, remote entities can verify that a certificate is valid and current.
Common types of certificates include the following:
- Certificate Authority certificates can sign other certificates.
- Server certificates are used on a server to enable a software client to verify the validity of the connection to a machine and to create an encrypted channel between a client and a server.
- Client certificates enable a server to verify a client's identity (certificate-based authentication) and to enable a user to digitally sign or encrypt data. Client certificates, which are digitally signed by a trusted certificate authority, are stronger proof of a client's identity than username/password credentials alone.
NOTE: Steel-Belted Radius Carrier does not support Digital Signature Algorithm (DSA) type certificates.
Certificate Chains
A certificate chain is a sequence of certificates, where each certificate in the chain is signed by the certificate above it in the chain. At the top of the chain is a self-signed certificate. Each CA in the chain vouches for the identity in the entity to which it issues a signed digital certificate. Certificate chains establish a chain of trust; if you trust the CA at the top of the chain, this implies you can trust the signed certificates below it in the chain.
Certificate Revocation Lists
Under normal circumstances, a certificate remains valid until it reaches its expiration date. However, a certificate may become invalid before it expires. For example, if an employee whose identity is bound to a certificate terminates employment or if an enterprise suspects the confidentiality of the private key associated with a certificate's public key has been compromised, the certificate might be declared invalid and revoked before its expiration date.
When a CA revokes a certificate, it must let other entities know the certificate is no longer valid and should not be accepted. A certificate revocation list (CRL) is a signed data structure that identifies the serial numbers of certificates that have been issued and subsequently revoked by the CA. When a remote entity is asked to use a certificate to verify a remote user's identity, it can download a current copy of the applicable CRL from a CRL distribution point (CDP) and confirm that the certificate's serial number is not present. If a CRL has expired, the entity must connect to the CDP to download a new revocation list.
CRLs can be issued by a CA periodically (hourly, daily, or weekly) or as needed. When a certificate is revoked, its serial number is listed in the CRL, and that serial number remains on the CRL at least one period after the certificate's expiration date. CRLs, like certificates, can be distributed by untrusted servers and untrusted communications.
Under some circumstances, latency (the time between when a certificate is revoked and when the certificate's serial number appears on the CRL of the issuing CA) may be a concern. For example, if a revocation is reported today, certificate-using systems are not reliably notified until all currently issued CRLs are updated, which may take hours, days, or even weeks. Online revocation checking can reduce the latency between a revocation report and the distribution of the information to relying parties.
If CRL checking is enabled, Steel-Belted Radius Carrier uses the URI information contained in a client certificate to connect to the certificate's CDP. Steel-Belted Radius Carrier then uses HTTP, LDAP, or a network file system to retrieve the appropriate CRLs. Steel-Belted Radius Carrier stores these retrieved CRLs in the CRLCache directory under the radiusdir server directory.
When a client certificate is presented during EAP-TLS or EAP-TTLS authentication, Steel-Belted Radius Carrier can evaluate the client's certificate chain against its set of stored CRLs to verify none of the certificates in the chain have been revoked.
You can configure the following settings for CRL checking:
- Static CDPs—A static CDP is a CDP whose address (URI) is specified in the [Static_CDPs] section of a TLS or TTLS initialization file.
- CRL expiration—The CRL checking feature can be configured to operate in strict or lax mode.
- In strict mode, a cached CRL that has expired is immediately discarded; if Steel-Belted Radius Carrier cannot acquire a new CRL in the allotted time during a CRL check on a chain, the user is rejected.
- In lax mode, you can configure Steel-Belted Radius Carrier to accept an expired CRL for a a period past its expiration.
Steel-Belted Radius Carrier attempts to obtain a current CRL whether it is running in strict or lax mode.
- Missing CDP attribute—When a CRL check is performed on a certificate chain, Steel-Belted Radius Carrier reads the contents of the CDP attribute for each certificate past the root certificate and uses the CDP information to retrieve the appropriate CRL. If a non-root certificate in the chain does not contain a CDP attribute, no CRL checking is performed for that certificate. You can configure EAP-TLS to reject the user if it encounters a non-root certificate that is missing a CDP attribute.
- Incomplete LDAP CDP—Some CAs may create certificates that contain an LDAP-style CDP (//ldap:\\...) that does not specify the identity of the LDAP server to be queried. You can designate a default LDAP server be used when such CDPs are encountered. If you do not designate a default LDAP server and an LDAP-style CDP is encountered, the CRL retrieval fails.
- HTTP proxies for CRL checking—Network security policy may prevent Steel-Belted Radius Carrier from making a direct HTTP connection to a CDP. In such cases, you can configure Steel-Belted Radius Carrier to download CRLs through an HTTP proxy server on its local network. Optionally, you can specify the hosts or domains that do not require an HTTP proxy.
- CRL cache flushing—You can flush the CRL caches used for EAP-TLS and EAP-TTLS authentication at any time.
