User Guide for the Cisco Secure Access Control System 5.0
Authentication in ACS 5.0
Downloads: This chapterpdf (PDF - 420.0KB) The complete bookPDF (PDF - 12.93MB) | Feedback

Authentication in ACS 5.0

Table Of Contents

Authentication in ACS 5.0

PAP

RADIUS PAP Authentication

EAP

EAP-MD5

Overview of EAP-MD5

EAP- MD5 Flow in ACS 5.0

EAP-TLS

Overview of EAP-TLS

User Certificate Authentication

PKI Authentication

PKI Credentials

PKI Usage

Fixed Management Certificates

Importing Trust Certificates

Acquiring Local Certificates

Importing the ACS Server Certificate

Initial Self-Signed Certificate Generation

Certificate Generation

Exporting Credentials

Credentials Distribution

Hardware Replacement and Certificates

Securing the Cryptographic Sensitive Material

Private Keys and Passwords Backup

EAP-TLS Flow in ACS 5.0

PEAPv0v1

Overview of PEAP

Supported PEAP Features

Server Authenticated and Unauthenticated Tunnel Establishment Modes

Fast Reconnect

Session Resume

Protected Exchange of Arbitrary Parameters

PEAP Flow in ACS 5.0

Creating the TLS Channel

Authenticating with MS-CHAPv2

EAP-FAST

Overview of EAP-FAST

EAP-FAST Benefits

EAP-FAST in ACS 5.0

About Master-Keys

About PACs

Provisioning Modes

Types of PACs

ACS Supported Features for PACs

Master Key Generation and PAC TTLs

EAP-FAST Flow in ACS 5.0.

EAP-FAST PAC Management

Key Distribution Algorithm

EAP-FAST PAC-Opaque Packing and Unpacking

Revocation Method

PAC Migration from ACS 4.x

EAP-MSCHAPv2

Overview of EAP-MSCHAPv2

MSCHAPv2 for User Authentication

MSCHAPv2 for Change Password

Windows Machine Authentication Against AD

EAP- MSCHAPv2 Flow in ACS 5.0

Certificate Attributes

Certificate Binary Comparison

Rules Relating to Textual Attributes

Certificate Revocation

Machine Authentication

Authentication Protocol and Identity Store Compatibility

Passwords


Authentication in ACS 5.0


This section contains the following topics:

PAP

EAP

EAP-MD5

EAP-TLS

PEAPv0v1

EAP-FAST

EAP-MSCHAPv2

Certificate Attributes

Machine Authentication

Authentication Protocol and Identity Store Compatibility

PAP

The Password Authentication Protocol (PAP) provides a simple method for a user to establish its identity by using a two-way handshake. The PAP password is encrypted with the shared secret and is the least sophisticated authentication protocol.

ACS checks the ID-Password pair against the external database, Identity Store, until ACS acknowledges the authentication or terminates the connection.

PAP is not a strong authentication method since it offers little protection from repeated trial-and-error attacks.


Note The RADIUS with PAP authentication flow includes logging of passed and failed attempts.


RADIUS PAP Authentication

You can use different levels of security concurrently with ACS for different requirements. PAP applies a two-way handshaking procedure. If authentication succeeds, ACS returns an acknowledgement; otherwise, ACS terminates the connection or gives the originator another chance.

The originator is in total control of the frequency and timing of the attempts. Therefore, any server that can use a stronger authentication method will offer to negotiate that method prior to PAP. RFC 1334 defines PAP.

Figure B-1 illustrates RADIUS with PAP authentication.

Figure B-1 RADIUS with PAP Authentication Use Case

1

A host connects to the network. Any communication protocol may be used depending on the host.

3

ACS uses an external identity store to validate the user's credentials.

2

The network device sends a RADIUS access request to ACS.

4

The RADIUS response (access-accept or access-reject) is sent to the network device that will apply the decision.


EAP

Extensible Authentication Protocol (EAP) is an authentication framework for wireless networks and point-to-point connections. EAP supports multiple authentication methods, and provides common functions and rules for negotiation of the desired authentication method:

Server authentication request

Client authentication response

Server success authentication result

Server failure authentication result

Silent discard of client packets if they do not meet integrity and security conditions

Rules for server-initiated EAP method negotiation

Message sequencing, and tracking responses to requests

Retransmit

EAP is a lock-step protocol; after the initial request, ACS cannot send a new request before receiving a valid response from the client.

In ACS 5.0, EAP is encapsulated in the RADIUS protocol. Incoming and outgoing EAP messages are stored in a RADIUS EAP-Message attribute (79). A single RADIUS packet can contain multiple EAP-Message attributes when the size of a particular EAP message is greater than the maximum RADIUS attribute data size (253 bytes). The RADIUS State attribute (24) stores the current EAP session reference information, and ACS stores the actual EAP session data.

The EAP standard is described in:

RFC 3748—Extensible Authentication Protocol (EAP).

RFC 3579—RADIUS Support For Extensible Authentication Protocol (EAP).

In the EAP process:

1. The network device sends an EAP request to a host when the host connects to the network.

2. The host sends an EAP response to the network device; the network device embeds the EAP packet that it received from the host into a RADIUS request and sends it to ACS, which is acting as the EAP server.

3. ACS negotiates the EAP method for authentication. The client can acknowledge the EAP method that the EAP server suggests or, it can respond with a negative acknowledgment (NAK) and suggest a list of alternative EAP methods. The server and client must reach agreement about the EAP method to use to instantiate authentication.

Table B-1 lists the EAP codes for each type of EAP message.

Table B-1 EAP Codes

EAP message type
EAP code

Accept-request

1

Response

2

Success

3

Failure

4


Table B-2 describes the EAP methods that ACS 5.0 supports.

Table B-2 Supported EAP methods

EAP Method
Description

EAP-TLS

Extensible Authentication Protocol-Transport Layer Security. For more information, see Exporting Credentials.

EAP-MSCHAPv2

Microsoft Challenge Handshake Authentication Protocol version 2. For more information see EAP-MSCHAPv2

EAP-MD5

Message Digest 5 Protocol. For more information see EAP-MD5.

PEAPv0v1

Protected Extensible Authentication Protocol version 0 and version 1. For more information see PEAPv0v1

EAP-FAST

EAP Flexible Authentication via Secured Tunnel (EAP-FAST) protocol. For more information see EAP-FAST.


ACS supports full EAP infrastructure, including EAP type negotiation, message sequencing and message retransmission. All protocols support fragmentation of big messages.

In ACS 5.0, you configure EAP methods for authentication as part of access service configuration. For more information about access services, see Chapter 3, "ACS 5.0 Policy Model."

EAP-MD5

This section contains the following topics:

Overview of EAP-MD5

EAP- MD5 Flow in ACS 5.0

Overview of EAP-MD5

EAP Message Digest 5-(EAP-MD5) provides one-way client authentication. The server sends the client a random challenge. The client proves its identity by hashing the challenge and its password with MD5. Because a man in the middle could see the challenge and response, EAP-MD5 is vulnerable to dictionary attack when used over an open medium. Since no server authentication occurs, it is also vulnerable to spoofing.

Related Topics

Host Lookup, page 4-10

Overview of Agentless Network Access, page 4-9

EAP- MD5 Flow in ACS 5.0

ACS supports EAP-MD5 authentication against the ACS internal identity store. Host Lookup is also supported when using the EAP-MD5 protocol. See Host Lookup, page 4-10.

Related Topics

Authentication Protocol and Identity Store Compatibility

Overview of Agentless Network Access, page 4-9

EAP-TLS

This section contains the following topics:

Overview of EAP-TLS

EAP-TLS Flow in ACS 5.0

Overview of EAP-TLS

EAP-TLS is one of the methods in the EAP authentication framework, and is based on the 802.1x and EAP architecture. Components involved in the 802.1x and EAP authentication process are the:

Host—The end entity, or end user's machine.

AAA client—The network access point.

Authentication server—ACS.

The EAP-TLS standard is described in:

RFC 2716—PPP EAP-TLS Authentication Protocol

RFC 3079—Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)

This section contains the following topics:

User Certificate Authentication

PKI Authentication

The host must support EAP-TLS authentication. The access point must support the EAP authentication process in the 802.1x environment (the access point is not aware of the EAP authentication protocol type).

