Network Working Group J. Mattsson Internet-Draft M. Sethi Obsoletes: 5216 (if approved) Ericsson Intended status: Standards Track July 3, 2017 Expires: January 4, 2018 The EAP-TLS Authentication Protocol draft-mattsson-eap-tls13-00 Abstract Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. Transport Layer Security (TLS) provides mutual authentication, integrity-protected cipher suite negotiation, and key exchange between two endpoints. This document specifies an EAP authentication method to provide support for certificate-based mutual authentication and key derivation using the version 1.3 of the TLS protocol. This document obsoletes RFC5216. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Mattsson & Sethi Expires January 4, 2018 [Page 1] Internet-Draft EAP-TLS 1.3 July 2017 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Base Case . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Resumption . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Key Heirarchy . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Ciphersuite and Compression Negotiation . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.1. EAP security claims . . . . . . . . . . . . . . . . . . . 10 4.2. Certificate Validation and Revocation Checks . . . . . . 11 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative references . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Extensible Authentication Protocol (EAP) [RFC3748], provides a standard mechanism for supporting multiple authentication methods. Authentication methods such as Generalized Pre-Shared Key (GPSK) [RFC5433] and Protected One-Time Password Protocol (POTP) [RFC4793] have been defined using the EAP framework. Specifications for how EAP messages are carried over a variety of lower layers such as Point-to-Point Protocol (PPP) [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and wireless technologies such as IEEE 802.11 [IEEE-802.11] and IEEE 802.16 [IEEE-802.16e] also exist. [RFC5216] had defined TLS based mutual authentication for EAP. This document obsoletes [RFC5216] and specifies EAP-TLS that is based on TLS version 1.3. TLS 1.3 obsoletes the older version 1.2 and introduces a number of changes such as encrypting all messages after ServerHello and adding a 0-RTT mode that saves a round-trip at connection setup. For a complete list of updates see [I-D.ietf-tls-tls13]. This document does not request a new EAP method type assignment. Mattsson & Sethi Expires January 4, 2018 [Page 2] Internet-Draft EAP-TLS 1.3 July 2017 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In addition, this document frequently uses the following terms as defined in : authenticator The entity initiating EAP authentication. peer The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the supplicant. server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. NAI A Network Access Identifier [RFC7542]. It is the user identifier submitted by the peer/supplicant prior to accessing resources. Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. Extended Master Session Key (EMSK) Additional keying material derived between the EAP peer and server that is exported by the EAP method. 3. Protocol Overview The EAP-TLS conversation begins with the authenticator and the peer negotiating EAP. The authenticator then sends an EAP-Request/ Identity packet to the peer. The peer then responds with its Network Access Identifier (NAI) in an EAP-Response/Identity packet. From this point onwards, although nominally the EAP conversation occurs between the EAP peer and the EAP authenticator, the EAP server is the ultimate endpoint conversing with the EAP peer. The authenticator MAY act as a pass-through to a backend EAP server. In the case where no backend authentication server is used, the EAP server is part of the authenticator. Mattsson & Sethi Expires January 4, 2018 [Page 3] Internet-Draft EAP-TLS 1.3 July 2017 3.1. Base Case After receiving the peer's Identity (NAI), the EAP server MUST respond with an EAP-TLS/Start packet. This is an EAP-Request packet with EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP- TLS conversation will then begin. The EAP-TLS conversation consists of EAP-Response and EAP-Request packets with EAP-Type=EAP-TLS and with the data field encapsulating one or more TLS records in TLS record layer format. The formating and processing of the TLS handshake SHALL be done as specified by TLS 1.3 [I-D.ietf-tls-tls13]. This document only lists additional requirements, restrictions, and processing compared to TLS 1.3. The peer responds to the EAP-Request with EAP-Response packet with EAP-Type=EAP-TLS. The data field in the response encapsulates one or more TLS records in TLS record layer format, containing a TLS ClientHello handshake message. The ClientHello message contains the peer's legacy_version that MUST be set to 0x0303, a random number, a legacy_session_id that MUST be set as a zero length vector (i.e., a single zero byte length field), a set of ciphersuites supported by the peer, a legacy_compression_methods vector field that MUST contain exactly one byte set to zero. The ClientHello must include the supported_versions extension. Peers can request additional functionality using extensions in the ClientHello message. After receiving the EAP-Response containing the ClientHello, the EAP- Server sends an EAP-Request packet with EAP-Type=EAP-TLS. The data field of this packet contains one or more TLS records for TLS ServerHello, Encrypted extensions, a CertificateRequest, the server Certificate along with an explicit proof of the server identity (CertificateVerify), followed by finished handshake message. The ServerHello contains the version of TLS. EAP Servers MUST select a version from the list in ClientHello's supported_versions extension. For this version of the specification, the version is 0x0304. The ServerHello also contains a random number, a single cipher_suites selected by the server from the list in the ClientHello, and the "key_share" extension which specifies the cryptographic parameters such as the named group for the key being exchanged. After receiving the EAP-Response containing the ServerHello, the EAP- Server sends an EAP-Request packet with EAP-Type=EAP-TLS. The data field of this packet contains one or more TLS records for TLS Certificate, CertificateVerify, followed by finished handshake message. Mattsson & Sethi Expires January 4, 2018 [Page 4] Internet-Draft EAP-TLS 1.3 July 2017 After the TLS handshake has completed, the EAP server sends EAP Success. In the case where the EAP-TLS with mutual authentication is successful, the conversation will appear as shown in Figure 1. EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (MyID) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=EAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> <-------- EAP-Success Figure 1: EAP-TLS base case - Mutual authentication While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances in which peer authentication will not be needed (e.g., emergency services, as described in [RFC7406]), or where the peer will authenticate via some other means. If the EAP Server does not desire the peer to authenticate itself, the CertificateRequest is omitted, and the EAP Peer therefore does not send Certificate and CertificateVerify. The message flow is shown in Figure 2. Mattsson & Sethi Expires January 4, 2018 [Page 5] Internet-Draft EAP-TLS 1.3 July 2017 EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (MyID) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=EAP-TLS (TLS Finished) --------> <-------- EAP-Success Figure 2: EAP-TLS base case - Server authentication only 3.2. Resumption The purpose of resumption is to allow for improved efficiency in the case where a peer repeatedly attempts to authenticate to an EAP server within a short period of time. Once a TLS handshake has completed, the EAP Server can send the EAP Peer a PSK identity (TLS NewSessionTicket) that corresponds to a key derived from the handshake. It is left up to the EAP Server whether to support resumption. An initial authentication, where both sides authenticate successfully and the EAP Server sends a TLS NewSessionTicket is shown in Figure 3. Mattsson & Sethi Expires January 4, 2018 [Page 6] Internet-Draft EAP-TLS 1.3 July 2017 EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (MyID) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=EAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS NewSessionTicket) EAP-Response/ EAP-Type=EAP-TLS --------> <-------- EAP-Success Figure 3: EAP-TLS resumption - Initial authentication The EAP Peer can then use the PSK identity received in TLS NewSessionTicket to negotiate use of the PSK in future authentications. If the server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake. It is up to the peer whether to attempt resumption. Typically, a the peer's decision will be made based on the time elapsed since the previous authentication attempt to that EAP server. Based on the the time elapsed since the previous full authentication, the EAP server will decide whether to allow resumption or require a full authentication. Mattsson & Sethi Expires January 4, 2018 [Page 7] Internet-Draft EAP-TLS 1.3 July 2017 An subsequent authentication using resumption, where both sides authenticate successfully is shown in Figure 4.. EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (MyID) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS (TLS ServerHello, TLS EncryptedExtensions, <-------- TLS Finished) EAP-Response/ EAP-Type=EAP-TLS (TLS Finished) --------> <-------- EAP-Success Figure 4: EAP-TLS resumption - Subsequent authentication 3.3. Termination 3.4. Fragmentation A single TLS record may be up several thousand octets in length and a TLS message may consiste of multiple TLS records. TLS certificate message may of the order of 10s of Megabytes. The group of EAP-TLS messages sent in a single round may thus be larger than the MTU size or the maximum Remote Authentication Dail-In User Service (RADIUS) packet size of 4096 octets. As a result, an EAP-TLS implementation MUST provide its own support for fragmentation and reassembly. In order to protect against reassembly lockup and denial-of-service attacks, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. Since a single certificate is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, a reasonable choice of maximum acceptable message length might be 64 Kilobyte as suggested in [RFC5216] Mattsson & Sethi Expires January 4, 2018 [Page 8] Internet-Draft EAP-TLS 1.3 July 2017 This specification reuses the mechanism of fragmentation and reassembly specified in [RFC5216]. The fragmentation support is provided through addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a TLS Message Length field of four octets. The three 1-bit flags included are: o Length included (L) bit flag: is set to indicate the presence of the four-octet TLS Message Length field. It MUST be set for the first fragment of a fragmented TLS message or set of messages. o More fragments (M) bit flag: The M flag is set on all but the last fragment. o EAP-TLS Start (S) bit flag: The S flag is set only within the EAP- TLS start message sent from the EAP server to the peer. The remaining 5 bits in the flags octet are reserved. The TLS Message Length field is four octets, and provides the total length of the TLS message or set of messages that is being fragmented. This simplifies buffer allocation. When an EAP-TLS peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and no data. This serves as an acknowledgment for the fragment. The EAP server MUST wait until it receives the EAP-Response (acknowledging the previous fragment) before sending another fragment. As specified in [RFC3748] each EAP packet has an Identifier field. The EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the EAP-Response that acknowledges the fragment. Similarly, when the EAP Peer needs to fragment a large message, it sends an EAP-Response with the M bit set. The EAP Server MUST respond to this with an EAP-Request with EAP-Type=EAP-TLS and no data. This acts as an acknowledgment for the fragment received from the EAP peer. The EAP peer MUST wait until it receives the EAP- Request before sending another fragment. Even when the EAP Peer fragments messages over several EAP-Response messages, it is the EAP Server that MUST increment the Identifier value for each fragment acknowledgment in the EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment within the EAP-Response. 3.5. Key Heirarchy ... Mattsson & Sethi Expires January 4, 2018 [Page 9] Internet-Draft EAP-TLS 1.3 July 2017 3.6. Ciphersuite and Compression Negotiation EAP-TLS implementations MUST support TLS v1.3. To ensure interoperability, EAP-TLS peers and servers MUST support the TLS mandatory-to-implement ciphersuite: TLS_AES_128_GCM_SHA256 [GCM] and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC7539] cipher suites. During the EAP-TLS conversation the EAP peer and server MUST NOT request or negotiate compression. 4. Security Considerations 4.1. EAP security claims EAP security claims are defined in section 7.2.1 of [RFC3748]. The security claims for EAP-TLS are listed in Table 1. Mattsson & Sethi Expires January 4, 2018 [Page 10] Internet-Draft EAP-TLS 1.3 July 2017 +-----------------------------------+----------------+ | Security property | EAP-TLS claim | +-----------------------------------+----------------+ | Authentication mechanism | Certificates | | | | | Protected cryptosuite negotiation | yes | | | | | Mutual authentication | yes | | | | | Integrity protection | yes | | | | | Replay protection | yes | | | | | Key derivation | yes | | | | | Key strength | ... | | | | | Dictionary attack protection | yes | | | | | Fast reconnect | yes | | | | | Cryptographic binding | not applicable | | | | | Session independence | yes | | | | | Fragmentation | no | | | | | Channel binding | ... | +-----------------------------------+----------------+ Table 1: EAP security claims 4.2. Certificate Validation and Revocation Checks In contrast to the EAP-TLS server, the EAP-TLS peer may not have Internet connectivity. Therefore, the EAP-TLS server SHOULD provide its entire certificate chain minus the root to facilitate certificate validation by the peer. The EAP-TLS peer SHOULD support validating the server certificate using RFC6818 [RFC6818] compliant path validation. A EAP server MUST NOT request that a EAP Peer present an OCSP response with its certificate, i.e., the EAP server MUST NOT send an empty "status_request" extension in its CertificateRequest message. Mattsson & Sethi Expires January 4, 2018 [Page 11] Internet-Draft EAP-TLS 1.3 July 2017 5. IANA considerations 6. Acknowledgements 7. References 7.1. Normative References [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D , November 2007. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-20 (work in progress), April 2017. [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004. , December 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, . [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 2013, . [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, . [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, . Mattsson & Sethi Expires January 4, 2018 [Page 12] Internet-Draft EAP-TLS 1.3 July 2017 7.2. Informative references [IEEE-802.11] Institute of Electrical and Electronics Engineers, "IEEE Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", November 1997. [IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed Broadband Wireless Access Systems", April 2002. [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, . [RFC4793] Nystroem, M., "The EAP Protected One-Time Password Protocol (EAP-POTP)", RFC 4793, DOI 10.17487/RFC4793, February 2007, . [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, DOI 10.17487/RFC5433, February 2009, . [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., and D. Kroeselberg, "Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, December 2014, . Authors' Addresses John Mattsson Ericsson Farogatan 6 Kista 16480 Sweden Email: john.mattsson@ericsson.com Mattsson & Sethi Expires January 4, 2018 [Page 13] Internet-Draft EAP-TLS 1.3 July 2017 Mohit Sethi Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: mohit@piuha.net Mattsson & Sethi Expires January 4, 2018 [Page 14]