Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

About the Extensible Authentication Protocol

SBR Carrier supports the EAP, an open-ended standard for communication between NADs 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 NADs. When the authentication process is complete, the RADIUS server simply informs the NAD of the result.

SBR Carrier supports several EAP authentication mechanisms, such as TTLS, TLS, PEAP, AKA, and MD5-Challenge. 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 SBR 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 SBR 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 SBR 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 SBR Carrier in selecting the appropriate EAP protocol. If SBR 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.

Note: Given this general flow, a RADIUS request with EAP credentials must incur a minimum of two network round-trips between the NAD or Access Point and the SBR Carrier before reaching a successful conclusion.

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 SBR Carrier.

Table 33: EAP Implementations

EAP-Type

Implemented As

EAP-TTLS

Standalone Authentication Method

EAP-TLS

Standalone Authentication Method

EAP-TLS

Automatic EAP helper

EAP MD5-Challenge

Automatic EAP helper for CHAP

EAP MS-CHAP v2

Automatic EAP helper for MS-CHAP v2 (needed for PEAP)

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. As such, EAP MD5-Challenge can be used only with authentication methods that support CHAP.

Table 34 summarizes the support for MS-CHAP v2 and CHAP in the SBR Carrier authentication methods.

Table 34: MS-CHAP v2 and CHAP Support

Authentication Method

MS-CHAP v2

CHAP

LDAP

Yes, for BindName. (The password must be stored unencrypted or encrypted with enc-md5 by the LDAP server.)

No, for Bind.

Yes, for BindName. (The password must be stored unencrypted or encrypted with enc-md5 by the LDAP server.)

No, for Bind.

Local

Yes

Yes

Proxy RADIUS

Yes

Yes

SQL

Yes, if the password is stored unencrypted or encrypted with enc-md5 by the SQL database

Yes, if the password is stored unencrypted or encrypted with enc-md5 by the SQL database

UNIX User

No

No

UNIX Group

No

No

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 Methods page in Web GUI). Refer to Order of Authentication Methods for information about 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 Methods page.

When SBR 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, SBR 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 credentials to PAP for security reasons. If you are using a third party authentication service 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, SBR 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, SBR 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).

Table 35: Authentication Method Prefetch Capability

Authentication Method

Prefetch Capable?

LDAP

Yes, if using BindName (rather than the Bind option)

Native User

Yes

SQL

Yes, if password does not need to be used as an input parameter in the SQL statement

UNIX User

No

Note: If you enable the lockout facility in SBR Carrier and you use a tunneled authentication method (TTLS or PEAP) with a prefetch-capable method (Native, SQL, or LDAP) and an enabled EAP protocol (MS-CHAPv2, MD5-Challenge, TLS), then you must enable First Handle Via Auto-EAP in that prefetch-capable method to prevent the outer username (anonymous) from being added to the lockout list.

Otherwise, when SBR Carrier receives an authentication request that uses an EAP method that has not been configured, it rejects the user (because the EAP method is not considered to be valid until it is configured) and add the outer username (anonymous) to its lockout list. This locks out all users with an outer authentication name of anonymous until the lockout period expires.

EAP-NAK Notifications

If you are supporting only one type of client or only one EAP protocol, SBR 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, SBR 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 SBR 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, SBR 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, SBR 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 SBR Carrier.

You can configure your choice of Session Timeout settings using standard SBR 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.

Note: Not all access points support the Session-Timeout attribute. Check the specifications for your access points to determine whether this configuration must be performed in a fixed manner on the Access Point or whether the Access Point defers to the server.

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 5280 (which made RFC 3280 obsolete), 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: SBR 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, SBR Carrier uses the URI information contained in a client certificate to connect to the certificate’s CDP. SBR Carrier then uses HTTP, LDAP, or a network file system to retrieve the appropriate CRLs. SBR 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, SBR 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 SBR 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 SBR Carrier to accept an expired CRL for a period past its expiration.

    SBR 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, SBR 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 SBR Carrier from making a direct HTTP connection to a CDP. In such cases, you can configure SBR 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.

Modified: 2018-01-11