Related Topics

Configuring CA Certificates, page 7-27

Certificate-Based Network Access, page 4-6

ACS and NAC RADIUS, page 4-17

EAP-TLS Flow in ACS 5.0

User Certificate Authentication

EAP-TLS is a mutual authentication method for certificate-based authentication; the client and server authenticate each other by using digital certificates. Certificates must meet specific requirements on the server and client for successful authentication. EAP and TLS are Internet Engineering Task Force (IETF) RFC standards. The EAP protocol carries initial authentication information, specifically the encapsulation of EAP over LANs (EAPOL) as established by IEEE 802.1x. TLS uses certificates for user authentication and dynamic ephemeral session key generation.

Once the peer is authenticated and a session is created, the information is cached on ACS for a certain amount of time. The session can be re-established by using the EAP-TLS session resume, without an additional certificate exchange. ACS 5.0 maintains the server certificate and private key in files on the ACS server, which it uses during EAP-TLS processing. You can choose the certificate authorities (CAs) that can be trusted to sign on client certificates.

EAP-TLS authentication involves two elements of trust:

The EAP-TLS negotiation establishes end-user trust by validating, through RSA signature verifications, that the user possesses a keypair that a certificate signs. This process verifies that the end user is the legitimate keyholder for a given digital certificate and the corresponding user identification in the certificate. However, trusting that a user possesses a certificate only provides a username-keypair binding.

Using a third-party signature, usually from a CA, that verifies the information in a certificate. This third-party binding is similar to the real-world equivalent of the stamp on a passport. You trust the passport because you trust the preparation and identity-checking that the particular country's passport office made when creating that passport. You trust digital certificates by installing the root certificate CA signature.

Some situations do not require this second element of trust that is provided by installing the root certificate CA signature. When such external validation of certificate legitimacy is not required, you can use the ACS self-signed certificate capability. Depending on the end-user client involved, the CA certificate for the CA that issued the ACS server certificate is likely to be required in local storage for trusted root CAs on the end-user client computer. For more information, see Adding a Certificate Authority, page 7-28.

EAP-TLS-compliant AAA clients include:

Cisco 802.1x-enabled switch platforms (such as the Catalyst 6500 product line)

Cisco Aironet Wireless solutions

To accomplish secure Cisco Aironet connectivity, EAP-TLS generates a dynamic, per-user, per-connection, unique session key.

Related Topics

Configuring CA Certificates, page 7-27

Certificate-Based Network Access, page 4-6

PKI Authentication

EAP-TLS uses public key infrastructures (PKI) concepts:

A host requires a valid certificate to authenticate to the LAN network.

The AAA server requires a server certificate to validate its identity to the clients.

The certificate-authority-server infrastructure issues certificates to the AAA server(s) and the clients.

An SSL/TLS tunnel authentication is conducted by both peers and is initiated by the client. In ACS, the tunnel can be either authenticated by:

both peers

either one

neither client or host

A tunnel that is constructed without an authentication is considered an anonymous tunnel, and is usually constructed by the Diffie-Hellman key exchange protocol. ACS supports the SSL/TLS session resume feature for TLS. ACS maintains the tunnel keys and cipher used to establish the tunnel communication in the cache for each session. Fetching an old session is based on the session ID which is unique for each client.

You can configure the timeout for each session in the cache, for each protocol individually. The lifetime of a session is measured from the beginning of the conversation and is determined when the TLS session is created.

ACS supports establishment of a tunnel from a commonly shared key known to the client and the server for the EAP-FAST protocol. The key that is securely agreed upon between the two peers is used to derive a shared tunnel TLS-master-key that is used to open a tunnel. This mechanism involves a shorter TLS negotiation.

An anonymous Diffie-Hellman tunnel relates to the establishment of a completely anonymous tunnel between a client and a server for cases where none of the peers authenticates itself. ACS runtime supports anonymous Diffie-Hellman tunnels for EAP-FAST with a predefined prime and a predefined generator of two. There is no server authentication conducted within anonymous Diffie-Hellman tunnel cipher-suites.

An authenticated Diffie-Hellman tunnel is similar to an anonymous Diffie-Hellman tunnel. The additional factor of the authenticated Diffie-Hellman tunnel is that peer authentication is conducted through an RSA certificate. ACS supports Authenticated-Diffie-Hellman tunnels for EAP-FAST where the server authenticates by using its own certificate.

Additional client authentications are conducted within the tunnel by using other protocols such as MSCHAP or TLS.

Related Topics

Configuring Local Server Certificates, page 16-9

Configuring CA Certificates, page 7-27

Configuring Certificate Authentication Profiles, page 7-31

PKI Credentials

This section contains the following topics:

PKI Usage

Fixed Management Certificates

Importing Trust Certificates

Exporting Credentials

PKI Usage

ACS supports using certificates for various PKI use cases. The main use case is the EAP-TLS protocol where the PKI is used to authenticate the client and the server. Other protocols which use the PKI credentials are: LDAP, HTTPS, SSH, SFTP, and GAME over SSL.

For TLS related EAP protocols, a single Local Certificate is used to authenticate the server for all the TLS related EAP protocols. You can pick the certificate to use from any of the certificates containing a private-key in the Local Certificate store.

For other protocols such as HTTPS, SFTP, SSH, GAME over HTTPS, and for the message-bus ActiveMQ authentication, a single certificate should be configured to authenticate ACS. You can pick the certificate to use from any of the certificates containing a private-key in the Local Certificate store. You can configure the same Local Certificate for the TLS related EAP protocols and for HTTPS.

For HTTPS, SFTP, SSH and ActiveMQ, an auto-generated self-signed certificates can be used as the means for server authentication.

Fixed Management Certificates

ACS generates and uses self-signed certificates to identify various management protocols. such as the Web browser, HTTPS, ActiveMQ SSH and SFTP.

Self-signed certificates are generated when ACS is installed and are maintained locally in files outside of the ACS database. These certificates cannot be modified and you cannot export them.

Importing Trust Certificates

ACS supports PEM or DER formatted X509 certificate files. You can add a trust certificate to the trust certificate store. ACS verifies that an imported certificate complies with a the X509 format and does not perform any hierarchical certificate signature verification.

You can mark the acquired certificate for immediate trust for TLS related EAP protocols as the EAP CTL. The trust certificate store does not allow for duplicate trust certificates. These are the rules for rejecting certificates:

Two certificates cannot have the same subject.

Two certificates cannot have the same issuer and the same serial-number.

Acquiring Local Certificates

This topic describes the methods for ACS to acquire PKI credentials, and the ways that you can sets the public or private keys pairs to each ACS server in the ACS domain.

An X509 certificate contains the credentials which include the public key, and a PKCS#12 [?10.1] that holds the private key protected with a password that goes with it.

The ACS domain may have more than a single ACS server; each domain should have its own set of PKI key pairs to identify itself through the appropriate interfaces. Some interfaces may require that the certificate that identifies ACS, contain the IP or FQDN of the ACS server, in its Common Name (CN) for better binding of the certificate to the IP of the server, for example, the HTTPS ACS server certificate which is used for the Web interface. For other interfaces, it may be possible to use a common certificate that can be shared between the servers, however, Cisco does not recommend that you use a common certificate. Each ACS PKI credentials may be obtained either from a self-signed certificate or a certificate signed by a common certificate authority (CA). For protocols that require the ACS identification, clients should be deployed with at least the lowest common certificate that dominates all the ACS servers certificates that are used to identify each ACS.

You can pick the PKI policy to be used in your organization and configure the PKI credentials for the ACS domain.

The configured certificate with its private-key should not be used outside the ACS machine

Related Topics

Importing the ACS Server Certificate

Initial Self-Signed Certificate Generation

Certificate Generation

Importing the ACS Server Certificate

When you manually import and ACS server certificate you must supply the certificate file, the private key file, and the private key password used to decrypt the PKCS#12 private key. The certificate along with its private-key and private-key-password, is added to the Local Certificate store. For non-encrypted private-keys, the user supplied password may be ignored.

ACS supports PEM or DER formatted X509 certificate files. ACS verifies that an imported certificate complies with a the X509 format and does not perform any hierarchical certificate signature verification.

