Cisco Acs 5x User Guide
Have a look at the manual Cisco Acs 5x User Guide online for free. It’s possible to download the document as PDF or print. UserManuals.tech offer 53 Cisco manuals and user’s guides for free. Share the user manual or guide on Facebook, Twitter or Google+.
B-21 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-FAST ACS-Supported Features for PACs, page B-24 Master Key Generation and PAC TTLs, page B-26 EAP-FAST for Allow TLS Renegotiation, page B-26 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, page B-21. 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, page B-26. 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 - Ke y—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 - I n fo—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 In-Band PAC Provisioning, page B-23 and Manual PAC Provisioning, page B-24. 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.
B-22 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-FAST Provisioning Modes ACS supports out-of-band and in-band provisioning modes. The in-band provisioning mode operates inside a TLS tunnel raised by Anonymous DH or Authenticated DH or RSA algorithm for key agreement. To minimize the risk of exposing the user’s credentials, a clear text password should not be used outside of the protected tunnel. Therefore, EAP-MSCHAPv2 or EAP-GTC are used to authenticate the users credentials within the protected tunnel. The information contained in the PAC is also available for further authentication sessions after the inner EAP method has completed. 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 the following EAP methods inside the tunnel for provisioning: EAP-MSCHAPv2 EAP-GTC 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 SGA 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 information, 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, page B-16.
B-23 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-FAST 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, page B-26. The two supported means of PAC provisioning are: –Automatic In-Band PAC Provisioning—Sends a PAC by using a secure network connection. For more information, see Automatic In-Band PAC Provisioning, page B-23. –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, page B-24. PAC r e f r e s h—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, page B-26. 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 In-Band PAC Provisioning Automatic In-Band 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 In-Band PAC Provisioning requires no intervention of the network user or an ACS administrator, provided that you configure ACS and the end-user client to support Automatic In-Band PAC Provisioning. NoteGiven that ACS associates each user with a single identity store, the use of Automatic In-Band PAC Provisioning requires that EAP-FAST users be 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, page B-35. In general, phase zero of EAP-FAST does not authorize network access. In this general case, after the client has successfully performed phase zero PAC provisioning, the client must send a new EAP-FAST request in order to begin a new round of phase one tunnel establishment, followed by phase two authentication. However, if you choose the Accept Client on Authenticated Provisioning option, ACS sends a RADIUS Access-Accept (that contains an EAP Success) at the end of a successful phase zero PAC provisioning, and the client is not forced to reauthenticate again. This option can be enabled only when the Allow Authenticated In-Band PAC Provisioning option is also enabled. Because transmission of PACs in phase zero is secured by MSCHAPv2 authentication, when MSCHAPv2 is vulnerable to dictionary attacks, we recommend that you limit use of Automatic In-Band PAC Provisioning to initial deployment of EAP-FAST. After a large EAP-FAST deployment, PAC provisioning should be done manually to ensure the highest security for PACs. For more information about manual PAC provisioning, see Manual PAC Provisioning, page B-24.
B-24 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-FAST To control whether ACS performs Automatic In-Band PAC Provisioning, use the options on the Global System Options pages in the System Administration drawer. For more information, see EAP-FAST, page B-18. 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 In-Band PAC Provisioning, any EAP-FAST user who is not provisioned with a PAC will not be able to 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 that of automatic in-band PAC provisioning, it does not risk sending the PAC over the network. Although manually provisioning the PACs requires a lot of effort early on, in configuring many end-user clients during the initial deployment, this type of provisioning is the most secure means for distributing PACs. We recommend that, after a large EAP-FAST deployment, you 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 PA C d a t a . ACS-Supported Features for PACs ACS 5.3 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.
B-25 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-FAST The proactive PAC update time is configured for the ACS server in the Allowed Protocols Page. This mechanism allows the client to be always updated with a valid PAC. NoteThere 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. Ta b l e B - 3 displays the different types of PACs and the authentication and authorization methods you can use them for. Related Topics About PACs, page B-21 Provisioning Modes, page B-22 Types of PACs, page B-22 Master Key Generation and PAC TTLs, page B-26 Table B-3 PAC Rules Summary PAC Type Tunnel v1/v1a/SGA Machine Authorization Provide PAC on request on provisioningYes Yes Provide PAC on request on provisioning. Provide PAC on request on authenticationYes Yes Only if the PAC was not used in this authentication. Proactive update Yes No No When PAC is expired Reject, try to fall on TLS fallback, provide a new PAC after successful authentication only (tunnel PA C ) .Reject, try to fall on TLS fallback, provide a new PAC after successful authentication only (machine PA C ) .Reject and provide a new PAC after successful authentication only (authorization PAC). Support ACS 3.x/4.x PACs For Tunnel PAC v1/v1a only Yes No
B-26 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-FAST Master Key Generation and PAC TTLs The values for master key generation and PAC TTLs determine their states, as described in About Master-Keys, page B-21 and Types of PACs, page B-22. Master key and PAC states determine whether someone requesting network access with EAP-FAST requires PAC provisioning or PAC refreshing. Related Topics About PACs, page B-21 Provisioning Modes, page B-22 Types of PACs, page B-22 ACS-Supported Features for PACs, page B-24 EAP-FAST for Allow TLS Renegotiation You may be prompted to enter a password twice when you use an anonymous PAC provisioning schema. When you enter the password the first time, ACS provisions the PAC and sends an access-reject to the client. The client is then prompted to re-enter the password so that they will be able to authenticate and be granted access to the network. ACS checks for a TLS client handshake record. If it finds the TLS client handshake record, ACS will initiate a TLS renegotiation at the end of EAP-Fast phase zero, instead of rejecting the user’s request for access. You should use this option with a Vista client when the host is using anonymous PAC provisioning. Vista client do not save the user password in the cache, so you are allowed to enter the password once. When this option is enabled, ACS initiates the TLS renegotiation request to the client at the end of EAP-FAST phase zero, instead of rejecting the access attempt after PAC provisioning. EAP-FAST Flow in ACS 5.3. NoteYou 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 In-Band PAC Provisioning places different limits on user database support.
B-27 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-FAST To enable ACS to perform EAP-FAST authentication: Step 1Configure an identity store that supports EAP-FAST authentication. To determine which identity stores support EAP-FAST authentication, see Authentication Protocol and Identity Store Compatibility, page B-35. For information about configuring identity stores, see Chapter 8, “Managing Users and Identity Stores” Step 2Determine 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, page B-26. Step 3Determine whether you want to use automatic or manual PAC provisioning. For more information about the two means of PAC provisioning, see Automatic In-Band PAC Provisioning, page B-23, and Manual PAC Provisioning, page B-24. We recommend that you limit the use of Automatic In-Band 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 4Using the decisions during Step 2 and Step 3, enable EAP-FAST in the Global Systems Options drawer. See EAP-FAST, page B-18 for more information. ACS is ready to perform EAP-FAST authentication. NoteInner-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 8-4 Managing External Identity Stores, page 8-22 EAP-FAST PAC Management The EAP-FAST master-key in ACS is used to encrypt or decrypt, sign and authenticate the PACs and PAC-Opaques 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.3 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.
B-28 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-FAST 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, page B-28 EAP-FAST PAC-Opaque Packing and Unpacking, page B-28 Revocation Method, page B-28 PAC Migration from ACS 4.x, page B-29 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. Because of 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.
B-29 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP Authentication with RADIUS Key Wrap 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.3 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.3, 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 deployments A-ID of ACS 5.3. 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.3. 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 PACs-cipher assigned to each key. EAP Authentication with RADIUS Key Wrap You can configure ACS to use PEAP, EAP-FAST and EAP-TLS authentication with RADIUS Key Wrap. ACS can then authenticate RADIUS messages and distribute the session key to the network access server (NAS). The EAP session key is encrypted by using Advanced Encryption Standard (AES), and the RADIUS message is authenticated by using HMAC-SHA-1. Because RADIUS is used to transport EAP messages (in the EAP-Message attribute), securely authenticating RADIUS messages ensures securely authenticated EAP message exchanges. You can use RADIUS Key Wrap when PEAP, EAP-FAST and EAP-TLS authentication is enabled as an external authentication method. Key Wrap is not supported for EAP-TLS as an inner method (for example, for EAP-FAST or PEAP). RADIUS Key Wrap support in ACS uses three new AVPs for the cisco-av-pair RADIUS Vendor-Specific-Attribute (VSA); the TLV value of Cisco VSA is [26/9/1]): Random-Nonce—Generated by the NAS, it adds randomness to the key data encryption and authentication, and links requests and response packets to prevent replay attacks. Key—Used for session key distribution. Message-Authenticator-Code—Ensures the authenticity of the RADIUS message, including the EAP-Message and Key attributes. While using RADIUS Key Wrap, ACS enforces the use of these three RADIUS Key Wrap AVPs for message exchanges and key delivery. ACS will reject all RADIUS (EAP) requests that contain both RADIUS Key Wrap AVPs and the standard RADIUS Message-Authenticator attribute. To use RADIUS Key Wrap in PEAP, EAP-FAST and EAP-TLS authentications, you must enable the EAP authentication with RADIUS KeyWrap in the Network Devices and AAA Clients page or Default Network Device page. You must also define two shared secret keys for each AAA Client. Each key must be unique and be distinct from the RADIUS shared key. RADIUS Key Wrap does not support proxy functionality, and should not be used with a proxy configuration.
B-30 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-MSCHAPv2 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 users password. This section contains the following topics: Overview of EAP-MSCHAPv2, page B-30 EAP- MSCHAPv2 Flow in ACS 5.3, page B-31 Overview of EAP-MSCHAPv2 Some of the specific members of the EAP family of authentication protocols, specifically EAP-FAST and PEAP, support the notion of an “EAP inner method.” This means that another EAP-based protocol performs additional authentication within the context of the first protocol, which is known as the EAP outer method. One of the inner methods supported by the EAP-FAST and PEAP outer methods is EAP-MSCHAPv2, which is an adaptation of the MSCHAPv2 protocol that complies with the general framework established by EAP. Using EAP-MSCHAPv2 as the inner EAP method facilitates the reuse of Microsoft directory technology (such as Windows Active Directory), with the associated database of user credentials for wireless authentication in the following contexts: MSCHAPv2 for User Authentication, page B-30 MSCHAPv2 for Change Password, page B-30 Windows Machine Authentication Against AD, page B-31 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 you use EAP-MSCHAPv2 (as an EAP inner method) to authenticate a user whose password has expired, ACS sends a specific EAP-MSCHAPv2 failure notification to the client. 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.