session_05_access_authentication_092008

session_05_access_authentication_092008 - Cryptography and...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Cryptography and Network Security TECH 6350 Session 5 Access Authentication Manuel Mogollon m_mogollon@verizon.net Graduate School of Management Information Assurance University of Dallas 0 Session 5 – Contents • Authentication Concepts • IEEE 802.1X Authentication • Extensible Authentication Protocol (EAP) • EAP Password Mechanisms • Other Password Mechanisms • Password Security Considerations • EAP Authentication Servers • Remote Authentication Dial-in User Service (RADIUS) • The Needham-Schroeder Protocol, Kerberos V5.1 • ITU-T X.509 IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 1 • Unless a corporation can reliably authenticate its network users, it is not possible to keep unauthorized users out of its networks. Authentication is essential for two parties to be able to trust in each other’s identities. Authentication is based on something you know (a password), on something you have (a token card, a digital certificate), or something that is part of you (fingerprints, voiceprint). A strong authentication requires at least two of these factors. The following mechanisms of authentication are described in this session: (1) IEEE 802.1X Access Control Protocol; (2) Extensible Authentication Protocol (EAP) and EAP methods; (3) Traditional passwords; (4) Remote Authentication Dial-in Service (RADIUS); (5) Kerberos authentication service; and (6) X.509 authentication. • Objectives • Understand the IEEE 8021X and EAP methods of authentication. • Learn how RADIUS is used to authenticate dial-in users. • Understand how the Kerberos service is used to provide authentication and authorization to a user. • Learn how X.509 provides user authentication. 1 Security Concerns • Browsing — The attacker tries to get access to a database to get information. • Spoofing — The attacker pretends to be a user with certain privileges. • Session Hijacking — The attacker tries to take over an existing connection between two computers. • Electronic Eavesdropping or Sniffing — The attacker records all the traffic going through the network interface card (NIC) or on a server node. • Exhaustive Attacks — The attacker tries to identify secret information by testing all possibilities. Also called Brute Force Attack. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 2 2 What is Authentication? authentication / n. (1) The act of identifying or verifying the entity that originated the message or the corroboration (proof) of the sender's identity, i.e. that he is who he claims to be. Written messages are authenticated with a handwritten signature so the receiver of the message is able to validate the message. (2) access. The act of identifying or verifying the eligibility of a station, originator or individual to access specific categories of information. Longley, D., & Shain, M. (1989). Data & Computer Security Dictionary of Standards Concepts and Terms (p26). Boca Raton, FL:CRC Press, Inc. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 3 • The OSI Security Architecture (ISO 7498-2) describes two types of authentication: data origin authentication and peer entity authentication. • Data origin authentication is the act of identifying or verifying the entity who originates a message (entity authentication), or the corroboration (proof) of the sender's identity and authentication that he is who he claims to be (data origin authentication). • In this session, we will discuss peer entity authentication. 3 Access Authentication Dial-up User Authentication PSTN Device Authentication NAS VoIP Home office Internet, IPWAN Router Authentication Server Router User Authentication Firewall Router Wireless Access Authentication IEEE 802.1X EAP Methods Intranet Access Authentication • Dial-up User Authentication • Wireline User Authentication. • Wireless User Authentication • Device Authentication. Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 4 • Authentication has been used to verify that an individual is authorized to access property, resources, and information. In today’s communications, users access information from everywhere; for example, individuals can travel with their laptops and IP phones and are able to access their networks and receive phone calls as if they were at their offices. There is an increasing demand to provide strong authentication for users, devices, and applications across all type of networks. • Ideally, a subject’s identity should be initially established and verified at a specified point in the network, and some type of credentials that assert the subject’s identity should be given to the subject by the authenticator. When access to several networks or Web domains are involved in a transaction, the subject should be able to show credentials and assertions to other networks or Web domains to prove his identity to complete transaction. This requires making the assertion portable. For example, in Web services, the Security Assertion Markup Language (SAML) allows users to gain access to different resources in multiple domains without having to re-authenticate after initially logging into the first domain. • Regardless of whether the authentication can be made portable, or if authentication is at the access point or end-to-end, or if individuals and or devices are authenticated, secure and trusted networks require strong authentication. This means that people and devices are reliably identified so transactions can be conducted without compromise. 4 Access Authentication The prevention of the unauthorized use of a resource. Access Authentication Protocol EAP Method IEEE 802.1X Mechanism EAP-TLS EAP-SIM CHAP OTP EAP-TTLS EAP-AKA GTC MS-CHAP v2 EAP-PEAP EAP-PSK Digital Certificates IEEE 802.1X: Port-based Access Control Protocol EAP: Extensible Authentication Protocol PEAP: Protected EAP CHAP: Challenge-Handshake Authentication Protocol TLS: Transport Layer Security TTLS: Tunneled Transport Layer Security OTP: One-Time Password GTC: Generic Token Card IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 5 • For the purpose of providing authentication and authorization mechanisms for devices connected to a network, it is necessary to establish the following: • An authentication protocol between the devices that require authentication, i.e. the client/supplicant and the authenticator. • An authentication method used between the authenticator and an authentication server. • An authentication mechanism to carry the access control that authenticates a client or supplicant. 5 Authentication Factors • What the user knows — Something secret only the user knows – A memorized personal identification number (PIN) or password • What the user has — Something unique the user possesses – SecureID card (token generating a one-time password) – A smartcard that can perform cryptographic operations on behalf of a user). – Digital certificate • What the user has — Something unique to the user — Biometrics (Fingerprints, voiceprint) IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 6 • Authentication is the process of reliably verifying the identity of a user or device and should not to be confused with identification, which is only an assertion of identity. Authentication is usually a prerequisite to authorization since entitlements depend upon verifying the identity of the user. • User authentication is usually based on one or a combination of the following: • What the user knows – passwords. • What the user has – tokens, smart cards, digital certificates, etc… • What personal identifier the user has – biometrics. • When passwords are used to authenticate a user, there are certain limitations on the length of the password because the user will have to memorize it, and writing the password is not recommended. Because of this limitation, the level of security offered by passwords is very low. The level of security could be increased by using two or three factor authentication, e.g., passwords and tokens, or passwords, tokens and biometrics. • A Network Access Control (NAC) based device for authentication ensures that unauthorized devices are not connected to the network, even when operated by an authorized user. For example, an authorized user cannot access the network from an unauthorized PC at home or at a kiosk. Also, if a user’s password or token has been compromised, the network is still protected because the attacker needs to use an authorized device to access the network. Device authentication is also used when two network devices, e.g., two switches or routers, authenticate each other. Device-to-device authentication is not constrained by the need to remember passwords. Encryption keys can be used to provide strong authentication. • Device authentication provides the following benefits: • Provides identity information for electronic devices connected to the network • Adds another layer of protection by establishing control regarding the equipment connected to the network. • Increases the device’s trustworthiness. 6 Access Authentication vs. Authorization • Access Authentication — Defines whether Access-Accept or Access-Reject is returned by the authenticator server. • Authorization — Defines user’s environment once access is granted. — Controls or restricts what user is allowed to do on a network access server (NAS) or network. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 7 7 IEEE 802.1X Authentication • The IEEE 802.1X-2004 is a data link layer transport protocol that defines wireless and physical networks port-access control standards. — Port access refers to “user port” access controlled by a wireless access point or wired switch. Users do not get IP-connectivity until they have successfully authenticated. • IEEE802.1X deployment requires the installation of three components: — Supplicant authentication software and hardware. — Authenticator – 802.1X EAP compatible. — Authentication Server. In IEEE 802.11, the Access Point acts as an authenticator, while a wireless station (e.g., a laptop) is the supplicant. A Port Access Entity (PAE) is an entity that is able to control the authorized/unauthorized state of its controlled port. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 8 • The IEEE 802.1X-2004 is a data link layer transport protocol that defines port-access control standards for wireless and physical networks. The extensible authentication protocol is used to carry for authentication credentials. Within this framework, port access refers to user port access controlled by a wireless access point or wired switch. Users do not get IP-connectivity until they have successfully authenticated. • IEEE802.1X (Institute of Electrical and Electronic Engineers (IEEE), 2004) deployment requires the installation of three components, which are the same three main components for EAP: the supplicant, the authenticator, and the authentication server. 1. Supplicant authentication software and hardware. They run on a device that requires authentication. The network adapter needs to be 802.1X-compatible. 2. Authenticator 802.1X EAP compatible. The authenticator is nothing more than a gateway. Its function is to convert the supplicant’s EAP packets from 802.1X to RADIUS format and pass the packets to the authentication server. It also converts the authentication server’s EAP packets from RADIUS format to 802.1X and passes the packets to the supplicant. The authenticator should not only be 802.1X EAP compatible, but also should be compatible with the authentication method the system is using. 3. Authentication Server. The authentication server needs to support EAP. Usually the authentication server is a RADIUS, although 802.1 X does not specify RADIUS. The authentication server also needs to support: (1) The inner authentication method for TTLS and PEAP, if these methods were selected; (2) The database, LDAP server, or Windows 2000; (3) The platform operating system, UNIX or Windows. • In IEEE 802.1X, the access point acts as an authenticator, while a wireless station (e.g., a laptop) is the supplicant. A Port Access Entity (PAE) is an entity that is able to control the authorized/unauthorized state of its controlled port. 8 802.1X Port-based Access Control Protocol Authentication Server System Authentication System Services offered by the authenticator system Controlled Port Authenticator Port Access Entity Port Unauthorized Authentication Server Uncontrolled Port Authentication Protocol Exchanges AuthControlledPortStatus MAC Enable/Disable LAN IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 9 • The authenticator uses a dual-port model with two ports, the uncontrolled port and the controlled port. The uncontrolled and controlled ports have the same point of attachment to the LAN. Any access to the LAN is subject to the current administrative and operational state of the MAC (or logical MAC) associated with the port, in addition to Auth_Controlled_Port_ Status. If the MAC is physically or administratively inoperable, then no protocol exchanges of any kind can take place using that MAC on either the controlled or the uncontrolled port. • Connection through the uncontrolled port access allows uncontrolled exchange of data information between the authenticator and the client on the LAN, regardless of the authorization state (the uncontrolled port). The uncontrolled port filters all network traffic and allows only EAP packets to pass. Authentication occurs when a supplicant is connected to an authenticator’s port. Until authentication has been successfully completed, the supplicant only has access to the authenticator to perform authentication exchanges. Depending on the result of the authentication process, the authenticator can determine whether or not the supplicant is authorized to access its services on that controlled port. A possible outcome is that when the supplicant is successfully authenticated, its traffic is directed to a particular virtual LAN (VLAN). If the supplicant is not authorized for access, the authenticator sets the controlled port state to “unauthorized.” In the unauthorized state, the use of the controlled port is restricted, thus preventing unauthorized data transfer between the supplicant and the services offered by the authenticator. In order to perform the authentication, the authenticator makes use of an authentication server. 9 EAP Stack Auth. Layer Connection and Login Process Protection Layer TLS Method Layer PEAP TTLS Extensible Authentication Protocol (EAP) EAP Layer EAP over LAN (EAPOL) PPP EAP Methods 802.5 Ethernet IEEE 802.1X 802.3 Token Ring Passwords Radius Media Layer 802.11 Wireless LAN Kerberos X.509 M. Mogollon – 01/08 - 10 • As an authentication protocol, 802.1X can be used in Ethernet, Token Ring or wireless LAN. • IEEE 802.3 is the IEEE standard defining the physical layer and transport layer of (a variant of) Ethernet. • IEEE 802.5 Token Ring standards. • IEEE 802.11 or Wi-Fi denotes a set of Wireless LAN standards developed by working group 11 of IEEE 802. 10 Extensible Authentication Protocol • Originally created for use with PPP, it has since been adopted for use with IEEE 802.1X -2004 "Port-Based Network Access Control". • EAP is extensible because any authentication mechanism can be encapsulated within EAP messages. • EAP allows the deployment of new protocols between the supplicant and the authentication server. — The encapsulation technique used to carry EAP packets between peer and authenticator in a LAN environment is known as EAP over LANs, or EAPOL • Supports authentication mechanisms such as smart cards, Kerberos, digital certificates, one-time-passwords, and others. — • Authentication mechanisms are implemented in a number of ways called EAP methods, e.g., EAPTLS, EAP-TTLS, EAP-PEAP, etc. Authentication Mechanisms — MD5-Challenge: Analogous to the PPP CHAP protocol with MD5 as the specified algorithm, RFC 1994. The Request contains a "challenge" message to the peer. — One-Time Password (OTP): Defined in "A One-Time Password System," RFC 1938. The Request contains a displayable message containing an OTP challenge. — Generic Token Card (GTC): Defined for use with various token card implementations which require user input. The Request contains an ASCII text message and the Reply contains the token card information necessary for authentication. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 11 • PPP is part of Layer 2 Tunneling Protocol that encapsulates IP, as well as IPX packets, between the sender and the receiver. It is the dial-up protocol most commonly used to access the Internet and other TCP/IP networks. In the early 90s, it was mostly used for dial-up Internet access protocol. Now, PPP is used by some Internet service providers as PPP over Ethernet for DSL and for cable modem authentication. • The Password Authentication Protocol, PAP, is used as the authentication method with a Pointto-Point Protocol. With PAP, a peer sends his ID and password in clear; this makes the protocol a less secure system – nothing protects against playback attacks. In order to provide more robust authentication, the IETF defined a new authentication protocol called the Extensible Authentication Protocol (EAP) in RFC 2284. The protocol is extensible in the sense that any authentication mechanism can be encapsulated within EAP messages. • The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication which supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism at the Link Control Phase, but rather allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "back-end" server, which actually implements the various mechanisms, while the PPP authenticator merely passes through the authentication exchange. 11 EAP Authentication Process Authentication Server Radius, Kerberos, PKI, OTP, Token Authenticator EAP over Ethernet EAP Method Password Authentication Database The Authenticator functions as an AAA client to the Authentication Server Token Authentication Database X.509 Directory Kerberos Ticket Granting Server Supplicants AAA – Authentication, Authorization and Accounting IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 12 • The process of authenticating a user or device involves the following parties and protocols: 1. The supplicant is an entity at one end of a point-to-point LAN segment that is being authenticated by an authenticator attached to the other end of that link. 2. The authenticator is an entity at one end of a point-to-point LAN segment that enables authentication of the entity attached to the other end of that link, the supplicant. 3. The 802.1X port-based network access control protocol provides the means to authenticate and authorize devices attached to a LAN port that has point-to-point connection characteristics; it can also prevent access to that port in cases in which the authentication and authorization process fails. 4. An EAP authentication method such as EAP-TLS, EAP-TTLS, EAP-PEAP, etc., provides specific authentication mechanisms between the client and the authentication server. The choice of method often implies a choice of mechanisms. 5. An authentication mechanism such as one-time passwords, token cards, biometrics, Kerberos, pre-shared keys, or digital certificates, authenticates a client or supplicant. 6. An authentication server performs the authentication function necessary to check the credentials of the supplicant on behalf of the authenticator and indicates whether the supplicant is authorized to access the authenticator’s services. An AAA server checks • Who are you (Authentication) • What are you allowed to do (Authorization) • What you actually do (Accounting) 12 EAP Certificate and Hybrid Methods • Certificate Method — EAP-TLS: The Extensible Authentication Protocol-Transport Layer Security uses X.509 digital certificates for secure mutual authentication client and server. • EAP Hybrid Methods — EAP-TTLS (Tunneled TLS): Based on asymmetric cryptography reusing TLS mechanisms. In EAP-TTLS, the TLS handshake can be mutual, or it can be one-way, in which only the server is authenticated to the client. — PEAP (Protected Extensible Authentication Protocol): Based on asymmetric cryptography reusing TLS mechanisms. Provides an encrypted and authenticated tunnel based on transport layer security (TLS) that encapsulates EAP authentication mechanisms. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 13 • EAP-TLS leverages X.509 digital certificates for secure mutual authentication using digital signatures but requires client-side and server-side certificates to perform authentication. It ensures authenticity, message integrity, and non-repudiation. It is generally appropriate for enterprises that have already deployed a PKI infrastructure. EAP-TLS is an experimental RFC. • The tunneled methods, TTLS and PEAP, offer message integrity so no one can interfere with the authentication and confidentiality by using encryption. • The following are some of the advantages of tunneled and protected EAP: • Offers message integrity by using encryption so no one can interfere with authentication and confidentiality. • Has simple deployment because it requires only a server certificate. • Can be used in inner tunnel to protect existing authentication methods. • Protects user identity because no client ID is exchanged until a TLS secure channel is established. • Uses mutual authentication, TLS for the client and legacy authentication for the server. • PEAP uses TLS to protect against rogue authenticators and against attacks on the confidentiality and integrity of the inner EAP method exchange; it also provides EAP peer identity privacy. • In summary, PEAP and TTLS are very similar. Both are not as secure as TLS, but they have the advantage of being able to use username/password authentication instead of certificate authentication for backward compatibility with legacy authentication methods. PEAP only allows EAP methods for client authentication whereas TTLS allows any method, including PAP and CHAP. Another difference is the way payload encoding is done; whereas TTLS uses the TLS channel to exchange Attribute-Value Pairs (AVP), much like RADIUS, PEAP uses type-length-value. Thus, TLS is EAP friendly and TTLS is better aligned with RADIUS. PEAP-EAP-MS-CHAPv2 requires that the client trust certificates provided by the server. 13 Protected EAP Cipher Suite Cipher Suite Services offered by the authenticator system LAN, Wireless Authenticator (Dual Port) Trust Keys EAP Methods, EAP-TLS, EAP-GTC, MS-CHAPv2 Client Authenticator with Controlled Port Disabled. EAP API EAP Method • Authentication Server EAP API EAP Method First a TLS tunnel ( ) is established, and then the tunnel is used to run legacy authentication protocols in the inner tunnel ( ). IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 14 • The slide shows the Authenticator’s port to the services offered in unable state. If access is authenticated, the Authentication Server informs the Authenticator, which enables the port to the services offered. • In order for the conversation to proceed in the case where the Authenticator and Authentication Server reside on separate machines, the Authenticator and Authentication Server need to establish trust beforehand. • When the authentication server accepts authentication, the authenticator switches port assigned to VLAN & service class. 14 EAP SIM-Based Methods • EAP-AKA (Authentication and Key Agreement): — Based on the 3rd generation authentication and key agreement mechanism (AKA) specified for Universal Mobile Telecommunications System (UMTS) and for cdma2000. — Based on challenge-response mechanisms and symmetric cryptography. It uses shared secrets between the user and the authenticator together with a sequence number to perform the authentication. — EAP-AKA uses AES with a 128-bit key in the cipher block chaining (CBC) mode of operation. It uses SHA-1 to check the integrity of all EAP-Request/AKA-Identity and EAP-Response/ AKAIdentity packets used in the authentication exchange. It also uses SHA-1 to create the master key by hashing certain concatenated parameters. EAP-AKA is defined in RFC 4187. • EAP-SIM (Subscriber Identity Module) — Based on symmetric cryptography that reuses the GSM authentication infrastructure. — Useful for scenarios where SIMs are already deployed (e.g., authentication of GPRS clients on a WLAN connected to a 3GPP network). — The lack of mutual authentication is a weakness in GSM authentication. Also, the derived 64-bit cipher key (Kc) is not strong enough for use in data networks for which stronger and longer keys are required. To overcome the key size problem, several RAND challenges are used for generating various 64-bit Kc keys, which are combined to get longer keys. EAP-SIM is defined in RFC 4186 (Haverinen, & Salowey, 2006). IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 15 EAP SIM-based Methods • EAP-AKA: Authentication and key agreement is an EAP method based on the 3rd generation authentication and key agreement mechanism (AKA) specified for Universal Mobile Telecommunications System (UMTS) and for cdma2000. AKA typically runs in a UMTS Subscriber Identity Module (USIM) or a cdma2000 (Removable) User Identity Module ((R)UIM). It could be used without a USIM (e.g., with a software-based virtual USIM), thus becoming a generic shared-key EAP method. • EAP-AKA is based on challenge-response mechanisms and symmetric cryptography. It uses shared secrets between the user and the authenticator together with a sequence number to perform the authentication. EAP-AKA uses AES with a 128-bit key in the cipher block chaining (CBC) mode of operation. It uses SHA-1 to check the integrity of all EAP-Request/AKA-Identity and EAP-Response/ AKA-Identity packets used in the authentication exchange. It also uses SHA-1 to create the master key by hashing certain concatenated parameters. EAP-AKA is defined in RFC 4187. • EAP-SIM: The Subscriber Identity Module is an EAP method based on symmetric cryptography that reuses the GSM authentication infrastructure. The lack of mutual authentication is a weakness in GSM authentication. Also, the derived 64-bit cipher key (Kc) is not strong enough for use in data networks for which stronger and longer keys are required. To overcome the key size problem, several RAND challenges are used for generating various 64-bit Kc keys, which are combined to get longer keys. EAPSIM is defined in RFC 4186. • EAP-SIM could be implemented for backward compatibility with the millions of GSM/GPRS SIM cards already deployed. However, since AKA architecture for the UMTS includes mutual authentication, replay protection, and derivation of longer session keys, EAP-AKA, which is a more secure protocol, may be used instead of EAP-SIM, if 3rd generation identity modules and 3G network infrastructures are available. 15 EAP Pre-Shared Key Methods • EAP-TLS-PSK: TLS Pre-Shared Key — A possible future EAP method based on TLS that would support authentication based on preshared keys. — TLS-PSK uses one of the following: – 1. Symmetric key operations for authentication; – 2. Diffie-Hellman exchange authenticated with a pre-shared key; – 3. Combined public key authentication of the server with pre-shared key authentication of the client. • EAP-IKEv2: — Based on the symmetric and asymmetric cryptography of IKEv2, a protocol whose security has received considerable expert review. — Could be an excellent candidate to replace EAP-MD5. • EAP-PSK (Pre-Shared Key) — Based on symmetric cryptography. — Advantages: – Simplicity: Easy to implement and to deploy without any pre-existing infrastructure. – Wide applicability: Can be used to authenticate over any network, in particular for WLANs. – Security: Based on AES. – Extensibility: Can add extensions as needed. – Patent-avoidance: No Intellectual Property Right claims. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 16 EAP Pre-Shared Key Methods • • • EAP-TLS-PSK: This EAP method based on TLS that supports authentication based on pre-shared keys. The TLS-PSK, RFC 4764 (Bersani, & Tschofenig, 2007), describes methods for using symmetric keys, also called pre-shared keys or PSKs, shared in advance among the communicating parties, to establish a TLS connection. TLS-PSK uses one of the following: 1. Symmetric key operations for authentication; 2. Diffie-Hellman exchange authenticated with a pre-shared key; or 3. A combination of the public key authentication of the server with pre-shared key authentication of the client. EAP-IKEv2 is based on the symmetric and asymmetric cryptography of IKEv2. Its main advantages are that it uses the IKEv2 standard protocol, RFC 4306. EAP-IKEv2 also provides support for cryptographic ciphersuite negotiation, has hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional fast reconnect mode. Currently, IKEv2 supports authentication techniques that are based on passwords, high-entropy shared keys, and public-key certificates. EAPIKEv2 might not be an appropriate EAP method under certain circumstances because DH computations and potential server side authentication make EAP-IKEv2 computationally expensive. Whereas in TLSPSK, DH exchange is optional, in EAP-IKEv2, it is not the case. EAP-PSK: EAP pre-shared key is an EAP method based on symmetric cryptography defined in RFC 4764. Some of the advantages it has are the following: • Simplicity: It is easy to implement and to deploy without any pre-existing infrastructure. EAP-PSK uses only AES-128. • Wide applicability: It is possible to use this method to authenticate over any network. In particular, it complies with IEEE 802 EAP method requirements for wireless LANs. • Security: It is based on AES. • Extensibility: It is possible to add to this method any required extensions as needed. 16 Password-Based EAP Methods • EAP-PAX — Designed for device authentication using a shared key, a personal identification number (PIN). Instead of using a symmetric key exchange, the client and server perform a Diffie-Hellman key exchange, which provides forward secrecy. — Supports the generation of strong key material; mutual authentication; resistance to desynchronization, dictionary, and man-in-the-middle attacks; ciphersuite extensibility with protected negotiation; identity protection; and the authenticated exchange of data, useful for implementing channel binding. EAP-PAX is ideal for wireless environments such as IEEE 802.11. • EAP-SPEKE (Simple Password Exponential Key Exchange) — Based on symmetric cryptography and asymmetric key cryptography to provide password-only authenticated key exchange. — Useful only when authentication is based on user-provided password information. — Unnecessarily complex for device authentication (e.g., it makes heavy use of public key cryptography). — Improved protocol supports mutual authentication and key exchange and it works on the Elliptic Curve Cryptosystems (ECC) base, as well as the DH (Diffie-Hellman) base. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 17 • EAP-PAX: The EAP Password Authenticated Exchange, RFC 4746 (Clancy, & Arbaugh, 2006), is an EAP method designed for device authentication using a shared key and a personal identification number (PIN). Instead of using a symmetric key exchange, the client and server perform a Diffie-Hellman key exchange, which provides forward secrecy. EAP-PAX uses two separate subprotocols, PAX_STD and PAX_SEC. PAX_STD is a simple, lightweight protocol for mutual authentication using a shared key, supporting authenticated data exchange (ADE). PAX_SEC uses public key. In the weakest mode, PAX_SEC allows the use of raw public keys, eliminating the need for a PKI. In the strongest mode, PAX_SEC requires that EAP servers use certificates signed by a trusted Certification Authority (CA). EAP-PAX supports the generation of strong key material; mutual authentication; resistance to desynchronization, dictionary, and man-in-the-middle attacks; ciphersuite extensibility with protected negotiation; identity protection; and the authenticated exchange of data, useful for implementing channel binding. EAP-PAX is ideal for wireless environments such as IEEE 802.11. • EAP-SPEKE (Simple Password Encrypted Key Exchange): This is an EAP method based on symmetric cryptography and asymmetric key cryptography to provide password-only authenticated key exchange. EAP-SPEKE is only useful when authentication is based on userprovided password information. It is unnecessarily complex for device authentication (e.g., it makes heavy use of public key cryptography). The improved EAP-SPEKE protocol supports mutual authentication and key exchange and it works on the Elliptic Curve Cryptosystems (ECC) base, as well as the DH (Diffie-Hellman) base. 17 Road to Authentication Step 1 (Note 1) Step 2 EAP Method Step 3 Authentication Mechanism 802.1X Port-Based Network Control EAP-AKA EAP-SIM Yes Pre-Shared-Keys EAP-PAX EAP-SPEKE No EAP-TLS-PSK EAP-IKE v2 EAP-PSK Passwords PEAP EAP Methods, EAPTLS, EAP-GTC, MSCHAPv2 EAP-TTLS EAP Methods, CHAP, PAP, MS-CHAP and MS-CHAPv2. EAP-TLS Public-Key Certificates SIM-based Client Certificate RSA / ECC Client and Server Certificates (Note 2) No, Only Server Yes (Note 3) Note 1: Strong Access Control protocol. Must be coupled with a secure EAP method. Note 2: No need to issue certificate to the client Note 3: Both the client and the server must be assigned a digital certificate signed by a certificate authority. Requires PKI IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 18 • Where EAP messages are not encrypted, it must be assumed that an attacker could be passively listening during the EAP exchange or act as a man-in-the-middle. Therefore, EAP methods must not leak secret or sensitive information (e.g. passwords or password hashes, as in the case of EAP-MD5). When selecting an EAP method, it is necessary to consider the fact that EAP transmits identity in clear; consequently, it is possible for an attacker to learn the identity of authenticating users. Password compromise should be avoided by using EAP methods that employ strong encryption. • Another consideration when selecting an EAP method is to determine if the authentication mechanism will use either pre-shared keys, or keys that are created and exchanged during the authentication process using public keys and digital certificates. • When selecting an EAP method, consideration must be given to whether mutual or one-way authentication is required. In a rogue attack, the attacker replaces the device with a suitably modified one. This attack can be prevented by using an EAP method that supports mutual authentication and that indicates whether mutual authentication has been completed. It is also necessary to have the supplicant refuse to process an EAP success received prior to that indication. 18 EAP Key Material • User authentication protocols perform two functions: — Verifying the identity of one or both parties, and — Producing ephemeral secret keys shared between the parties that are used subsequently for data origin authentication. • During authentication, key material is transported or agreed to. — In key transport, both parties share a key-encrypting key that is used to wrap (encipher) the key that is going to be transported - exchanged. — A key agreement algorithm allows two parties to generate a secret key computed from public key algorithms such as Diffie-Hellman. • Exchanged or generated keys are used to generate key material. • In EAP, the following keys are derived: Master Session Key (MSK), Extended Master Session Key (EMSK), AAA Key, Application-Specific Master Session Keys (AMSK), Transient Session Keys (TSK), Initialization Vector (IV), and Transient EAP Keys (TEK) • The MSK is used to derive the AAA Key; the AAA Key is used to derive the Transient Session Keys (TSKs), and the TSKs are used to protect data. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 19 • User authentication protocols perform two functions: 1. Verifying the identity of one or both parties, and 2. Producing ephemeral secret keys shared between the parties and that are used subsequently for data origin authentication. • During authentication, key material is transported or agreed to, and this key material is used to authenticate and, possibly, to encrypt data transmitted between the device and the network. In key transport, also called key exchange or key wrapping, both parties share a key-encrypting key that is used to wrap (encipher) the key that is going to be transported, exchanged. A keyagreement algorithm allows two parties to generate a secret key computed from public-key algorithms such as Diffie-Hellman. Regardless if the key is exchanged or generated, normally the key is not used to encrypt messages, but, rather, to arrive at key material. The steps required to generate a key used to encrypt the message depends on the protocol. • In EAP, the following keys are derived: Master Session Key (MSK), Extended Master Session Key (EMSK), AAA Key, Application-specific Master Session Keys (AMSK), Transient Session Keys (TSK), Initialization Vector (IV), and Transient EAP Keys (TEK). • The MSK is used to derive the AAA Key; the AAA Key is used to derive the TSKs, and the TSKs are used to protect data. 19 EAP Password Mechanisms • Legacy authentication systems are based on passwords or token-based authentication systems. • EAP is used with legacy authentication systems by first establishing a secure tunnel (e.g. TLS), and then using that tunnel to run the legacy authentication protocols, so the authentication is running in an inner tunnel. • Two EAP methods, TTLS and PEAP, have been proposed to support legacy authentication systems. — EAP-TTLS supports all EAP methods, CHAP, PAP, MS-CHAP, and MS-CHAPv2. — EAP-PEAP supports all EAP methods, as well as EAP-TLS, EAPGTC, MS-CHAPv2. PAP and CHAP are not recommended for use as authentication methods with EAP-PEAP. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 20 • The use of EAP-TLS requires digital certificates for authentication. Digital certificates provide strong methods of authenticating, but they can require a public-key infrastructure (PKI). Rather than deploying a PKI, or using EAP methods based on pre-shared keys, the use of legacy authentication systems, based on passwords, or token-based authentication systems is still preferred. • A way to use EAP with legacy authentication systems is to first establish a secure tunnel (e.g., TLS), and then to use that tunnel to run the legacy authentication protocols, so the authentication is running in an inner tunnel. • Two EAP methods, TTLS and PEAP, have been proposed to support legacy authentication methods. • The EAP-TTLS supports all EAP methods, as well as CHAP, PAP, MS-CHAP, and MSCHAPv2. • EAP-PEAP supports all EAP methods, EAP-TLS, EAP-GTC, and MS-CHAPv2. PAP and CHAP are not recommended for use as authentication methods with EAP-PEAP. 20 EAP PEAP with MS-CHAP-v2 Authenticator Client Request Identity Message Client or Computer Identity Authenticator Challenge (16-octet random number) Client Challenge Response (24-octet) Client Challenge (16-octet random number) Success Message Response to Client Challenge Ack Message Success Message The entire authentication exchange is encrypted The entire authentication exchange is encrypted through the TLS channel created in PEAP through the TLS channel created in PEAP IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 21 • The EAP MS-CHAP-v2 protocol is based on Microsoft MS-CHAP-v2. The authentication mechanism is password-based and supports mutual authentication. Integrity is supported but confidentiality is not. The name field, in both the challenge and response packets, is sent in the clear. While key derivation is supported, the key strength is limited by the password policy. • The EAP PEAP with MS-CHAP-v2 authentication process occurs in two parts. First an encrypted TLS channel is established and second a mutual authentication is established using MS-CHAP-v2. • The Authenticator and Client challenges are random numbers in a 24-octet format. • The Client Response to the Authenticator’s challenge is an encoded function of the Password, User Name, Authenticator Challenge, and Client’s challenge, and Password Hash. • The Authenticator’s response to the Client’s challenge is an encoded function of the Password, Client Response, Peer Challenge, Authenticator Challenge, User Name, Password hash. 21 EAP Generic Token Card (GTC) Access Control Server Encipher with Key Seed User’s Key Database PIN Seed Same Encipher with Key Token User IEEE 802.1X Authenticator EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 22 • The generic token card is defined for use with various token card implementations that require user input. The use of EAP-GTC was standardized in EAP RFC 3748 (Aboba, Blunk, Vollbrecht, Carlson, & Levkowetz, 2004). EAP-GTC allows the exchange of cleartext passwords and token information across the network. However, because of the GTC two-factor authentication, this method is not vulnerable to a replay attack. Even though EAP-GTC can be used by itself and does not need to be tunneled, it is recommended that it be used inside of TTLS or PEAP to provide server authentication. • Generic token cards are dynamic in the sense that the information that they display changes in time, i.e., every 60 seconds. Each end user is assigned a token, which is bonded to the user’s PIN. The user logs into the system by entering his PIN and the pass code from the token. • Generic token cards are dynamic in the sense that the information that they display changes in time, i.e., every 60 seconds. Each end user is assigned a token, which is bonded to the user’s PIN. The user logs into the system by entering his PIN and the pass code from the token. The server gets the user’s key from the database, computes the token value, and compares it with the token value entered by the user. If the value is correct, access is granted; if incorrect, the user is allowed to try again for certain number of times. After x failed attempts, the user should be locked out until the administrator reenables the user access. • Time synchronous is a two-factor authentication based on something the user knows (a password or PIN), and something he has, a time synchronizing token such as RSA SecureID. 22 EAP One-Time Password (OTP) Seed and Challenge numbers User’s secret pass-phrase or PIN Concatenate Network Access Server Hash Function Seed and Challenge numbers Concatenate Same User’s secret pass-phrase or PIN Database Hash Function One-Time Password One-Time Password Systems • New password required for each session. • IETF standardized OTP in RFC 2289. • Difficult to administer the secret pass-phrase list and, therefore, not very scalable. Secret pass-phrase and seed are hashed the number of times to be equal to the Challenge number and then become a One-Time Password. User IEEE 802.1X Authenticator EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 23 • The RFC 2289 describes the procedure as follows: 1. The authenticator, a network access server, sends a seed and a challenge number, N, to the user. 2. The user’s pass phrase is concatenated with a seed that is transmitted from the server in clear text. This non-secret seed allows clients to use the same secret pass-phrase on multiple machines (using different seeds) and to recycle safely their secret pass-phrases by changing the seed. 3. A sequence of one-time passwords is produced by applying the secure hash function multiple times to the output of step 2 (called S). That is, the first one-time password to be used is produced by passing S through the secure hash function the number of times (N) specified by the authenticator challenge number. The next one-time password to be used is generated by passing S though the secure hash function N - 1 times. An eavesdropper who has monitored the transmission of a one-time password would not be able to generate the next required password because doing so would mean inverting the hash function. • The authenticator server gets the user’s pass-phrase from the database, concatenates the user pass-phrase with his seed, and applies the one-way hash function. If the hashed password matches, the user is allowed to log in. All pass-phrases must be of at least 63 characters. 23 Password Security Considerations • Passwords are prearranged identifiers that the user possesses, such as words, special coded phrases, personal identification numbers (PINs), etc. • Password systems require a single coded response from the user to be allowed access to the host computer. • When writing a password policy, organizations should consider the following: — — — — How the password will be selected How often the password will be changed How long the password will be used How the system will handle (transmit) the password • Users normally choose unsatisfactory or poor passwords, such as words from a dictionary, words spelled backwards, first names, surnames, address numbers, telephone numbers, and social security numbers. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 24 • Passwords are prearranged identifiers that the user possesses, such as words, special coded phrases, personal identification numbers (PINs), etc. • Password systems require a single coded response from the user to be allowed access to the host computer. In the case of an organization, to make password systems secure, it is important to consider the following: • How the password will be selected. • How often the password will be changed. • How long the password will be used. • How the system will handle (transmit) the password. • Practice has shown that leaving the choice of a password to the user often results in the use of unsatisfactory or poor passwords, such as words from a dictionary, words spelled backwards, first names, surnames, address numbers, telephone numbers, and social security numbers. For this reason, it is recommended that a series of random characters be generated and assigned to each user. The composition of the password should require a minimum of a possible 100 million passwords for the lowest level of security. 24 Password Guessing • In 1985, the Department of Defense published the Password Management Guideline, CSC-STD-002-85, that described how to calculate the maximum lifetime of a password. L= PxS R where L = Maximum lifetime for a password P = Probability that a password can be guessed within its lifetime, assuming continuous guesses for that period. R = Number of guesses possible to make per unit of time. S = Password space; the total number of passwords that can be generated. S = AM (A = number of alphabet symbols, M = password length) • • For P = 10-6; R = 500K guesses/sec = 43.2 x 108/day. For a password that consists of a combination of ten upper and lower case letters and numbers 0 - 9, then S = A M = 6210 = 8.39 x 1017 and IEEE 802.1X L = 10 -6 EAP Methods x 8.39 x 1017 = 19.43 days 43.2 x 10 8 Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 25 • A password used for a long time has the probability of falling into an intruder's hands. The greater the length of time a password is used, the more opportunities there are for breaking security. The recommended maximum lifetime of a password should be not more than one year. The password should be changed immediately if a compromise is suspected, or if the owner is no longer authorized to access the computer. The maximum lifetime of a password depends on the size of the password space, how fast an intruder could execute a login attempt, and the level of security (probability that a password will be guessed during its lifetime). The formula above (Department of Defense, 1985) may be used to determine the lifetime of a password. • A premise in authentication is that passwords provides weak authentication. This is true because of the way passwords are selected and how authentication is implemented. Simple passwords are not a good idea because they can be broken using dictionary attacks. A better option is a random combination of 20 alphanumeric characters including alphabetic (lower and upper case), numeric, and special (e.g., punctuation) characters. When the password is hashed using SHA-256 and sent to the authentication server, then a good password authentication system is enabled. Those password implementations in which the hash is truncated from 256 to 80 bits reduces considerably the security of the password because of collisions. It is not necessary to have the same password to breach security, but a password that produces the same 80 bits of the stored hash could do so. 25 Password Guidelines • Must contain a combination of at least eight alphanumeric characters including at least one alphabetic, one numeric, and one special (e.g., punctuation) character, as well as one upper case and one lower case character. • Must be a minimum length of ten characters (not eight) if the system does not distinguish between upper and lower case. • • • Must not contain the user ID or portion thereof. • In the Windows NT environment, it is better to use passwords that are exactly 7 or 14 characters in length. • The system should not modify the end-user password, i.e., convert the password to all lower case, or truncate the password. • Passwords must not be stored or retained in clear at any location; instead, a hash of the password should be stored. The Secure Hash Algorithm SHA (224, 256, 384, or 512) should be used and the hashed password should not be truncated. Must not be a combination of year and date. Must not contain any two or more letters in forward or reverse alphabetic sequence, ASCII sequence, or QWERTY sequence, regardless of the case. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 26 • Practice has shown that leaving the choice of a password to the user often results in the use of unsatisfactory or poor passwords, such as words from a dictionary, words spelled backwards, first names, surnames, address numbers, telephone numbers, and social security numbers. For this reason, a series of random characters can be generated and assigned to each user. The composition of the password should permit a minimum of 100 million passwords for the lowest level of security. This is equivalent to a password with five alpha characters (266). • Other guidelines [Recommended] • Should not be a repeating character string, or keyboard patterns or sequence • Should not include any customer specific requirements. [Optional] • Should not contain a dictionary word of four characters or longer in forward or reverse letter order • Should not be the same as any six previously used passwords • Should not match any four or more characters in sequence with any four or more characters in sequence with the last password • Should not contain space, editing (@#) or field-separators (:), delimiter (,) or ([), (]), ($), (\), (/), or single/double quote marks 26 Access Authentication • Two-Factor Authentication — To identify and authenticate an authorized system user, two factors are necessary: (1) Something secret only the user knows – a memorized personal identification number (PIN) or password; (2) Something unique the user possesses – a token. • Time Synchronizing — The authorized system user carries a token which generates a unique, onetime, unpredictable access code every 60 seconds. To gain access to a protected resource, a user simply enters his or her secret PIN, followed by the current code displayed on the token. — Authentication is assured when the authenticator recognizes the token’s unique code in combination with the user’s unique PIN. Software synchronizes each token with hardware at the authenticator. — RSA SecurID token is a good example of a product providing an easy, onestep process to positively identify network and system users. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 27 27 RADIUS Authentication Server • Used for Remote Authentication Dial-In User Services • Is an easy method for authentication, authorization and accounting of dial-in users (AAA). • Relies on basic Request/Accept messaging. • Uses UDP (User Datagram Protocol). • Relies on “shared secret” for NAS authentication • Access-Request — Sent by RADIUS client (Network Access Server - NAS) — Contains username, password and particulars such as NAS ID, port number, access type, etc. • Password encrypted with shared secret • Access-Accept or Access-Reject — Returned by RADIUS server — Contains list of attributes (called authorization info) used by the NAS IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 28 • Two different sets of protocols are used to provide access authentication. For LAN-to-LAN, X.509 is used, and for dial-in or client-to-LAN, a protocol called Remote authentication Dial-in User Service (RADIUS) is used. • Remote access using dial-in systems requires access security, authorization, and accounting (AAA). RFC 2865 (Rigney, Willens, Rubens, & Simpson, 2000) describes a protocol for carrying authentication, authorization, and configuration information between a network access server that needs to authenticate its links and a RADIUS server. A RADIUS server is connected to a database that maintains access profiles for all trusted users. Access to this database allows for authentication (verifying user name and password), access privileges (authorization), as well as configuration information detailing the types of services to deliver to the user (for example, SLIP, PPP, telnet, rlogin). • Client/Server Model - RADIUS servers handle requests from a Network Access Server (NAS) that is installed as a gateway or network entry point and that operates as a client of RADIUS. The NAS client is responsible for passing user information to designated RADIUS servers, and then acting on the response that is returned. • RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. • Network Security - Transactions between the client and a RADIUS server are authenticated with a shared secret, which is never sent over the network. In addition, all user passwords are sent encrypted between the client and the RADIUS server to eliminate the possibility that someone snooping on an unsecured network could determine a user's password. 28 1 Access-Request 5 Access-Reject or Client (User) Challenge 7 Challenge 6 Resubmit Access-Request RADIUS Network Access Server (NAS) NAS operates as a Client of Radius 2 Response 4 3 RADIUS Server Smart Card, Software 1 Access-Request • User dials into remote access server • User Name • Password (Hidden using RSA Message Digest Algorithm, MD5) • NAS ID • Port ID IEEE 802.1X 2-4 5-6 Database 7 List of requirements which must be met to allow access for the user. • Sends Access• NAS sends Resubmit AccessReject or request for Request Challenge RADIUS • Original Access(random number) authentication Request with the and authorization. • User enciphers User Password Challenge with • RADIUS checks Attribute replaced Smart Card or against its user ID by the encrypted encryption database, and response. software. • Provides info to NAS whether the user is in the database or not. EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 29 • The RADIUS server can support several methods to authenticate a user. RADIUS is the preferred protocol for use with Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP), but it also can support Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), UNIX login, and other authentication mechanisms. • The authentication process begins with the user submitting an “access-request” to the NAS. The NAS submits the “access-request” plus NAS-identifier, NAS-port, user-name, and userpassword. Once the RADIUS server receives the request, it validates the sending client. A request from a client for which the RADIUS server does not have a shared secret is discarded. If the client is valid, the RADIUS server consults a database of users to find the user whose name matches the request. The user entry in the database contains a list of requirements that must be met to allow access for the user. This always includes verification of the password, but can also specify the port(s) to which the user is allowed access. • If any condition is not met, the RADIUS server sends an “access-reject” response indicating that this user request is invalid. If all conditions are met, the RADIUS server generates a random number and sends back an “access-challenge” packet with state and a reply-message along the lines of “challenge {random number}, enter your response at the prompt," thus challenging the user to encrypt the random number and send back the result. • The user enciphers the challenge using a special device such as a smart card or encryption software. Unauthorized users, lacking the appropriate device or encryption software and lacking knowledge of the secret key, are not able to generate the response. The user then re-submits its original “access-request” with a new request ID, in which the user-password attribute is replaced by the response (encrypted). If the response matches the expected response, the RADIUS server replies with “access-accept,” otherwise it sends an “access-reject.” 29 Needham and Schroeder Authentication 1. A A: EK {RA ¦ B ¦ K ¦EB(K ¦A)} B: E B {K ¦A} 4. B A: E K {R B} 5. A 2 {A ¦B ¦RA} 3. A 1 T: 2. T Trusted Entity B: E K {RB – 1} A 3 A 4 B 5 IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 30 • The authentication protocol invented by Needham and Schroeder (1978) uses symmetric key encryption and a trusted entity, which, for this example, will be called Trent. • The procedure is as follows: 1. Alice sends a message to Trent with her name, A, and the name of the server, B, to which she wants access and a random value, RA. 2. Trent generates a session key, K, concatenates the generated session key with Alice’s name and enciphers it with Bob’s secret key. This enciphered message is concatenated with Alice’s random number, Bob’s name, the key, and everything else is enciphered with Alice’s key. 3. Alice deciphers the message using her key, gets the session key, K, and confirms that RA is the same value that she sent to Trent in step 1. Then, she sends Bob the message EB {K || A } that Trent sent her. 4. Bob deciphers the message and gets the session key, K. He then generates another random value, RB, enciphers RB with the session key, K, and sends the message to Alice. 5. Alice deciphers the message with the session key, K and she generates RB – 1 and enciphers it with the session key, K. Then, she sends the message back to Bob. • RA, RB, and RB -1 are used to ensure that there will not be any replay attacks during the authentication process, and that intruders will not be able to use Alice’s messages in future sessions. 30 Kerberos Authentication Method • Internet security standard protocol RFC 1510 based on trusted third-party centralized authentication to offer authentication services to users and servers in an open distributed environment. — Used in Windows 2000 • Relies on secret-key symmetric ciphers for encryption and authentication. • Requires trust in a third party (the Kerberos server) for authentication. — If the server is compromised, the integrity of the whole system is lost. • Does not use public-key encryption, therefore, does not produce digital signatures or authentication of authorship of documents. • Version 4 still used. • Version 4 makes use of DES in Propagating Cipher Block Chaining (PCBC) • Version 5 (RFC 1510) uses any encryption algorithm. If DES is used it has to be in CBC mode. ftp://ftp.isi.edu/in-notes/rfc1510.txt . IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 31 • Kerberos Version 5.2 is an Internet security standard protocol, RFC 4120 (Neuman, Yu, Hartman, & Raeburn, 2005), based on a trusted third-party authentication to offer authentication services to users and servers in an openly distributed environment. Kerberos relies on secret-key symmetric ciphers for encryption and authentication and does not use public-key encryption; therefore, it does not produce digital signatures or authentication of authorship of documents. The authentication requires trust in a third party (the Kerberos server), so if the server is compromised, the integrity of the whole system is lost. Kerberos version 4 uses DES and version 5.2 uses any encryption algorithm; in version 5.2, DES has to be used in the CBC mode. The Kerberos Authentication Server (KAS) keeps a database with the names of all the users and their secret keys. 31 Kerberos Ticket is encrypted using the secret key shared by the Kerberos server and the Application server. Kerberos Server 2 I am Alice’s workstation and I want to use database # 1 in the application server “B”. Here is my user ID. 1 I am Alice, and here is my password to prove it. Client Workstation I believe you. Here is your ticket with your user ID, network 3 address, and the server ID for the application server “B” you want to access. I am Alice, and I want to 4 use your database #1. Here is my ticket. Application Server “B” Database # 1 I believe you, and here is 5 your access to the database services. • Kerberos server performs the functions of a Key Distribution Center (KDC). — Keeps the secret keys of all users. — Authenticates the identities of users and distributes session keys to users and servers. • Application servers do not communicate with the Kerberos server. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 32 • Suppose that Alice would like to generate a session secret key for a communication with the server, Bob. The basic Kerberos authentication process for this procedure is as follows: • Alice sends a request to the KAS requesting credentials to talk with the application server, Bob. • The KAS responds with the credentials, encrypted in Alice's secret key. The credentials consist of (1) A ticket to communicate with the application server B and (2) A temporary encryption key (often called a session key). The ticket is encrypted with application server B secret key. • Alice transmits the ticket, which contains her identity and a copy of the session key, all encrypted with the application server B secret key, to the application server B. • The session key, now shared by Alice and application server B, may be used to provide three different levels of protection: (1) Authenticate Alice and application server B at the beginning of the network connection; (2) Authenticate and encipher further communications between Alice and application server B; (3) Exchange a separate sub-session key to be used to encrypt further communications between Alice and application server B. 32 Kerberos’ Abbreviations and Protocols C S TGS adddrx Ax = = = = = IDx Kx Kx,y = = = Kx {m} = Txy TGSx times = = = || = Client Server Ticket Granting Server x’s network address x’s authentication (name, address, and timestamp) x’s identification x’s secret key Session key for x and y communications m encrypted with x’s secret key x’s ticket to use with y TGS used by C beginning and ending validity time for a ticket, timestamp concatenation AS TGS 3 2 1 4 Once per type of service Once per user log on C Once per service session 5 6 • • EK { K C, TGS } || E K • IDS || E K • EK Kerberos’ ticket for x to talk with y • E K {TC,S} || EK Tx,y = EKy { IDx, addrx, times, Kx,y } • EK S IDC || TGSC || time IEEE 802.1X EAP Methods Passwords C TGS TGS C, TGS s C,S { TC,TGS } || time { TC,TGS } || E K C, TGS { AC } { KC,S } || E K { TC,S } s C,S { AC } { timestamp, Subkey, Seq # } Radius Kerberos X.509 M. Mogollon – 01/08 - 33 • The following describes the Kerberos protocol: 1. The client sends her identification and the name of her TGS to the Kerberos authentication server. 2. The Kerberos authentication server looks in its database to see if the client identification is correct. If the client ID is correct, the Kerberos authentication server sends a ticket to be presented to the TGS and a message that has a session key, enciphered with the client’s secret key. The client deciphers the message and retrieves the session that it is going to use to communicate in secure with the Ticket Granting Service (TGS). 3. The client sends the TGS the following: (a) The server ID to which the client wants to communicate; (b) The ticket that it received from the Kerberos authentication server; and (c) The client’s authentication (client’s name & address, and time stamp) enciphered with the session key sent by the Kerberos authentication server. 4. The TGS deciphers the ticket and the client’s authentication and compares them. If everything is correct, the TGS sends a ticket for the client to present to the server, and a message for the client that has a new session key, enciphered with the client’s secret key. The client deciphers the message and retrieves session key 2 that is going to be used to communicate in secure with the server. 5. The client sends the server the following: (a) The ticket that it received from the ticket granting service; and (b) The client’s authentication encrypted with session key 2 provided by the TGS. 6. The server deciphers the ticket, and, after getting session key 2, deciphers the client’s authentication. The server compares them and, if everything is correct, the server knows that the client is who she claims to be. If the client requested that mutual authentication be required, the server sends a time stamp, a subkey, and a sequence number, enciphered with the new session. The subkey is an optional key, in case the client and the server do not want to use session key 2 provided by the TGS. 33 Kerberos Encryption and Checksum Encryption Confounder Message Padding Ke Confounder Message Padding Encipher HMAC Ki Ciphertext Output = E (Ke, confounder || message || padding) || HMAC(Ki, confounder || message || padding) Checksum Confounder Message Padding Ki Ke Encipher HMAC Encipher Ke Checksum Output = E (Ke, confounder) || E [Ke, (HMAC(Ki confounder || message || padding)] IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 34 • Kerberos is designed to encipher messages, using block encryption ciphers or stream encryption ciphers. Encryption is used as an authentication mechanism to prove the identities of the network entities participating in message exchanges. However, the Kerberos protocol does not require a specific encryption algorithm be used, as long as the algorithm includes certain operations. • RFC 3961, “Encryption and Checksum Specifications for Kerberos 5,” specifies the encryption and checksum mechanisms for Kerberos, as well as a framework for defining future mechanisms. RFC 3962, “Advanced Encryption Standard (AES) Encryption for Kerberos 5,” defines how to generate encryption keys and checksum types for Kerberos 5 using the AES 128-bit block encryption and key sizes of 128 or 256 bits. AES is used in the CBC mode with ciphertext stealing (CTS) to avoid message expansion. SHA-1 is the associated checksum function. CTS is defined in RFC 2040 (Baldwin, Rivest, 1996), “The RC5, RC5-CBC, RC5-CBC-Pad, and RC5CTS Algorithms.” • According to RFC 3961 the format for the data to be encrypted includes a one-block confounder, the plaintext, and any necessary padding. Then, the concatenated block is enciphered using an encryption algorithm and an HMAC function (possibly truncated), using the specified hash function H. The ciphertext output is the concatenation of the output of the basic encryption function E and the hash function as shown above. • The confounder, a random number, is included so that an observer cannot know if two messages contain the same plaintext, or even if the cipher state and specific keys are the same. Decryption is performed by removing the (partial) HMAC, decrypting the remainder, and verifying the HMAC. The cipher state is an initial vector, initialized to zero. In some of the algorithms proposed in RFC 3961, the confounder and the hash result are enciphered using a cipher encryption. 34 Kerberos Security Concerns • Secret keys should be distributed in a secure way. • Kerberos servers have same concerns about secret-key encryption, i.e. confidentiality and timeliness that apply to Kerberos’ secret keys. • Kerberos servers should be located in physically secure environments with restricted physical access. • Multiple-service-granting tickets are reusable, so an opponent may capture the ticket and use it. — Tickets should have a timestamp and a lifetime to prevent replay attacks (Version 5). IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 35 35 X.509 Authentication Method • ITU-T recommendation X.509 is part of the X.500 series of recommendations that define a directory service. • X.509 is the primary standard for certificates. It specifies not only the format of the certificate, but also the conditions under which certificates are created and used. • Two types of authentication are used. — Simple Authentication using passwords. — Strong Authentication using public-key crypto systems. • Public Key Infrastructure (PKI) is based on X.509, Version 3. — Each certificate contains the public key of a user and is signed with the private key of a CA. — RSA is recommended for use in X.509. • X.509 is used in S/MIME, IP Security, TLS/SSL and SET. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 36 • The ITU-T X.509 Recommendation defines a framework for the provision of authentication services by the directory to its users. These users include the directory itself, as well as other applications and services. The Directory is a natural place from which communicating parties can obtain authentication information from each other. • The ITU-T X.509 Recommendation includes the following information: • Specifies the form of authentication information held by the Directory; • Describes how authentication information may be obtained from the Directory; • States the assumptions made about how authentication information is gathered and placed in the Directory; • Defines three ways in which applications may use this authentication information to carry out authentication and describes how other security services may be supported by authentication. • The ITU-T X.509 Recommendation describes two levels of authentication: simple authentication, using a password as a verification of claimed identity, and strong authentication, involving credentials created by using cryptographic techniques. The strong authentication method specified in ITU-T X.509 is based upon public-key cryptosystems. • ITU-T X.509 Recommendation focuses on defining a mechanism by which information can be made available in a secure way to a third party either by a password or by using certificates. The public keys and user certificates are created off-line by an off-line certificate authority and subsequently placed in the Directory. The Directory server merely provides an easily accessible location for users to obtain certificates. No special requirements are placed upon Directory providers to store or communicate user certificates in a secure manner. 36 X.509 – Simple Authentication 1. Alice sends her ID and password to Bob. Directory password to the Directory, where the password is checked against the information held for Alice. 3 2 3. The Directory confirms (or denies) 1 A 2. Bob sends Alice’s ID and to Bob that the credentials are valid. B 4 4. The success (or failure) of authentication may be conveyed to Alice. The password is sent in cleartext IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 37 • In a simple authentication, the password is sent in clear. 37 X.509 – Simple Protected Authentication Alice Alice ID, Password, Time Stamp, and Random Number ID, Time Stamp, and Random Number Bob Transmit Hash Alice’s Password from Directory ID, Time Stamp, and Random Number One-Way Function Hash Hash Compare One-Way Function • Using a one-way function, Alice creates a hash of her ID, password, time stamp and a random number. • Alice sends in clear her ID, time stamp and random number. The time stamp and/or random number (when used) is used to minimize replay and to conceal the password. • Bob generates Alice’s hash by using Alice’s ID and optional time stamp and/or random number, together with the Directory’s local copy of Alice’s password. • Bob compares Alice’s hash with the locally generated hash value. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 38 • The basic approach to authentication is the corroboration of identity by demonstrating possession of a private key. ITU-T X.509 includes three strong authentication procedures all based on public key. • The three procedures provide different types of authentication: (1) Only the identity of the initiating party, Alice, is verified; (2) The identity of both parties, Alice and Bob, is verified; (3) The identity of both parties is verified but without the need for time-stamp checking. • It is assumed that prior to any exchange of information, Alice has Bob’s public key, as well as the return certification path from Bob to Alice, so Bob will know how to get Alice’s public key. 38 X.509 – One-way Alice’s CA Strong Authentication Bob CA’s Public Key Alice Decipher Using CA’s Public Key Alice’s Certificate and path to CA Non-repeating number rA Time Stamp tA Alice’s Digital Signature sgnData Bob’s ID IDB Enciphered, and signed authentication message Secret Key [encData] IEEE 802.1X Alice’s public key and info Using Decipher Alice’s Public Key Using Encipher Alice’s Private Key Authentication Message Bp[encData] Using Bob’s Public Key Encipher EAP Methods Bob checks if Alice’s certificate has expired. Bob • Checks that Alice’s non-repeating number has not been replayed. • Checks that Alice’s time stamp is current. • Verifies that Bob himself is the intended recipient. rA , tA, IDB , Bp[encData] Using Bob’s Decipher Private Key Secret Key [encData] Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 39 1. Alice generates rA, a non-repeating number, which is used to detect replay attacks and to prevent forgery. 2. Alice sends the following message to Bob: B A, A {tA, rA, IDB, sgnData, Bp[encData]} where B A is Alice’s certification authority path, tA is a timestamp. tA consist of one or two dates: the generation time of the token (which is optional) and the expiry date. "sgnData" is used if the digital signature provides data origin authentication. “[encData]” is used in cases when information been conveyed will subsequently be used as a secret key. “[encData]” is enciphered with Bob’s public key, PubB. The use of “[encData]” as a secret key implies that it shall be chosen carefully, to be a strong key for whatever cryptosystem is used. 3. Bob carries out the following actions: • Obtains Alice’s public key, p, from the Certificate Authority (B certificate has not expired; A,) checking that Alice's • Verifies the signature, and thus the integrity of the signed information; • Checks IDB to verify that Bob himself is the intended recipient; • Checks that the time stamp is "current"; • Checks that rA has not been replayed (optional). rA is valid until the expiration date indicated by tA, so Alice will not repeat the token during the time range tA. 39 X.509 – Two-way Strong Authentication Alice Bob’s CA CA’s Public Key Alice checks if Bob’s certificate has expired. Bob Using CA’s Decipher Public Key Bob’s Certificate Enciphered, and signed authentication message Bob’s public key and info Alice • Checks that Bob’s non-repeating number has not been replayed. • Checks that Bob’s time stamp is current. • Verifies that Alice herself is the intended recipient. Using Bob’s Decipher Public Key Using Bob’s Private Key rB , tB, IDA , Authentication Message Bp[encData] Decipher Using Alice’s Private Key Secret Key [encData] IEEE 802.1X EAP Methods Encipher Passwords Non-repeating number rB Time Stamp tB Bob’s Digital Signature sgnData Alice’s ID IDA Ap[encData] Encipher Secret Key [encData] Using Alice’s Public Key Radius Kerberos X.509 M. Mogollon – 01/08 - 40 1. Same as Step 1 of One-way authentication. 2. Same as Step 2 of One-way authentication. 3. Same as Step 3 of One-way authentication. 4. Bob generates rB , a non-repeating number, used for similar purpose(s) to rA; 5. B sends the following authentication token to A: B{tB, rB, IDA, rA, sgnData, Ap[encData]} tB is a timestamp defined in the same way as tA. "sgnData" is used if the digital signature provides data origin authentication. “[encData]” is used in cases where information being conveyed will subsequently be used as a secret key. “[encData]” is enciphered with Alice’s public key, PubA. 6. Alice carries out the following actions: a) Verifies the signature, and thus the integrity of the signed information; b) Checks IDA to verify that Alice herself is the intended recipient; c) Checks that the timestamp tB is "current"; d) Checks that rB has not been replayed (optional). 40 X.509 Certificate Certificate version Certificate serial number ID of the algorithm used by the issuer (CA) to sign the certificate CA’s name issuing the certificate Certificate validity period (not before, not after) Subject’s Certificate Information End-entity’s name Subject public key information Issuer CA’s unique ID (optional) Hash SHA-1 Digital Signature Encipher A S N 1 + D E R R A D I X 64 End-entity’s unique ID (optional) Extensions (optional) Authority-Key Identifier Subject-Key Identifier ● IEEE 802.1X EAP Methods Certificate Authority’s Private Key ASN1: Abstract Syntax One Notation DER: Distinguish Encoding Rules (tag, length, value) Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 41 • X.509 is the most widely used certificate format for PKI. It is used in SSL, IPsec, S/MIME, SET, and now on PGP. RFC 4325 (Santesson, & Housley, 2005) lists the following X.509 certificate basic fields: • Version: This field gives the version of the encoded certificate. • Certificate Serial Number: The serial number is a unique positive integer assigned by the CA to each certificate. Certificate users must be able to support serial number values up to 20 octets. • Signature Algorithm Identifier: This field contains the algorithm identifier for the algorithm used by the CA to digitally sign the certificate. The algorithm could be RSA or DSA. • CA Issuer Name: The issuer field identifies the certification authority that has signed and issued the certificate. • Validity Period: The validity period field is the time interval during which the CA certifies that it will maintain information about the status of the certificate. The field is represented as a sequence of two dates: the date on which the certificate validity period begins and the date on which the certificate validity period ends. • Subject Name: The subject field identifies the entity whose public key is authenticated. • Subject Public-Key Information: This field is used to carry the public key and public- key parameters, as well as the identifier of the public-key algorithm used (e.g., RSA, DSA, or DiffieHellman). • Issuer Unique ID: This is an optional field used to allow the reuse of issuer names over time. • Subject Unique ID: This is an optional field used to allow the reuse of subject names over time. • Extensions: This field must appear only if the certificate version is 3. The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing a certification hierarchy, such as CA Key Identifier and Subject Key Identifier. • The information from the above fields is signed using the CA’s private key. The CA’s digital signature and the information from the above fields are (1) Concatenated; (2) Written using a syntax notation system called Abstract Syntax One, (3) Converted into binary data using Distinguish Encoding Rules (DER) encoding system, and then (4) Converted to ASCII characters using base-64 encoding. 41 To Probe Further • Public-Key Infrastructure (X.509) (PKIX) Charter. Links to many X.509 RFP web sites. http://www.ietf.org/html.charters/pkix-charter.html • Directories and X.500: An Introduction, Information Technology Services, National Library of Canada. Retrieved August 20, 2002 from http://www.nlc-bnc.ca/9/1/p1-244e.html • RFC 2865 Remote Authentication Dial-in User Service (RADIUS) describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server that desires to authenticate its links and a RADIUS Server. http://www.ietf.org/rfc/rfc2865.txt?number=2865 • Password Management Guideline, CSC-STD-002-85 http://www.radium.ncsc.mil/tpep/library/rainbow/CSC-STD-002-85.html • One-Time Password System RFC 2289. IETF. http://www.ietf.org/rfc/rfc2289.txt?number=2289 • The Kerberos Network Authentication Service (V5). RFC 1510. IETF. http://www.ietf.org/rfc/rfc1510.txt?number=1510 • • Extensible Authentication Protocol RFC 2284 Mishra, Arunesh, and William Arbaugh. (2001) "An Initial Security Analysis of the IEEE 802.1X Security Standard. Paper available from http://www.cs.umd.edu/~waa/1x.pdf IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 42 42 To Probe Further • Needham R. M., M. D. Schroeder, Using Encryption for Authentication in Large Networks of Computers Communications of the ACM, Vol. 21 (12), pp. 993-99. IEEE 802.1X EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 43 43 802.1X Ethernet Packet 6 bytes 6 bytes 2 bytes 1 byte Dest. MAC 0180C200000F Source MAC Type 8180 Protocol Version 01 1 byte 2 bytes Packet Type Packet Body Length n bytes Packet Body 00 EAP-Packet 01 EAPOL-Start * * No Packet Body Field 02 EAPOL-Logoff * 03 EAPOL-Key 04 EAPOL-Encapsulated-ASF-Alert 1 byte 1 byte 2 bytes Code Identifier Length n bytes Data EAP Payload (EAP-TLS, EAP-TTLS, EAP PEAP) 1 Request 2 Response 1 bytes 2 bytes 8 bytes 3 Success Descriptor Type Key Length 4 Failure IEEE 802.1X Replay Counter 32 bytes Nonce 16 bytes Key IV 1 bytes 16 bytes Key Index Key Signature n bytes Key Packet Body Field EAP Methods Passwords Radius Kerberos X.509 M. Mogollon – 01/08 - 44 44 ...
View Full Document

This note was uploaded on 05/26/2010 for the course TECH 6350 taught by Professor Mogollon during the Spring '10 term at University of Arkansas for Medical Sciences.

Ask a homework question - tutors are online