When importing a certificate, you can configure the certificate for protocol that require an ACS server certificate, such as TLS related EAP protocols, and GAME over HTTPS.


Note Only EAP and GAME over HTTPS protocols can be configured in ACS 5.0 for certificate-based authentication.


The input password and private-key, which are cryptographically sensitive information, are passed over the HTTPS channel. Using HTTPS with a non-authenticated server, for example, a self-signed certificate for HTTPS server authentication, is not a secure method of passing this sensitive information.

Importing Trust Certificates

Initial Self-Signed Certificate Generation

Certificate Generation

Initial Self-Signed Certificate Generation

An automatically generated self-signed certificate is placed in the Local Certificate store for each ACS server. This certificate is used to identify ACS for TLS related EAP protocols and for GAME over HTTPS. The self-signed certificate is generated with the CN equal to the machine's host name, as required for HTTPS certificates and is generated when ACS is installed.

Certificate Generation

You an generate ACS server certificates through the Web interface. The output of this process is a certificate or a certificate request and it's corresponding private-key and password. The generated private-key is structured as PKCS#12 encrypted, by using a relatively strong automatically generated password based on at least 128 bit of randomness.

You can pick the generated private-key length, from 512, 1024, 2048 or 4096 bit. The certificate digest algorithm used by the ACS is SHA1.

You must input the certificate subject for the generated certificate or certificate request. ACS uses the common Name (CN) field in the subject. You can set the ACS server's IP address for the CN attributes, to the static IP address or the FQDN address of the server. The reason behind this, is that certificates that authenticate an HTTPS server must include the server's IP address as the CN, which is part of the protected information in that certificate. Other non-mandatory fields that ACS supports for certificate generation are: O, OU, C, L, ST, and E.

There are two types of certificate generation:

Self signing certificate generation — ACS supports generation of an X.509 certificate and a PKCS#12 private key. The pass-phrase used to encrypt the private key in the PKCS#12 automatically generates stronger passwords, and the private-key is hidden in the Local Certificate store. You can select the newly generated certificate for immediate use for GAME over HTTPS, for TLS related EAP protocols, or both.

Certificate request generation—ACS supports generation of a PKCS#10 certificate request with a PKCS#12 private key. The request is downloaded through the Web interface and should be formatted with PEM representation with a REQ extension. The pass-phrase used to encrypt the private key in the PKCS#12 automatically generates stronger passwords, and the private-key is hidden in the ACS database. You can download the request file to be signed offline by the RA. After the RA signs the request, you can install the returned signed certificate on ACS and bind the certificate with its corresponding private key. The binding of certificate and its private key is automatic. After binding the signed certificate with the private key, you can mark this certificate for immediate use for GAME over HTTPS, for TLS related EAP protocols, or both.

Related Topics

Configuring CA Certificates, page 7-27

Configuring Certificate Authentication Profiles, page 7-31

EAP-TLS Flow in ACS 5.0

Exporting Credentials

You can export a general trust certificates, an ACS server certificate with or without private keys, and previously generated certificates requests from the certificate stores. You cannot export the request for a private-key. You can download certificates file with a .CER extension. The file format is not changed from the format that is imported into ACS.

You can download the public certificate as a regular certificate with .CER extension for ACS server certificates, that also contain a private key. The file format is retained.

You can export a public request to re-issue a certificate request to an RA, for certificate-requests. The request is downloaded with an REQ extension and is formatted identically to the format that it was generated by.

Only administrators with the highest administrator privileges can export the certificate private key and its password. A warning about the security implications of such an action is conveyed twice, to approve the export operation. After this double check, the private-key files can be downloaded as a .PVK extension, and the private-key password can be downloaded as a .PWD extension. The private-key file format is retained.

Credentials Distribution

All certificates are kept in the ACS database which is distributed and shared between all ACS nodes. The ACS server certificates are associated and designated for a specific node, which uses that specific certificate.

Public certificates are distributed along with the private keys and the protected private key passwords by using the ACS distributed mechanism. ACS implements a method of protection to prevent a private-key to be used by other servers other than the one to which the private-key is designated to. This protection mechanism applies only to encrypted private-keys.

The PKI policy for private keys is that private keys are not supposed to be usable by other entities which are not associated with the ACS server to which they are designated to. ACS supports cryptographic protection of the private-keys to prevent possible use outside of the ACS server machine to which they are designated to.

Hardware Replacement and Certificates

When hardware fails, a new node is used for replacing a malfunctioning node. The malfunctioning node's certificates are removed from the distributed database of the primary server, and the new node's certificates are then being passed to the primary to be associated with the newly replaced node.

This process of certificate changing is conducted as part of the hardware replacement process when the new node registered to the domain, The certificate distribution is based on the server's IP address.

Securing the Cryptographic Sensitive Material

There are several types of PKI related keys that are stored in the ACS database. These keys have different cryptographic storage requirements that must comply to SEC-RCV-CRED-2 which is part of the Cisco security baseline. These requirements include:

Public keys that usually reside in a certificate may be stored plain open as they are used to pass on the clear text to clients and contain only public keys.

Private-keys must be stored encrypted as PKCS#12 by using a relatively strong password.

The password for the PKCS#12 private-keys must be stored in the ACS database. Since the ACS database is encrypted, this does not pose a serious security concern. ACS 5.0 distributes the entire database between all the ACS servers. ACS encrypts the private-key passwords by using a password that exists only for the machine, thus preventing possible use of the private-keys by other machines. The private-key password key is maintained in /opt/CSCOacs/config/prikeypwd.key on the ACS file-system.

Other certificate repositories such as the tomcat key-store should have the same properties as the ACS database. Private-keys are encrypted by a password that is kept secured in the database.

Private Keys and Passwords Backup

The entire ACS database is distributed and backed-up on the primary ACS along with all the certificates, private-keys and the encrypted private-key-passwords. The private-key-password-key of the primary server is also backed up with the primary's backup.

Other secondary ACS private-key-password-keys are not backed-up. Backups are encrypted and also can pass relatively secured in and out of the ACS servers. The private keys in backups are protected by the PKCS#12 and the backup file encryption. The passwords that are used to open the PKCS#12 private-keys are protected with the backup encryption.

EAP-TLS Flow in ACS 5.0

An EAP-TLS server exchanges data with a client by using packets based on the EAP request and response packets; the packets are extended by specific EAP-TLS data. ACS acts as the EAP-TLS server, and uses the Open Secure Sockets Layer (OpenSSL) library to process the TLS conversation. The ACS EAP-TLS server produces 128-bit MPPE send and receive keys that are used for encrypted communication between the client and server. The ACS EAP-TLS server sends MPPE keys to the client in vendor-specific RADIUS attribute (26) by using vendor code Microsoft (311), and attributes MS-MPPE-Send-Key (16) and MS-MPPE-Recv-Key (17).

Figure B-2 shows the EAP-TLS processing flow between the host, network device, and ACS EAP-TLS server.

Figure B-2 EAP-TLS Flow

1

A host connects to the network. The network device sends an EAP request to the host.

2

The host sends an EAP response to the network device; the network device embeds the EAP packet that it received from the host into a RADIUS request and sends it to ACS.

3

ACS negotiates the EAP method for authentication. The server and client must reach agreement to use EAP-TLS (EAP request method 13) during EAP method negotiation to instantiate EAP-TLS authentication.

4

The client (host) and server (ACS) exchange certificates; this exchange involves several messages.

EAP-TLS authentication is successful after the client and server have authenticated each other, and each side is aware that the other side has authenticated them.

5

ACS returns an EAP success message to the host and returns a RADIUS access-accept to the network device that includes session keys.

   


Note All communication between the host and ACS goes through the network device.


EAP-TLS authentication fails if the:

Server fails to verify the client's certificate, and rejects EAP-TLS authentication.

Client fails to verify the server's certificate, and rejects EAP-TLS authentication.

Certificate validation fails if the:

Certificate has expired.

Server or client cannot find the certificate issuer.

Signature check failed.

The client dropped cases resulting in malformed EAP packets.

EAP-TLS also supports:

Fragmentation

When a TLS message is greater than the size of an EAP packet, fragmentation is supported at the protocol level. The EAP-TLS server manages correct division of the request packets that are sent to the client, and the reconstruction of responses from the client.

