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-1 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 APPENDIXB Authentication in ACS 5.3 Authentication verifies user information to confirm the users identity. Traditional authentication uses a name and a fixed password. More secure methods use cryptographic techniques, such as those used inside the Challenge Authentication Handshake Protocol (CHAP), OTP, and advanced EAP-based protocols. ACS supports a variety of these authentication methods. A fundamental implicit relationship exists between authentication and authorization. The more authorization privileges granted to a user, the stronger the authentication should be. ACS supports this relationship by providing various methods of authentication. Authentication Considerations Username and password is the most popular, simplest, and least-expensive method of authentication. The disadvantage is that this information can be told to someone else, guessed, or captured. Simple unencrypted username and password is not considered a strong authentication mechanism but can be sufficient for low authorization or privilege levels such as Internet access. You should use encryption to reduce the risk of password capture on the network. Client and server access-control protocols such as TACACS+ and RADIUS encrypt passwords to prevent them from being captured within a network. However, TACACS+ and RADIUS operate only between the AAA client and ACS. Before this point in the authentication process, unauthorized persons can obtain clear-text passwords; for example, in the following setups: The communication between an end-user client dialing up over a phone line An Integrated Services Digital Network (ISDN) line terminating at a network-access server Over a TELNET session between an end-user client and the hosting device Authentication and User Databases ACS supports a variety of user databases. It supports the ACS internal database and several external user databases, including: Windows Active Directory LDAP RSA SecurID Servers RADIUS Identity Servers
B-2 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 PAP This appendix describes the following: RADIUS-based authentication that does not include EAP: –PA P, p a g e B - 2 –CHAP, page B-31 –MSCHAPv1 –EAP-MSCHAPv2, page B-30 EAP family of protocols transported over RADIUS, which can be further classified as: –Simple EAP protocols that do not use certificates: EAP-MD5—For more information, see EAP-MD5, page B-5. LEAP—For more information, see LEAP, page B-31. –EAP protocols that involve a TLS-handshake and in which the client uses the ACS server certificate to perform server authentication: PEAP, using one of the following inner methods: PEAP/EAP-MSCHAPv2 and PEAP/EAP-GTC—For more information, see PEAPv0/1, page B-14. EAP-FAST, using one of the following inner methods: EAP-FAST/EAP-MSCHAPv2 and EAP-FAST/EAP-GTC—For more information, see EAP-FAST, page B-18. –EAP protocols that are fully certificate-based, in which the TLS handshake uses certificates for both server and client authentication: EAP-TLS—For more information, see EAP-TLS, page B-5. Certificate Attributes, page B-32 Machine Authentication, page B-34 Authentication Protocol and Identity Store Compatibility, page B-35 For a list of known supplicant issues, refer to http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.3/release/notes/ acs_53_rn.html. 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. NoteThe RADIUS with PAP authentication flow includes logging of passed and failed attempts.
B-3 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP 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 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.1A host connects to the network. Any communication protocol may be used depending on the host.3ACS uses an external identity store to validate the users credentials. 2The network device sends a RADIUS access request to ACS. 4The RADIUS response (Access-Accept or Access-Reject) is sent to the network device that will apply the decision. Host Network Device 2 4 1 External Identity Store3 210732 ACS Server
B-4 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP In ACS 5.3, 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. Ta b l e B - 1 lists the EAP codes for each type of EAP message. Ta b l e B - 2 describes the EAP methods that ACS 5.3 supports. Table B-1 EAP Codes EAP message type EAP code Accept-request 1 Response 2 Success 3 Failure 4 Table B-2 Supported EAP methods EAP Method Description EAP-MD5 Message Digest 5 Protocol. For more information see EAP-MD5, page B-5. LEAP Lightweight Extensible Authentication Protocol. PEAPv0v1 Protected Extensible Authentication Protocol version 0 and version 1. For more information see PEAPv0/1, page B-14. EAP-FAST EAP Flexible Authentication via Secured Tunnel (EAP-FAST) protocol. For more information see EAP-FAST, page B-18. EAP-MSCHAPv2 Microsoft Challenge Handshake Authentication Protocol version 2. For more information see EAP-MSCHAPv2, page B-30. EAP-GTC EAP Generic Token Card. EAP-TLS Extensible Authentication Protocol-Transport Layer Security. For more information, see Exporting Credentials, page B-11.
B-5 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-MD5 ACS supports full EAP infrastructure, including EAP type negotiation, message sequencing and message retransmission. All protocols support fragmentation of big messages. In ACS 5.3, you configure EAP methods for authentication as part of access service configuration. For more information about access services, see Chapter 3, “ACS 5.x Policy Model.” EAP-MD5 This section contains the following topics: Overview of EAP-MD5, page B-5 EAP- MD5 Flow in ACS 5.3, page B-5 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. EAP-MD5 is vulnerable to dictionary attacks when it is used over an open medium. This is because hackers are able to see the challenge and response. Since no server authentication occurs, it is also vulnerable to falsification. Related Topics Host Lookup, page 4-13 Overview of Agentless Network Access, page 4-12 EAP- MD5 Flow in ACS 5.3 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-13. Related Topics Authentication Protocol and Identity Store Compatibility, page B-35 Overview of Agentless Network Access, page 4-12 EAP-TLS This section contains the following topics: Overview of EAP-TLS, page B-6 EAP-TLS Flow in ACS 5.3, page B-13
B-6 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-TLS 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, page B-6 PKI Authentication, page B-7 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 8-68 Certificate-Based Network Access, page 4-9 ACS and Cisco Security Group Access, page 4-23 EAP-TLS Flow in ACS 5.3, page B-13 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. After 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.3 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.
B-7 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-TLS 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 8-69. 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 8-68 Certificate-Based Network Access, page 4-9 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.
B-8 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-TLS 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 EAP-MSCHAPv2 or EAP-GTC for the inner EAP method. Related Topics Configuring Local Server Certificates, page 18-14 Configuring CA Certificates, page 8-68 Configuring Certificate Authentication Profiles, page 8-73 PKI Credentials This section contains the following topics: PKI Usage, page B-8 Fixed Management Certificates, page B-9 Importing Trust Certificates, page B-9 Exporting Credentials, page B-11 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 not only the server, but also the client (PEAP and EAP-FAST also make use of certificates for server authentication, but do not perform client authentication). Other protocols which use the PKI credentials are LDAPS, HTTPS Management protocol, SSH, and SFTP. 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, and SSH, 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 Management protocol. For HTTPS, SFTP, SSH and ActiveMQ, an auto-generated self-signed certificates can be used as the means for server authentication.
B-9 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-TLS 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. You cannot modify or export these certificates. You can, however, assign imported certificates to management interfaces. 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 the X509 format and does not perform any hierarchical certificate signature verification. ACS also supports the Microsoft proprietary private key format. 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, page B-10 Initial Self-Signed Certificate Generation, page B-10 Certificate Generation, page B-10
B-10 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Appendix B Authentication in ACS 5.3 EAP-TLS 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 HTTPS Management protocol. NoteOnly EAP and HTTPS Management protocols can be configured in ACS 5.3 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, page B-9 Initial Self-Signed Certificate Generation, page B-10 Certificate Generation, page B-10 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 HTTPS Management protocols. The self-signed certificate is generated with the CN equal to the machine’s hostname, as required for HTTPS certificates, and is generated when ACS is installed. Certificate Generation You can 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 select any of these generated private-key lengths: 512, 1024, 2048 or 4096 bit. The certificate digest algorithm used by the ACS is SHA1 and SHA2 256-bit. NoteYou should install Windows XP SP3 to use SHA2 256-bit certificates as management certificates. 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 select any of these generated private-key lengths: 512, 1024, 2048 or 4096 bit. The certificate digest algorithm used by the ACS is SHA1 and SHA2 256-bit.