Session Resume

ACS supports the EAP-TLS session resume feature for fast reauthentication of a user who has already passed full EAP-TLS authentication. If the EAP-TLS configuration includes a session timeout period, ACS caches each TLS session for the duration of the timeout period. When a user reconnects within the configured EAP-TLS session timeout period, ACS resumes an EAP-TLS session, and the user re authenticates by a TLS handshake only, without a certificate comparison.

Related Topics

Types of PACs

User Certificate Authentication

PEAPv0v1

This section contains the following topics:

Overview of PEAP

EAP-MSCHAPv2

ACS 5.0 supports these PEAP supplicants:

Microsoft Built-In Clients 802.1x XP (PEAPv0 only)

Microsoft Built-In Clients 802.1x Vista (PEAPv0 only)

CSSC v.4.0

CSSC v.5

Funk Odyssey access client (latest version)

Overview of PEAP

PEAP is a client-server security architecture that you use to encrypt EAP transactions, thereby protecting the contents of EAP authentications. PEAP uses server-side public key certificates to authenticate the server. It then creates an encrypted SSL/TLS tunnel between the client and the authentication server. The ensuing exchange of authentication information to authenticate the client is then encrypted and user credentials are safe from eavesdropping.

PEAP is similar to EAP-TLS but uses a different client authentication method. PEAP provides authentication, by using server certificates, a TLS tunnel and client authentication through that encrypted tunnel. Unlike EAP-TLS, PEAP requires the client to use another EAP type, like EAP-MSCHAPv2.

PEAP authentications always involve two phases:

In phase1, the end-user client authenticates ACS. This action requires a server certificate and authenticates ACS to the end-user client, ensuring that the user or machine credentials sent in phase two are sent to a AAA server that has a certificate issued by a trusted CA. The first phase uses a TLS handshake to establish an SSL tunnel between the end-user client and the AAA server.


Note Depending on the end-user client involved, the CA certificate for the CA that issued the ACS server certificate is likely to be required in local storage for trusted root CAs on the end-user client computer.


In the second phase, ACS authenticates the user or machine credentials by using an EAP authentication protocol. The SSL tunnel that was created in phase1 protects the EAP authentication. The authentication type that is negotiated during the second conversation may be EAP-MSCHAPv2. In phase two, PEAP supports only the EAP-MSCHAPv2 authentication protocol.

One improvement in security that PEAP offers is identity protection. This improvement is the potential of protecting the username in all PEAP transactions. After phase one of PEAP, all data is encrypted, including username information that is usually sent in clear text. The Microsoft PEAPv0 client does not provide identity protection; the Microsoft PEAPv0 client sends the username in clear text in phase one of PEAP authentication.

In ACS 5.0 PEAP is encapsulated in RADIUS protocol. Inner method EAP messages are encapsulated in an EAP-TLV method.

Supported PEAP Features

This section contains the following topics:

Server Authenticated and Unauthenticated Tunnel Establishment Modes

Fast Reconnect

Session Resume

Protected Exchange of Arbitrary Parameters

Server Authenticated and Unauthenticated Tunnel Establishment Modes

Tunnel establishment helps prevent an attacker from injecting packets between the client and the network access server (NAS) or, to allow negotiation of a less secure EAP method. The encrypted TLS channel also helps prevent denial of service attacks against the ACS.

A client EAP message is always carried in the RADIUS Access-Request message and the server EAP message is always carried in the RADIUS Access-Challenge message. The EAP success message is always carried in RADIUS Access-Accept message. The EAP failure message is always carried in the RADIUS access-reject message. The client's PEAP message may cause the RADIUS client's message to drop unless the policy component is configured otherwise.

Fast Reconnect

When a session resumes, another method of decreasing the authentication time is to skip the inner method, also known as fast reconnect. After a tunnel is built, the authentication flow goes directly to exchange authentication information with a Result TLV Success (v0) / tunneled EAP success message for successful authentication and an EAP failure message in case of unsuccessful authentication. You can configure ACS to enable the Fast Reconnect option.After successful authentication, the client is able to perform a fast reconnect during a certain timeframe. PEAP fast reconnect reduces the delay in time between an authentication request by a client and the response by ACS. Fast reconnect also allows wireless clients to move between access points without repeated requests for authentication, which reduces resource requirements for the client and the server.

The user identity and the protocol used for user authentication (inner method) should be cached along with the TLS session to allow fast reconnect.

Session Resume

ACS supports a session resume feature for PEAP-authenticated user sessions. When this feature is enabled, ACS caches the TLS session that is created during phase one of PEAP authentication, provided that the user successfully authenticates in phase two of PEAP. If a user needs to reconnect and the original PEAP session has not timed out, ACS uses the cached TLS session, resulting in faster PEAP performance and a lessened AAA server load.

ACS stores the session in the cache after a successful full authentication. A client may try to resume the same session during a specific timeframe. A server certificate is not presented and the tunnel is built by using the session information from the OpenSSL session cache. The authentication flow then goes directly to the inner method.

If a client attempts to perform session resume but the timeout elapsed, ACS reverts to the full authentication flow.

You can configure the session resume and timeout values.

Protected Exchange of Arbitrary Parameters

TLV tuples provide a way to exchange arbitrary information between the peer and ACS within a secure channel.

PEAP Flow in ACS 5.0

The PEAP protocol allows authentication between ACS and the peer by using the PKI-based secure tunnel establishment and the EAP-MSCHAPv2 protocol as the inner method inside the tunnel. The Local Certificate can be validated by the peer (server-authenticated mode) or not validated (server-unauthenticated mode).

Figure B-3 shows the PEAP processing flow between the host, access point, network device, and ACS EAP-TLS server.

Figure B-3 PEAP Processing Flow

Creating the TLS Channel

To create the PEAP-TLS channel:

1

After creating a logical link, the wireless AP sends an EAP-Request/Identity message to the wireless client.

2

The wireless client responds with an EAP-Response/Identity message that contains the identity (user or computer name) of the wireless client.

3

The wireless AP sends the EAP-Response/Identity message to ACS. From this point on, the logical communication occurs between ACS and the wireless client by using the wireless AP as a pass-through device.

4

ACS sends an EAP-Request/Start PEAP message to the wireless client.

5

The wireless client and ACS exchange a series of TLS messages through which the cipher suite for the TLS channel is negotiated. In ACS 5.0, the client certificate is not used in PEAP.

 

At the end of the PEAP negotiation, ACS has authenticated itself to the wireless client. Both nodes have determined mutual encryption and signing keys (by using public key cryptography, not passwords) for the TLS channel.


Authenticating with MS-CHAPv2

After the PEAP-TLS channel is created. Follow these steps to authenticate the wireless client credentials with MS-CHAPv2:

1

ACS sends an EAP-Request/Identity message.

2

The wireless client responds with an EAP-Response/Identity message that contains the identity (user or computer name) of the wireless client.

3

ACS sends an EAP-Request/EAP-MS-CHAPv2 challenge message that contains a challenge string.

4

The wireless client responds with an EAP-Response/EAP-MS-CHAPv2 Response message that contains the response to ACS challenge string and a challenge string for ACS.

5

ACS sends an EAP-Request/EAP-MS-CHAPv2 success message, which indicates that the wireless client response was correct and contains the response to the wireless client challenge string.

6

The wireless client responds with an EAP-Response/EAP-MS-CHAPv2 acknowledgment message, indicating that ACS response was correct.

7

ACS sends an EAP-Success message.

   

At the end of this mutual authentication exchange, the wireless client has provided proof of knowledge of the correct password (the response to the ACS challenge string), and ACS has provided proof of knowledge of the correct password (the response to the wireless client challenge string). The entire exchange is encrypted through the TLS channel created in PEAP.

Related Topics

Authentication Protocol and Identity Store Compatibility

Configuring PEAP Settings, page 16-2

EAP-FAST

This section contains the following topics:

Overview of EAP-FAST

EAP-FAST Flow in ACS 5.0.

EAP-FAST PAC Management

Overview of EAP-FAST

The EAP Flexible Authentication via Secured Tunnel (EAP-FAST) protocol is a new, publicly accessible IEEE 802.1x EAP type that Cisco developed to support customers that cannot enforce a strong password policy and want to deploy an 802.1x EAP type that does not require digital certificates. EAP-FAST supports a variety of user and password database types, password change and expiration, and is flexible, easy to deploy, and easy to manage. For more information about EAP-FAST and comparison with other EAP types, see:

www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00802030dc.shtml

EAP-FAST is a client-server security architecture that encrypts EAP transactions with a TLS tunnel. While similar to PEAP in this respect, it differs significantly in that EAP-FAST tunnel establishment is based on strong secrets that are unique to users. These secrets are called Protected Access Credentials (PACs), which ACS generates by using a known only to ACS. Because handshakes based on shared secrets are intrinsically faster than handshakes based on PKI, EAP-FAST is the significantly faster of the two solutions that provide encrypted EAP transactions. No certificate management is required to implement EAP-FAST.

EAP-FAST occurs in three phases:

Phase zero—Unique to EAP-FAST, phase zero is a tunnel-secured means of providing an EAP-FAST end-user client with a PAC for the user requesting network access. (See Automatic PAC Provisioning.) Providing a PAC to the end-user client is the sole purpose of phase zero. The tunnel is established based on an anonymous Diffie-Hellman key exchange for Anonymous In-band provisioning. Authenticated In-band provisioning uses other cipher suites. If EAP-MS-CHAPv2 authentication succeeds, ACS provides the user with a PAC. To determine which databases support EAP-FAST phase zero, see Authentication Protocol and Identity Store Compatibility.


Note Phase zero is optional and PACs can be manually provided to end-user clients. (See Manual PAC Provisioning.)


The Allow Anonymous In-Band PAC provisioning option provides an end-user client with a PAC by using EAP-FAST phase zero. If this check box is checked, ACS establishes a secured connection with the end-user client for the purpose of providing the client with a new PAC. This option allows an anonymous TLS handshake between the end-user client and ACS. (EAP-MS-CHAP will be used as inner method only.)

The Allow Authenticated In-Band PAC provisioning option provisions an end-user client with a PAC by using EAP-FAST phase zero with TLS server-side authentication. This option requires that you install a server certificate.

Phase zero of EAP-FAST does not enable a network service, therefore, even a successful EAP-FAST phase zero transaction is recorded in the ACS Failed Attempts log.

If you choose the Accept Client on Authenticated Provisioning option, ACS always sends an access-reject at the end of  the provisioning phase (phase zero) and the client is not forced to re-authenticate again. This option sends an  access-accept to the client and can be enabled only when you check the Allow Authenticated in-band PAC provisioning check box.

Phase one—In phase one, ACS and the end-user client establish a TLS tunnel based on the PAC that the end-user client presents. This phase requires that the end-user client has been provided a PAC for the user who is attempting to gain network access and that the PAC is not expired. The means by which PAC provisioning has occurred is irrelevant; you can use automatic or manual provisioning.

Phase two—In phase two, ACS authenticates the user credentials with EAP-MS-CHAPv2, which is protected by the TLS tunnel that was created in phase one. EAP MS-CHAPv2 is supported as an inner method. To determine which databases support EAP-FAST phase two, see Authentication Protocol and Identity Store Compatibility.

Phase one and phase two are subsequent parts of the same EAP-FAST conversation.

EAP-FAST can protect the username in all EAP-FAST transactions. ACS does not perform user authentication based on a username that is presented in phase one, however, whether the username is protected during phase one depends on the end-user client. If the end-user client does not send the real username in phase one, the username is protected. After phase one of EAP-FAST, all data is encrypted, including username information that is usually sent in clear text.

ACS supports password aging with EAP-FAST for users who are authenticated by Windows user databases. Password aging can work with phase zero or phase two of EAP-FAST. If password aging requires a user to change passwords during phase zero, the new password would be effective in phase two.

EAP-FAST Benefits

EAP-FAST provides the following benefits over other authentication protocols:

Mutual Authentication— The EAP server must be able to verify the identity and authenticity of the peer and the peer must be able to verify the authenticity of the EAP server.

Immunity to passive dictionary attacks—Many authentication protocols require a password to be explicitly provided, either as clear text or hashed, by the peer to the EAP server.

Immunity to man-in-the-middle (MitM) attacks—In establishing a mutually authenticated protected tunnel, the protocol must prevent adversaries from successfully interjecting information into the conversation between the peer and the EAP server.

Flexibility to enable support for many different password authentication interfaces such as MS-CHAP, and others— EAP-FAST is an extensible framework that allows support of multiple internal protocols by the same server.

Efficiency— When using wireless media, peers are limited in computational and power resources. EAP-FAST enables the network access communication to be computationally lightweight.

Minimization of the authentication server's per user authentication state requirements—With large deployments, it is typical to have many servers acting as the authentication servers for many peers. It is also highly desirable for a peer to use the same shared secret to secure a tunnel much the same way it uses the username and password to gain access to the network. EAP-FAST facilitates the use of a single strong shared secret by the peer while enabling servers to minimize the per-user and device state it must cache and manage.

EAP-FAST in ACS 5.0

ACS supports in-band provisioning of the peer with a shared secret credential (PAC) based on PKI or ADHP (phase 0). Authentication of the peer and allowing the peer access to the network is implemented in phase 1 and phase 2.

ACS 5.0 supports EAP-FAST versions 1 and 1a.


Note ACS 5.0 does not support EAP-FAST for the Funk Supplicant (Odyssey).


This section contains the following topics:

About Master-Keys

About PACs

Provisioning Modes

Types of PACs

Machine PAC Authentication

Proactive PAC Update

Accept Peer on Authenticated Provisioning

PAC-less Authentication

Master Key Generation and PAC TTLs

About Master-Keys

EAP-FAST master-keys are strong secrets that ACS automatically generates and of which only ACS is aware. Master-keys are never sent to an end-user client. EAP-FAST requires master-keys for two purposes:

PAC generation—ACS generates PACs by using the active master-key. For details about PACs, see About PACs.

EAP-FAST phase one—ACS determines whether the PAC that the end-user client presents was generated by one of the master-keys it is aware of.

To increase the security of EAP-FAST, ACS changes the master-key that it uses to generate PACs. ACS uses Master Key Generation Period values that you define to determine when it generates a new master-key and the age of all master-keys.

An active master-key is the master-key used by ACS to generate PACs. The Master Key Generation Period setting determines the duration that a master-key remains active. At any time, only one master-key is active. For more information about how TTL values determine whether PAC refreshing or provisioning is required, see Master Key Generation and PAC TTLs.

About PACs

PACs are strong shared secrets that enable ACS and an EAP-FAST end-user client to authenticate each other and establish a TLS tunnel for use in EAP-FAST phase two. ACS generates PACs by using the active master-key and a username.

PAC comprises:

PAC-Key—Shared secret bound to a client (and client device) and server identity.

PAC Opaque—Opaque field that the client caches and passes to the server. The server recovers the PAC-Key and the client identity to mutually authenticate with the client.

PAC-Info—At a minimum, includes the Authority ID to enable the client to cache different PACs. Optionally, it includes other information such as the PACs expiration time.

An EAP-FAST end-user client stores PACs for each user accessing the network with the client. Additionally, a AAA server that supports EAP-FAST has a unique Authority ID. An end-user client associates a user's PACs with the Authority ID of the AAA server that generated them. PACs remove the need for PKI (digital certificates).

During EAP-FAST phase one, the end-user client presents the PAC that it has for the current user and Authority ID that ACS sends at the beginning of the EAP-FAST transaction. The means of providing PACs to end-user clients, known as PAC provisioning, are discussed in Automatic PAC Provisioning and Manual PAC Provisioning.

Modifying the master key generation values does not affect already created PACs. Any modifications you make to the master key generation values specify the period when the next master keys are generated.

Provisioning Modes

ACS supports out-of-band and in-band provisioning modes. The in-band provisioning mode operates inside an Authenticated Diffie-Hellman Key Agreement Protocol (ADHP) tunnel before the peer authenticates the ACS server.

Because PAC is provisioned to a client or a client is provisioned with PAC, it is not possible to use a clear text password; therefore, only MS-CHAPv2 credentials can be used inside the tunnel. MS-CHAPv2 is used to prove the peer's identity and the PAC is received for further authentication sessions after MS-CHAPv2 is finished. This method minimizes the risk of exposing the user's credentials.

EAP-FAST has been enhanced to support an authenticated tunnel (by using the server certificate) inside which PAC provisioning occurs. The new cipher suites that are enhancements to EAP-FAST and specifically the server certificate, are used.

At the end of a provisioning session that uses an authenticated tunnel, network access can be granted because the server and user have authenticated each other.

ACS supports EAP-MS-CHAPv2 inside the tunnel for provisioning.


Note By default, when you use EAP-MSCHAP inner methods, ACS allows authentication attempts up to the specified value you configured on the Service page inside the TLS tunnel if the initial authentication attempt fails. After the fourth failed authentication attempt inside the SSL tunnel, ACS terminates the EAP conversation, resulting in a RADIUS access-reject.


ACS supports issuing an out-of-band PAC file that allows you to generate a PAC that can be downloaded to ACS.

Types of PACs

ACS supports the following types of PACs:

Tunnel v1 and v1a

CTS

Machine

Authorization

ACS provisions supplicants with a PAC that contains a shared secret that is used in building a TLS tunnel between the supplicant and ACS. ACS provisions supplicants with PACs that have a wider contextual use.

The following types of PACs are provisioned to ACS, as per server policies:

Tunnel/Machine PAC —Contains user or machine credentials, but no policy information.

User Authorization PAC—Contains policy elements (for example, inner method used for user authentication). You can use the User Authorization PACs to allow a stateless server session to resume, as described in Session Resume.

The various means by which an end-user client can receive PACs are:

PAC provisioning—Required when an end-user client has no PAC. For more information about how master-key and PAC states determine whether PAC provisioning is required, see Master Key Generation and PAC TTLs.

The two supported means of PAC provisioning are:

Automatic provisioning—Sends a PAC by using a secure network connection. For more information, see Automatic PAC Provisioning.

Manual provisioning—Requires that you use ACS to generate a PAC file for the user, copy the PAC file to the computer that is running the end-user client, and import the PAC file into the end-user client. For more information, see Manual PAC Provisioning.

PAC refresh—Occurs based on the value you specify in the Proactive PAC Update When field. For more information about how master-key and PAC states determine whether a PAC is refreshed, see Master Key Generation and PAC TTLs.

PACs have the following two states, which the PAC TTL setting determines:

Active—A PAC younger than the PAC TTL is considered active and can be used to complete EAP-FAST phase one.

Expired—A PAC that is older than the PAC TTL is considered expired.At the end of EAP-FAST phase two, ACS generates a new PAC for the user and provides it to the end-user client.

Automatic PAC Provisioning

Automatic PAC provisioning, which is the same as EAP-FAST phase zero, sends a new PAC to an end-user client over a secured network connection. Automatic PAC provisioning requires no intervention of the network user or a ACS administrator, provided that you configure ACS and the end-user client to support automatic provisioning.

Automatic PAC provisioning requires EAP-MS-CHAPv2 authentication of the user. ACS establishes a Diffie-Hellman tunnel with the end-user client, and then MS-CHAPv2 authentication is performed. ACS generates a PAC for the user and sends it to the end-user client in this tunnel, along with the Authority ID and Authority ID information about this ACS.


Note Given that ACS associates each user with a single identity store, the use of automatic PAC provisioning requires that EAP-FAST users are authenticated with an identity store that is compatible with EAP-FAST phase zero. For the databases with which ACS can support EAP-FAST phase zero and phase two, see Authentication Protocol and Identity Store Compatibility.


No network service is enabled by phase zero of EAP-FAST, therefore, phase 0 of EAP-FAST does not enable any network service; therefore, ACS logs an EAP-FAST Phase 0 transaction in the Failed Attempts log, including an entry that PAC provisioning occurred. After the end-user client has received a PAC through a successful phase zero, it sends a new EAP-FAST request to begin phase one.


Note Because transmission of PACs in phase zero is secured by MS-CHAPv2 authentication and MS-CHAPv2 is vulnerable to dictionary attacks, we recommend that you limit use of automatic provisioning to initial deployment of EAP-FAST. After a large EAP-FAST deployment, PAC provisioning should manually to ensure the highest security for PACs. For more information about manual PAC provisioning, see Manual PAC Provisioning.


To control whether ACS performs automatic PAC provisioning, you use the options on the Global System Options pages in the System Administration drawer. For more information, see EAP-FAST.

Manual PAC Provisioning

Manual PAC provisioning requires an ACS administrator to generate PAC files, which must then be distributed to the applicable network users. Users must configure end-user clients with their PAC files. You can use manual PAC provisioning to control who can use EAP-FAST to access your network. If you disable automatic PAC provisioning, any EAP-FAST user denied a PAC cannot access the network. If your ACS deployment includes network segmentation, wherein a separate ACS controls access to each network segment, manual PAC provisioning enables you to grant EAP-FAST access on a per-segment basis. For example, if your company uses EAP-FAST for wireless access in its Chicago and Boston offices and the Cisco Aironet Access Points at each of these two offices are configured to use different ACSs, you can determine, on a per-employee basis, whether Boston employees visiting the Chicago office can have wireless access.

While the administrative overhead of manual PAC provisioning is much greater than automatic PAC provisioning, it does not include the risk of sending the PAC over the network. When you first deploy EAP-FAST by using manual PAC provisioning would require a lot of manual configuration of end-user clients, however, this type of provisioning is the most secure means for distributing PACs. We recommend that, after a large EAP-FAST deployment, you should manually perform PAC provisioning to ensure the highest security for PACs.

You can generate PAC files for specific usernames. You can also generate a PAC for a machine and provision the PAC manually to the client.

The following parameters are required to create a PAC:

Specifying whether it is a user or machine PAC.

Identity stored in Internal Identity Store ID field.

PAC Time to Live (TTL).

PAC encryption on or off, and password for encryption.

The PAC could be encrypted with the specified password by using the RC4 or AES algorithm. The detailed decryption algorithm must be provided to the client to allow decryption of the manually received PAC data.

ACS Supported Features for PACs

ACS 5.0 support these features for PACs.

Machine PAC Authentication

Machine PAC-based authentication allows the machine to gain restricted network access before user authentication.

Proactive PAC Update

ACS proactively provides a new PAC to the client after successful authentication when a configured percentage of the PAC TTL remains. The tunnel PAC update is initiated by the server after the first successful authentication that is performed before the PAC expiration. The proactive PAC update time is configured in ACS serve r in the Allowed Protocols Page. This mechanism allows client to be always updated with a valid PAC.


Note There is no proactive PAC update for Machine and Authorization PACs.


Accept Peer on Authenticated Provisioning

The peer may be authenticated during the provisioning phase.

PAC-less Authentication

With PAC-less EAP-FAST Authentication, you can run EAP-FAST on ACS without issuing or accepting any tunnel or machine-generated PAC. The secure tunnel may be established by using a certificate rather than a PAC. Some PACs may be long-lived and not updated, which may cause authentication and security problems. When PAC-less EAP-FAST is enabled, requests for PACs are ignored. Authentication begins with EAP-FAST phase zero and all subsequent requests for PACs are ignored. The flow moves on to EAP-FAST phase two. ACS responds with a Success-TLV message, without a PAC. If a client attempts to establish a tunnel with a PAC, ACS responds with a PAC Invalid message. The tunnel establishment does not occur, and an access-reject is sent. The host or supplicant can reattempt to connect.

Anonymous phase zero, also known as ADHP is not supported for PAC-less authentication since the protocol does not support rolling over to phase two. PAC-less EAP-Fast supports configuration and does not require a client certificate.

Table B-3 displays the different types of PACs and the authentication and authorization methods you can use them for.

Table B-3 PAC Rules Summary

PAC Type
Tunnel v1/v1a/CTS
Machine
Authorization

Provide PAC on request on provisioning

Yes

Yes

Provide PAC on request on provisioning.

Provide PAC on request on authentication

Yes

Yes

Only if the PAC was not used in this authentication.

Proactive update

Yes

No

No

When PAC is expired

Reject and do not provide a new PAC

Reject and do not provide a new PAC

Reject and do not provide a new PAC.

Support ACS 3.x/4.x PACs

For Tunnel PAC v1/v1a only

Yes

No


Related Topics

About PACs

Provisioning Modes

Types of PACs

Master Key Generation and PAC TTLs

Master Key Generation and PAC TTLs

The values for master key generation and PAC TTLs determine their states, as described in About Master-Keys and Types of PACs. Master key and PAC states determine whether someone requesting network access with EAP-FAST requires PAC provisioning or PAC refreshing.

Related Topics

About PACs

Provisioning Modes

Types of PACs

ACS Supported Features for PACs

EAP-FAST Flow in ACS 5.0.


Note You must configure the end-user clients to support EAP-FAST. This procedure is specific to configuring ACS only.


Before You Begin

The steps in this procedure are a suggested order only. Enabling EAP-FAST at your site may require recursion of these steps or performing these steps in a different order. For example, in this procedure, determining how you want to support PAC provisioning comes after configuring a user database to support EAP-FAST; however, choosing automatic PAC provisioning places different limits on user database support.

To enable ACS to perform EAP-FAST authentication:


Step 1 Configure an identity store that supports EAP-FAST authentication. To determine which identity stores support EAP-FAST authentication, see Authentication Protocol and Identity Store Compatibility. For information about configuring identity stores, see Chapter 7, "Managing Users and Identity Stores"

Step 2 Determine master key generation and PAC TTL values. For information about how master key generation and PAC TTL values determine whether PAC provisioning or PAC refreshing is required, see Master Key Generation and PAC TTLs.

Step 3 Determine whether you want to use automatic or manual PAC provisioning. For more information about the two means of PAC provisioning, see Automatic PAC Provisioning, and Manual PAC Provisioning.


Note We recommend that you limit the use of automatic PAC provisioning to initial deployments of EAP-FAST, before you use manual PAC provisioning for adding small numbers of new end-user clients to your network and replacing PACs based on expired master keys.


Step 4 Using the decisions during Step 2 and Step 3, enable EAP-FAST in the Global Systems Options drawer. See EAP-FAST for more information.

ACS is ready to perform EAP-FAST authentication.


Note Inner-identity will not be logged when: the workstation not allowed error appears, the SSL Handshake fails, EAP-PAC is provisioned, and ACS receives an invalid PAC.


Related Topics

Managing Internal Identity Stores, page 7-5

Managing External Identity Stores, page 7-11

EAP-FAST PAC Management

The EAP-FAST master-key in ACS is used to encrypt or decrypt, sign and authenticate the PACs and PAC-Opaque's that are used by EAP-FAST to store server opaque data by a supplicant. EAP-FAST requires a distributed mechanism by which each server in the ACS domain is able to pack and unpack PACs securely, including those which were packed on a different server.

The EAP-FAST master-key must have a common secret that is known to all servers in the ACS domain. The master-key is periodically refreshed and keys are replaced securely and synchronized by all ACS servers. The keys are generated of high entropy to comply with strong cryptographic standards such as FIPS-140.

In previous versions of ACS, the master-key was distributed by the ACS distribution mechanism and was replaced from time to time to improve the security of those keys. ACS 5.0 introduces a new scheme that provides simplicity, correctness, robustness, and security for master -key distribution.

The ACS EAP-FAST new distribution scheme contains a secure way of distributing the common seed-key, from which each ACS server can deterministically derive the same set of master-keys. Each PAC contains the information that the master-key was derived from, and each server can securely reconstruct the master-key that encrypted and signed the PAC.

This scheme improves the security by reducing the amount of cryptographic sensitive material that is transmitted.

This section contains the following topics:

Key Distribution Algorithm

EAP-FAST PAC-Opaque Packing and Unpacking

Revocation Method

PAC Migration from ACS 4.x

Key Distribution Algorithm

The common seed-key is a relatively large and a completely random buffer that is generated by the primary ACS server. The seed-key is generated only once during installation, or it can be manually regenerated by an administrator. The seed-key should rarely be replaced, because if you change seed-key, of all the previous master-keys and PACs would automatically be deactivated.

The seed-key is generated by using a FIPS approved RNG generator that exists in the runtime cryptographic module (CryptoLib). The ACS primary server management determines when to generate the seed-key, and communicates with the ACS runtime to request a new seed-key to be generated.

The size of the seed-key may vary and should consist of at least 64 bytes (512 bit). A larger seed might have some performance implication as each master-key derivation is dependant on it subsequently.

At any given time, a single seed-key should be used by each ACS server and the primary ACS server should ensure to distribute the latest seed-key to all the servers. Old seed-keys must discarded.

The seed- key contains critical cryptographic sensitive information.Disclosing the seed-key information would expose the entire EAP-FAST PAC mechanism to a large set of possible identity vulnerabilities. Due to that, the mechanism which transports the seed-key between the primary and the secondary ACS servers must be fully secured. Further security measures must be taken with respect to storing the seed-key in the data-base. The seed-key should be protected with the strongest means of security.

EAP-FAST PAC-Opaque Packing and Unpacking

When the server generates a new PAC, it must derive the master-key to be used. When the server accepts a new PAC the same algorithm should be used for deriving the master-key with some additional verification used to prevent possible attacks on the master-key scheme. The derivation calculation may be skipped if the master-key was already placed in the cache in the past.

Revocation Method

You can revoke all PACs and all Master-Keys. For this type of extensive revocation, all you need to do is to revoke the seed-key and replace it by a new one.

Having only a single seed-key to be used in the system facilitates implementation.

PAC Migration from ACS 4.x

Although the configuration can be migrated from 4.x, the PACs themselves, as being stored only in supplicants, may still be issued from versions as far back as ACS 3.x. ACS 5.0 accepts PACs of all types according to migrated master-keys from versions 4.x and onwards, and re-issues a new 5.0 PAC, similar to the proactive PAC update for EAP-FAST 5.0.

When ACS 5.0, accepts a PAC from either ACS 3.x or 4.x, it decrypts and authenticates the PAC according to the 4.x master-key that was migrated from ACS 4.x configuration. The decryption and handling of this type of PAC is similar to the way the ACS 4.x PAC was handled.

The migration process involves converting the following data-items:

EAP-FAST A-ID of ACS (Authority ID). The parameter replaces the deployment's A-ID of ACS 5.0.

A list of retired ACS 4.x master-keys. The list is taken from the ACS 4.x configuration and placed in a new table in ACS 5.0. Each migrated master-key is associated with its expected time of expiration. The table is migrated along with the master-key identifier (index) and the PAC's-cipher assigned to each key.

EAP-MSCHAPv2

Microsoft Challenge Handshake Authentication Protocol (MSCHAP v2) provides two-way authentication, also known as mutual authentication. The remote access client receives verification that the remote access server that it is dialing in to has access to the user's password.

This section contains the following topics:

Overview of EAP-MSCHAPv2

EAP- MSCHAPv2 Flow in ACS 5.0

Overview of EAP-MSCHAPv2

EAP-MSCHAPv2 is one of the methods in the EAP authentication framework.This EAP type can be used inside the TLS tunnel created by Protected EAP. EAP-MSCHAPv2 wraps MSCHAP v2 inside the EAP. If you want to reuse Microsoft user credentials and servers (for example, Windows Active Directories) for wireless authentication you can use this password for:

MSCHAPv2 for User Authentication.

MSCHAPv2 for Change Password.

Windows Machine Authentication Against AD.

MSCHAPv2 for User Authentication

ACS supports the EAP-MSCHAPv2 authentication protocol as the inner method of EAP-FAST and PEAP. The protocol is an encapsulation of MSCHAPv2 into the EAP framework. Mutual authentication occurs against the configured credential database. The client does not send its password, but a cryptographic function of the password. Using EAP-MSCHAPv2 as the inner method of tunneling protocols, increases protection of secured communication. Every protocol message is encrypted inside the tunnel and server, and client challenges are not generated randomly but, derived from outer method cryptographic material.

EAP-MSCHAPv2 is supported for AD and the ACS internal identity store.

MSCHAPv2 for Change Password

When a user password expires, ACS fails the EAP-MSCHAPv2 conversation with a specific notification. The client can prompt the user for new password and then provide it to ACS inside the same conversation. The new password is encrypted with the help of the old one. When a user password is changed successfully, the new user password is stored in the credential database.

EAP-MSCHAPv2 change password is supported for AD and ACS internal identity store.

Windows Machine Authentication Against AD

EAP-MSCHAPv2 can be used for machine authentication. EAP-MSCHAPv2 Windows machine authentication is the same as user authentication. The difference is that you must use the Active Directory of a Windows domain, since a machine password can be generated automatically on the machine and the AD, as a function of time and other parameters. The password generated cannot be stored in other types of credential databases.

EAP- MSCHAPv2 Flow in ACS 5.0

Components involved in the 802.1x and MSCHAPv2 authentication process are the:

Host—The end entity, or end user's machine.

AAA client—The network access point.

Authentication server—ACS.

The MSCHAPv2 protocol is described in RFC 2759.

Related Topic

Authentication Protocol and Identity Store Compatibility

Certificate Attributes

ACS parses the following client certificate's attributes:

Certificate serial-number (in binary format)

Encoded certificate (in binary DER format)

Subject's CN attribute

Subject's O attribute (Organization)

Subject's OU attribute (Organization Unit)

Subject's L attribute (Location)

Subject's C attribute (Country)

Subject's ST attribute (State Province)

Subject's E attribute (eMail)

Subject's SN attribute (Subject Serial Number)

SAN (Subject Alternative Name)

You can define a policy to set the principle username to use in the TLS conversation, as an attribute that is taken from the received certificate.

The attributes that can be used as the principle username are:

Subject CN

Subject Serial-Number (SN)

SAN

If the certificate does not contain the configured attribute, authentication fails.


Note ACS 5.0 supports short hard-coded attributes and certificate attribute verification for the only the EAP-TLS protocol.


Certificate Binary Comparison

You can perform binary comparison against a certificate that ACS receives from an external identity store. and determine the identity-store's parameters that would be used for the comparison.


Note In ACS 5.0, LDAP is the only external identity store that holds certificates.


ACS uses the configured principle username to query for the user's certificate and then perform binary comparison between the certificate received from external identity store and the one received from the client. The comparison is performed on a DER certificate format.

Rules Relating to Textual Attributes

ACS collects client certificate textual attributes and places them in the ACS context dictionary. ACS can apply any rule based policy on these attributes as with any rule attributes in ACS.

The attribute that can be used for rule verification are:

Subject's CN attribute

Subject's O attribute (Organization)

Subject's OU attribute (Organization Unit)

Subject's L attribute (Location)

Subject's C attribute (Country)

Subject's ST attribute (State Province)

Subject's E attribute (eMail)

Subject's SN attribute (Subject Serial Number)

SAN (Subject Alternative Name)

Certificate Revocation

Every client certificate that ACS receives is verified with a Certificate Revocation List (CRL) according to a policy that is defined.

The CRL scheme verifies whether either a client certificate or its issuing CA keys are broken. ACS searches for the certificate's issuer together with the serial-numbers, in the CRL. If they are found, the certificate is rejected.

ACS supports a static-CRL that contains a list of URLs used to acquire the CRL files that are configured in ACS database.

You can configure a set of URLs used for CRL update for each trusted CA certificate,. By default, when adding a CA certificate, ACS automatically sets all the URLs stored in the certificate crlDistributionPoint as the initial static CRL for that CA. In most cases, the crlDistributionPoint is used to point to the CRL location used to revoke the CA certificate, but you can edit the URL to point to the CRL file issued by this CA. You can only configure a single HTTP based URL for each CA.

You can configure the parameters for each CA, which will apply to all the URLs that are configured to the CA. ACS supports two download modes, one for periodic download, and the other for downloading the next CRL update just before the previous is about to expire. For the periodic download, you can define the download periods. For automatic downloading, you define the amount of time before the CRL file expires, should ACS download it. The CRL expiration time is taken from the CRL nextUpdate field. For both modes, if the download somehow fails, you can define the amount of time that ACS would wait before trying to re-download the CRL file.

ACS verifies that the downloaded CRL file is signed correctly by any one of the CAs in the trust store, for each downloaded CRL file and whether they are trusted. ACS uses the CRL file only if the signature verification passes. The verified CRL file replaces the previous CRL file issued by the same CA.


Note CRL files are not kept persistent, and should be re-downloaded when you restart ACS.


The configuration of URLs and their association to CA's is distributed to the entire ACS domain. The downloaded CRLs are not distributed and are autonomously populated in parallel in each ACS server.

Machine Authentication

ACS supports the authentication of computers that are running the Microsoft Windows operating systems that support EAP computer authentication. Machine authentication, also called computer authentication, allows networks services only for computers known to Active Directory. This feature is especially useful for wireless networks, where unauthorized users outside the physical premises of your workplace can access your wireless access points.

When machine authentication is enabled, there are three different types of authentications. When starting a computer, the authentications occur in this order:

Machine authentication—ACS authenticates the computer prior to user authentication. ACS checks the credentials that the computer provides against the Windows identity store. If you use Active Directory and the matching computer account in AD has the same credentials, the computer gains access to Windows domain services.

User domain authentication—If machine authentication succeeded, the Windows domain authenticates the user. If machine authentication failed, the computer does not have access to Windows domain services and the user credentials are authenticated by using cached credentials that the local operating system retains. In this case, the user can log in to only the local system. When a user is authenticated by cached credentials, instead of the domain, the computer does not enforce domain policies, such as running login scripts that the domain dictates.


Tip If a computer fails machine authentication and the user has not successfully logged in to the domain by using the computer since the most recent user password change, the cached credentials on the computer will not match the new password. Instead, the cached credentials will match an older password of the user, provided that the user once successfully logged in to the domain from this computer.


User network authentication—ACS authenticates the user, allowing the user to have network connectivity. If the user exists, the identity store that is specified is used to authenticate the user. While the identity store is not required to be the Windows identity store, most Microsoft clients can be configured to automatically perform network authentication by using the same credentials used for user domain authentication. This method allows for a single sign-on.


Note Microsoft PEAP clients may also initiate machine authentication whenever a user logs off. This feature prepares the network connection for the next user login. Microsoft PEAP clients may also initiate machine authentication when a user shuts down or restarts the computer rather than just logging off.


ACS supports EAP-TLS, PEAP (EAP-MS-CHAPv2), and PEAP (EAP-TLS) for machine authentication. You can enable each separately on the Active Directory: General Page, which allows a mix of computers that authenticate with EAP-TLS or PEAP (EAP-MS-CHAPv2). Microsoft operating systems that perform machine authentication might limit the user authentication protocol to the same protocol that is used for machine authentication.

Related Topics

Microsoft Active Directory, page 7-15

Managing External Identity Stores, page 7-11

Authentication Protocol and Identity Store Compatibility

ACS supports various authentication protocols to authenticate against the identity stores that ACS supports. For more information about the password protocols that ACS supports, see Passwords.

Table B-4 specifies non-EAP authentication protocol support.

Table B-4 Non-EAP Authentication Protocol and User Database Compatibility

Identity Store
ASCII/PAP
MSCHAPv2

ACS

yes

no

Windows AD

yes

no

LDAP

yes

no


Table B-5 specifies EAP authentication protocol support.

Table B-5 EAP Authentication Protocol and User Database Compatibility

Identity Store
EAP-MD5
EAP-TLS 1
PEAP EAP-MSCHAPv2
EAP-FAST MSCHAPv2

ACS

yes

no2

yes

yes

Windows AD

no

no3

yes

yes

LDAP

no

yes

no

no

1 During EAP-TLS, the user is authenticated by cryptographic validation of his certificate. Additionally, ACS 5.0 optionally allows a binary comparison of user's certificate sent by the end-user client against the user's certificate located on the user's record in LDAP identity store.

2 ACS 5.0 does not support certificate retreival from Windows AD. Windows AD can be used for groups/attributes retrieval only.

3 ACS 5.0 does not support certificate retreival from Windows AD. Windows AD can be used for groups/attributes retrieval only.


Passwords

ACS supports many common password protocols:

ASCII/PAP

EAP-MD5

EAP-TLS

PEAP (EAP-MSCHAPv2)

PEAP (EAP-TLS)

EAP-FAST (EAP-MSCHAPv2)

Passwords can be processed by using these password-authentication protocols based on the version and type of security-control protocol used (for example, RADIUS or TACACS+), and the configuration of the AAA client and end-user client.