Internet Engineering Task Force S. Ammirata Internet-Draft G. Peskens Intended status: Informational SipRadius LLC. Expires: 27 May 2023 B. Gilmer J. Iacovelli, Ed. Video Services Forum 23 November 2022 EAP SHA256-SRP6a Authentication Protocol draft-eap-sha256-srp6a-00 Abstract This document describes an authentication protocol intended for Internet applications which may require a robust and non-leaky exchange of credentials even under adverse network conditions. The protocol has the ability to recover from packet loss during the authentication process, as for example, should the Internet application use the UDP transport protocol under lossy network conditions. It does so by allowing the retransmission of lost packets during authentication. The protocol follows the Extensible Authentication Protocol (RFC 3748 and RFC 5247) framework, which allows for the use of multiple authentication mechanisms. It utilizes Secure Remote Password protocol (RFC 2945), with strong, password-based cryptographic hashing. It utilizes the Secure Hashing Algorithm message digest algorithm as the hashing mechanism. The authentication protocol allows for one Server and one or more Clients. Where multiple Clients exist, each may communicate only with the Server. Clients initiate the authentication exchange process. Until the authentication completes successfully, the Server and Client ignore/discard any packets except those supporting the authentication process. The authentication algorithm is based on a username/password or passphrase pair. These are used to generate secure ephemeral keys. The Server has a store of all valid usernames and password hashes. Each Client stores its own username and password. The authentication algorithm provides for each side to prove to the other that it has a valid username/password or passphrase pair, in a way that a third-party monitoring the transactions could not use intercepted information to later successfully authenticate. This mutual authentication exchange consists of several pairs of interactions. The first is a request for authentication by the Client, containing the Client name, to which the Server responds with a challenge for its identity. The Client responds with the Server name for verification purposes. Thereafter, Client and Server each exchange three values consisting of password salts, ephemeral public keys, and hash values. These are generated and verified by Client and Server in accordance with SRP Ammirata, et al. Expires 27 May 2023 [Page 1] Internet-Draft EAP SHA256 SRP6a November 2022 against the stored password/passphrase hashes. While any step in the process may be repeated to provide for dropped packets should a response not be received, the authentication process is terminated by any incorrect value received in any response. Multicast UDP authentication is also supported, with certain limitations. 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 https://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 27 May 2023. Copyright Notice Copyright (c) 2022 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 (https://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 include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Encapsulation . . . . . . . . . . . . . . . . . . . 4 3.1. Layer-2 Encapsulation . . . . . . . . . . . . . . . . . . 4 3.2. Layer-3 Encapsulation Using GRE . . . . . . . . . . . . . 5 3.3. Layer-4 Encapsulation Using GRE Over UDP . . . . . . . . 5 4. Description of the EAP SHA256-SRP6a Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Authentication Algorithm and Protocol . . . . . . . . . . 6 Ammirata, et al. Expires 27 May 2023 [Page 2] Internet-Draft EAP SHA256 SRP6a November 2022 4.2. Packet Formats . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. EAP Encapsulation . . . . . . . . . . . . . . . . . . 10 4.2.2. EAPoL Type 0 Packet Format . . . . . . . . . . . . . 10 4.2.3. Request and Response Packets . . . . . . . . . . . . 12 4.2.4. EAP SRP-SHA256 Packet Formats . . . . . . . . . . . . 13 4.3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . 22 4.4. Re-Authentication . . . . . . . . . . . . . . . . . . . . 24 4.5. UDP Transport Considerations . . . . . . . . . . . . . . 25 4.6. Multicast Authentication (Informative) . . . . . . . . . 26 4.7. Multi-Link Operation . . . . . . . . . . . . . . . . . . 27 4.8. Authentication Example . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. Internationalization Considerations . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . 32 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction The method described in this document is designed for network applications desiring an authentication protocol in which a robust, mutual, and non-leaky exchange of credentials is required. For each authentication instance, the model is as follows: There is one Server and one or more Clients. There is a username and password for each Client. These are known to both the Server and the Client and configured through out-of- band means. The protocol provides a secure way for the Client and the Server to prove to each other that they know the correct username and password without any additional previous information or setup. Moreover, a third party observing the traffic cannot obtain the password nor successfully authenticate by replaying the traffic. Clients shall only communicate with the Server. The Clients shall initiate the communication with the Server by following the steps in section 3.3. The Server shall initiate the authentication protocol. Ammirata, et al. Expires 27 May 2023 [Page 3] Internet-Draft EAP SHA256 SRP6a November 2022 The Server and Clients shall not send, receive or process any communication other than the steps described in section 4.3 until the mutual authentication completes successfully. 2. Requirements Language This document is consistent with RFC 2119 Internet Best Current Practices regarding key words for use in RFCs to indicate requirements levels. 3. Protocol Encapsulation The packets described in this document are EAP packets, encapsulated using EtherType 0x888E. This section describes three encapsulation methods for the EAP packets, as follows: A Layer-2 encapsulation method, where server and clients are in the same local network. A Layer-3 encapsulation method over IP, where server and clients can be in different networks. A Layer-4 encapsulation method over UDP/IP, where multiple server instances can be running in the same host. If there are firewalls between server and clients, this method simplifies the configuration of such firewalls. 3.1. Layer-2 Encapsulation When using Layer-2 Encapsulation, the EAP packets described in this document are encapsulated in Ethernet packets with EtherType 0x888E, as shown in Figure A. Figure A: Layer-2 Encapsulation :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype=0x888E | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP Packet | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ammirata, et al. Expires 27 May 2023 [Page 4] Internet-Draft EAP SHA256 SRP6a November 2022 3.2. Layer-3 Encapsulation Using GRE When using Layer-3 Encapsulation, the EAP packets described in this document are encapsulated using GRE over IP as per RFC 2784 [RFC2784] as shown in Figure B. Packet encryption shall not be used. Figure B: Layer-3 Encapsulation :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IP Header with Protocol=47 (GRE) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : GRE Header with Protocol Type = 0x888E : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : EAP Packet : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3. Layer-4 Encapsulation Using GRE Over UDP When using Layer-4 Encapsulation, the EAP packets described in this document are encapsulated using GRE over UDP as per [RFC8086], with the following modifications: Packets shall not be encrypted. There is no restriction on what UDP ports are used by the server. The encapsulation is shown in Figure C. Figure C: Layer-4 Encapsulation :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IP Header with Protocol=17 (UDP) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UDP Header : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : GRE Header with Protocol Type = 0x888E : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : EAP Packet : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ammirata, et al. Expires 27 May 2023 [Page 5] Internet-Draft EAP SHA256 SRP6a November 2022 4. Description of the EAP SHA256-SRP6a Authentication Protocol 4.1. Authentication Algorithm and Protocol Fundamentally, the authentication algorithm is based on a username/ password pair. The Server has a list of all the usernames and passwords (in a secure format); an authorized Client knows its username and password as well. The authentication algorithm provides a secure way for the Client to prove to the Server that it knows a valid username/password pair, in a way that a third-party monitoring the transactions cannot use the information exchanged to later successfully login to the Server. It also provides a secure way for the Client to authenticate the Server. Finally, the algorithm also generates a common strong ephemeral shared key that may be used to encrypt future unicast communication between the authenticated Client and the Server. The algorithm is based on two fundamental values, the generator value "g" and the prime modulus "N". The Server may use different values of "g" and "N" per Client, since these values are communicated to the Client at the beginning of the negotiation. The following rules shall be observed: As indicated in section 4.2.4.1, if "g" is not indicated, the Client shall assume the default value of 2. "N" shall be a large safe prime, of at least 512 bits. If "N" is not indicated, the Client shall assume the default 2048-bit value indicated in section 4.2.4.1. The value "g" shall not be higher than "N". In the algorithm description below, the following operations are used: % Modulo operator (as in the C programming language); the remainder of a division. The notation x % y shall indicate the remainder of the division of "x" by "y". ^ Modulo "N" exponentiation. The notation x ^ y shall indicate the remainder of "x" to the power "y" when divided by the prime modulus "N". Example: x = 2 y = 10 N = 263 x^y = (2^10) modulo 263 = 1024 modulo 263 = 235 (remainder of 1024/263) Ammirata, et al. Expires 27 May 2023 [Page 6] Internet-Draft EAP SHA256 SRP6a November 2022 | String concatenation. This operator creates a string that is a concatenation of its two arguments, in the same manner as the "strcat" function in a standard C library. The algorithm shall use the SHA256 hashing algorithm. If multiple arguments are provided to the SHA256 function, this indicates that the arguments shall be concatenated, and the SHA256 function applied to the combined value. For example, SHA256(x, y) means "create a buffer with the contents of "x", followed by the contents of "y", and apply the SHA256 algorithm to the resulting buffer". When the SHA256 hash is applied to a string, the null terminator (if present) shall not be included in the hash computation. For each Client, the Server shall select a random salt "s", containing at least four octets. If the Client password is denoted by "P" and the Client username by "I", the separator character being ":", use of said character shall be disallowed for use in "P" or "I". The Server shall compute the value "x" defined by: x = SHA256(s, SHA256(I | ":" | P)) For each Client, the Server shall compute the password verifier "v" as follows: v = g^x The Server shall store the values "s" and "v" for each Client, indexed by the Client username "I". The Server should not store the cleartext password "P". The Client starts the authentication process by contacting the Server using the EAPoL-Start message of section 4.2.1 (or any empty message, such as a keep-alive). The Server requests the Client username "I" using the Identity Request message of section 4.2.3.1, and the Client returns this information using the Identity Response message of section 4.2.3.1. If the username "I" is known to the Server, the Server sends the corresponding "s", "g" and "N" values to the Client using the Challenge Request Packet of section 4.2.4.1. If the Client's username is not known to the Server, it may abort at this point or continue with fake values for "s", "g" and "N". This is described in detail in section 4.2.4.1. Upon reception of the Challenge Request Packet, the Client caches the "s", "g", and "N" values, and generates a random number "a" between 1 and N-1. It then computes the value "A" as follows: Ammirata, et al. Expires 27 May 2023 [Page 7] Internet-Draft EAP SHA256 SRP6a November 2022 A = g^a The value "A" is returned to the Server in the Client Key Response Packet of section 4.2.4.2. The Server caches this value for later use. Upon reception of the Client Key Response, the Server generates a random number "b" between 1 and N-1, and computes the value "B" as follows: k = SHA256(N, g) B = (kv + g^b) % N The value "B" is returned to the Client in the Server Key Request Packet of section 4.2.4.3. Upon receiving the value "B", the Client performs the following computations: u = SHA256(A, B) x = SHA256(s, SHA256(I, ":", P)) k = SHA256(N, g) S = ((B - kg^x) ^ (a +ux)) % N K = SHA256(S) M1 = SHA256(SHA256(N) xor SHA256(g), SHA256(I, s, A, B, K)) The value "M1" above is returned to the Server in the Client Validator Response Packet from section 4.2.4.4, and the Client caches the session key "K". Upon receiving the "M1" value, the Server performs the following computations: u = SHA256(A, B) S = ((Av^u) ^ b) % N K = SHA256(S) M1 = SHA256(SHA256(N) xor SHA256(g), SHA256(I, s, A, B, K)) If the local "M1" calculation yields the same value as the received "M1" value, the Server shall consider the Client as authenticated. The Server computes the value "M2" as follows: M2 = SHA256(A, M1, K) The "M2" value is returned to the Client using the Server Validator Request Packet from section 4.2.4.5. Upon receiving this packet, the Client performs the same computation, and if the local calculation yields the same "M2" value as the received packet, the Client shall consider the Server authenticated. Ammirata, et al. Expires 27 May 2023 [Page 8] Internet-Draft EAP SHA256 SRP6a November 2022 4.2. Packet Formats This section describes the various packet formats used in the authentication process. The packet formats in the illustration follow a hierarchical structure based on GRE-encapsulated EAPoL packets. The hierarchy is depicted in Figure 1. The boxed items in Figure 1 represent the actual packets transmitted in the network at the various phases of the protocol and are documented in this section. All protocol transactions shall use unicast addressing between Server and Client. Figure 1: Authentication Packet Format Hierarchy : +------------+ : |EAPoL Packet| : +------------+ : / | \ : / | \ :+------------+ +------------+ +------------+ :| Start | | Logoff | | EAP Packet | :+------------+ +------------+ +------------+ : / / | \ : --------------- / | \ : / / | \ : +------------+ +------------+ | \ : | Success | | Failure | | \ : +------------+ +------------+ +------------+ +------------+ : | Request | | Response | : +------------+ +------------+ : | / : | / : --------------- : / | \ : +---------+ +---------------+ +------------+ : | NAK | |EAP SRP SHA256 | | IDENTITY | : +---------+ +---------------+ +------------+ : | | : | | : +------------------+ +------------------+ : | CHALLENGE | | CLIENT KEY | : +------------------+ +------------------+ : | | : +------------------+ +------------------+ : | SERVER KEY | | CLIENT VALIDATOR | : +------------------+ +------------------+ : | | : +------------------+ | : | SERVER VALIDATOR | | Ammirata, et al. Expires 27 May 2023 [Page 9] Internet-Draft EAP SHA256 SRP6a November 2022 : +------------------+ | : | | : +------------------+ +------------------+ : | PASSPHRASE | | PASSPHRASE | : +------------------+ +------------------+ 4.2.1. EAP Encapsulation Figure 2 shows the authentication packet format. Figure 2: Authentication Packet Format :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Packet Payload (EAPoL Type=0) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in Figure 2 are to be set as follows: EAP Version (8 bits): this field shall be set to "3" to indicate compliance with this Specification. EAPoL Type (8 bits): set this field as follows: 0x00: EAPoL-EAP: the packet payload field contains an EAP packet. 0x01: EAPoL-Start: optional packet sent by the Client to initiate the authentication process with the Server. EAPoL-Start packets do not have a payload field. 0x02: EAPoL-Logoff: optional packet sent before closing the connection, to revert to the non-authenticated state. This packet can be sent by either Server or Client. EAPoL-Logoff packets do not have a payload field. 0x03-0xFF: Reserved. Receivers shall silently discard packets with these types. Payload Length (16 bits): set this field to the length, in bytes, of the Packet Payload field. For EAPoL-Start and EAPoL-Logoff packets, which have no payload, set this field to "0" zero for those two packet types. 4.2.2. EAPoL Type 0 Packet Format Figure 3 shows the packet payload format for EAPoL Type 0. Figure 3: Packet Payload for EAPoL Type=0 Ammirata, et al. Expires 27 May 2023 [Page 10] Internet-Draft EAP SHA256 SRP6a November 2022 :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (variable, depends on Code) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Set the fields in Figure 3 as follows: Code (8 bits): set this field to identify the type of EAP packet, as follows: 0x01: Request 0x02: Response 0x03: Success 0x04: Failure All other values: reserved. Receivers shall silently discard packets with these values. Identifier (8 bits): this field is used to match responses with requests. The initial request shall select an arbitrary value for the request packet. The response shall use the same value in the response to that request, which may be a Response packet, a Success packet, or a Failure packet. The identifier shall be incremented by one at every new request message. It shall not be changed on a retransmission of a message. Any non-matching Response messages shall be discarded. As indicated in section 4, a full authentication exchange includes up to four distinct packets originated by the authentication Server. The authentication Server shall use four consecutive values for the Identifier field for full protocol exchange. Successive protocol exchanges for the same connection (identified by Client IP address and source UDP port) shall use non- overlapping Identifier values. Since the Identifier field is only 8 bits, the value 0x00 is deemed to follow the value 0xFF. Length (16 bits): set this field to the length of the EAP packet, including the Code, Identifier, Length and the variable-size data. If the overall packet is longer than what is indicated by the length field, additional octets shall be ignored. If the overall packet is truncated (i.e., not enough octets received to satisfy the length field), the packet shall be discarded. Data (variable): the data field is zero or more octets. The size and format of the data field depends on the Code field, as described below. Ammirata, et al. Expires 27 May 2023 [Page 11] Internet-Draft EAP SHA256 SRP6a November 2022 4.2.3. Request and Response Packets Figure 4 shows the packet payload format for Request (Code=0x01) and Response (Code=0x02) packets. Figure 4: Packet Payload Format for Request/Response Packets :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 or 2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type-Data (variable, depends on Type) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Set the fields in Figure 4 as follows: Type (8 bits): the Type field shall indicate the format of the messages used in the Request/Response exchanges. The following values are defined in this document: 0x01: Identity 0x03: Nak (only valid for Response packets, shall not be sent on Request packets) 0x13: EAP SRP-SHA256 All other values reserved. Type-Data (variable): set this field depending on the Type value, as documented below. 4.2.3.1. Identity Request/Response Packets Identity Request packets are sent from the Server to the Client. Upon reception of the Identity request packet, the Client shall answer with the Identity Response packet. In the Identity Request packet, the Server may include a displayable message in the Type-Data field. The Client shall return its identity as a string (typically the Username) in the Type-Data field. Strings shall not be null- terminated. Figure 5: Identity Packets :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | Ammirata, et al. Expires 27 May 2023 [Page 12] Internet-Draft EAP SHA256 SRP6a November 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 or 2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x01 | Message for Code=1, Username for Code=2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.3.2. Nak Response Packets Nak Response Packets shall be sent in response to any unknown or unsupported requests. The Type-Data field shall be set to one octet with value 0x13, to indicate that only EAP SRP-SHA256 authentication is supported. The Nak response packet is shown in Figure 6. Figure 6: Nak Response Packet :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length=6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 | Identifier | Length=6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x03 | Data=0x13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.4. EAP SRP-SHA256 Packet Formats Figure 7 shows the packet formats for the EAP SRP-SHA256 packets. Figure 7: EAP SRP-SHA256 Packet Formats :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 or 2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x13 | Subtype | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subtype-Data (variable) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Set the fields in Figure 7 as follows: Subtype (8 bits): the subtype field shall be set to one of the following values: Ammirata, et al. Expires 27 May 2023 [Page 13] Internet-Draft EAP SHA256 SRP6a November 2022 0x01: Challenge / Client Key 0x02: Server Key / Client Validator 0x03: Server Validator 0x10: Passphrase Request / Response All other values reserved. If a device receives an unknown subtype, it shall respond with a packet of Type Nak. Subtype Data (variable): set this field depending on the Type and Subtype values, as documented below. 4.2.4.1. EAP SRP-SHA256 Challenge Request Packet The EAP SRP-SHA256 Challenge is a Request packet sent from the Server to the Client once the username has been received from the Client. It includes the unauthenticated Server name for verification purposes, the password salt "s", the generator value "g", and the prime modulus "N". The packet format is shown in Figure 8. Figure 8: EAP SRP-SHA256 Challenge Packet :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x13 | Subtype=0x01 | Name Length |Name (variable): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Salt Length | Salt (variable) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gen Length | Generator (variable) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prime Modulus (variable) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Set the fields in the packet in Figure 8 as follows: Name Length (8 bits): a single octet giving the length of the Name field in octets. Ammirata, et al. Expires 27 May 2023 [Page 14] Internet-Draft EAP SHA256 SRP6a November 2022 Name (variable): the Server name. This field is not authenticated. The Server name may be used by the Client in an implementation-dependent manner. It shall not be treated by the Client as an authenticated name. Salt Length (8 bits): a single octet giving the length of the Salt field in octets. The Salt Length shall be at least 4 octets and may be any length up to 255 octets. Salt (variable): password salt; may contain any values. The contents of this field shall correspond to "s" in the SRP algorithm. Gen Length (8 bits): a single octet giving the length of the Generator field in octets. If this field has the value zero, the default generator value of 2 shall be used and the Generator field shall not be present. Generator (variable): the Generator value, called "g" in the SRP algorithm, is in network byte order. If the Gen Length field is zero, then the Generator field shall be omitted, and "g" shall be set to 2. Prime Modulus (variable): the Prime Modulus value, called "N" in the SRP algorithm, is in network byte order and fills the rest of the message to the length specified by the Length field in the EAP header. If the Gen Length field is zero, the Prime Modulus field may be omitted to select the default "N" value listed below. If the Prime Modulus field is present, then it should be at least 64 octets (512 bits). Longer values are recommended. If the Prime Modulus field in Figure 8 is empty, the Client shall assume the value below for value "N". In this case, the Gen Length value shall be zero and the Generator value shall be assumed as "2". The value for "N" is: 0xAC, 0x6B, 0xDB, 0x41, 0x32, 0x4A, 0x9A, 0x9B, 0xF1, 0x66, 0xDE, 0x5E, 0x13, 0x89, 0x58, 0x2F, 0xAF, 0x72, 0xB6, 0x65, 0x19, 0x87, 0xEE, 0x07, 0xFC, 0x31, 0x92, 0x94, 0x3D, 0xB5, 0x60, 0x50, 0xA3, 0x73, 0x29, 0xCB, 0xB4, 0xA0, 0x99, 0xED, 0x81, 0x93, 0xE0, 0x75, 0x77, 0x67, 0xA1, 0x3D, 0xD5, 0x23, 0x12, 0xAB, 0x4B, 0x03, 0x31, 0x0D, 0xCD, 0x7F, 0x48, 0xA9, 0xDA, 0x04, 0xFD, 0x50, 0xE8, 0x08, 0x39, 0x69, 0xED, 0xB7, 0x67, 0xB0, 0xCF, 0x60, 0x95, 0x17, 0x9A, 0x16, 0x3A, 0xB3, 0x66, 0x1A, 0x05, 0xFB, 0xD5, 0xFA, 0xAA, 0xE8, 0x29, 0x18, 0xA9, 0x96, 0x2F, 0x0B, 0x93, 0xB8, 0x55, 0xF9, 0x79, 0x93, 0xEC, 0x97, 0x5E, 0xEA, 0xA8, 0x0D, 0x74, 0x0A, 0xDB, 0xF4, 0xFF, 0x74, 0x73, 0x59, 0xD0, 0x41, 0xD5, 0xC3, 0x3E, 0xA7, 0x1D, 0x28, 0x1E, 0x44, 0x6B, 0x14, 0x77, 0x3B, 0xCA, 0x97, 0xB4, 0x3A, Ammirata, et al. Expires 27 May 2023 [Page 15] Internet-Draft EAP SHA256 SRP6a November 2022 0x23, 0xFB, 0x80, 0x16, 0x76, 0xBD, 0x20, 0x7A, 0x43, 0x6C, 0x64, 0x81, 0xF1, 0xD2, 0xB9, 0x07, 0x87, 0x17, 0x46, 0x1A, 0x5B, 0x9D, 0x32, 0xE6, 0x88, 0xF8, 0x77, 0x48, 0x54, 0x45, 0x23, 0xB5, 0x24, 0xB0, 0xD5, 0x7D, 0x5E, 0xA7, 0x7A, 0x27, 0x75, 0xD2, 0xEC, 0xFA, 0x03, 0x2C, 0xFB, 0xDB, 0xF5, 0x2F, 0xB3, 0x78, 0x61, 0x60, 0x27, 0x90, 0x04, 0xE5, 0x7A, 0xE6, 0xAF, 0x87, 0x4E, 0x73, 0x03, 0xCE, 0x53, 0x29, 0x9C, 0xCC, 0x04, 0x1C, 0x7B, 0xC3, 0x08, 0xD8, 0x2A, 0x56, 0x98, 0xF3, 0xA8, 0xD0, 0xC3, 0x82, 0x71, 0xAE, 0x35, 0xF8, 0xE9, 0xDB, 0xFB, 0xB6, 0x94, 0xB5, 0xC8, 0x03, 0xD8, 0x9F, 0x7A, 0xE4, 0x35, 0xDE, 0x23, 0x6D, 0x52, 0x5F, 0x54, 0x75, 0x9B, 0x65, 0xE3, 0x72, 0xFC, 0xD6, 0x8E, 0xF2, 0x0F, 0xA7, 0x11, 0x1F, 0x9E, 0x4A, 0xFF, 0x73 4.2.4.2. EAP SRP-SHA256 Client Key Response Packet The EAP SRP-SHA256 Client Key is a Response packet sent by the Client in response the Challenge packet described in section 4.2.4.1. The packet format is shown in Figure 9. Figure 9: EAP SRP-SHA256 Client Key Packet Format :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x13 | Subtype=0x01 | Value A (variable) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Client shall set the fields in Figure 9 as follows: Value A (variable): the result of g^a, where "a" is a randomly chosen number in the range 1 .. N (exclusive), as described in section 4.1. The randomly chosen number is the Client's private key, and the Value A field is the corresponding public key. This field shall be in network byte order and shall not be padded. The "A" value shall not be zero modulo N. If the Server receives a bad value for this field, it shall send a Failure packet described in section 4.2.5 and shall disconnect the link. 4.2.4.3. EAP SRP-SHA256 Server Key Request Packet The EAP SRP-SHA256 Server Key is a Request packet sent by the Server after it has received the Client Key packet described in section 4.2.4.2. The packet format is shown in Figure 10. Ammirata, et al. Expires 27 May 2023 [Page 16] Internet-Draft EAP SHA256 SRP6a November 2022 Figure 10: EAP SRP-SHA256 Server Key Packet Format :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x13 | Subtype=0x02 | Value B (variable) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in Figure 10 shall be set as follows: Value B (variable): the result of (kv + g^b) % N, where "b" is a randomly chosen number in the range 1 .. N (exclusive), "v" is the stored verifier from the authentication database, and k=SHA256(N, g), as described in section 3.1. The randomly chosen number is the Server's private key, and the Value B field is the corresponding public key. This field shall be in network byte order and shall not be padded. The B value shall not be zero modulo N. If the Client receives a bad value for this field, it shall send a Failure packet described in section 4.2.5 and shall disconnect the link. 4.2.4.4. EAP SRP-SHA256 Client Validator Response Packet The EAP SRP-SHA256 Client Validator is a Response packet sent by the Client in response to the Server Key packet described in section 4.2.4.5. The packet format is shown in Figure 11. Figure 11: EAP SRP-SHA256 Client Validator Packet Format :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x13 | Subtype=0x02 | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 |U| Value M1 (32 octets) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Client shall set the fields in Figure 11 as follows: Ammirata, et al. Expires 27 May 2023 [Page 17] Internet-Draft EAP SHA256 SRP6a November 2022 Reserved1 (16 bits), Reserved2 (15 bits): the Client shall set these bits to zero on transmission, and the Server shall ignore them on reception. U (1 bit): the Client shall set this bit to signal to the Server that it intends to use the derived key K (see section 4.1 and the M1 computation below) as the PSK passphrase. If this bit is set, the Server shall use K as the passphrase to decrypt the traffic received from the Client. M1 (32 octets): the 32 octet values are calculated as follows (see section 3.1): x = SHA256(s, SHA256(I | ":" | P)) u = SHA256(A, B) S = ((B - kg^x) ^ (a +ux)) % N K = SHA256(S) M1 = SHA256(SHA256(N) xor SHA256(g), SHA256(I, s, A, B, K)) Upon reception of the Client Validator response, the Server shall compute the M1 value and check against the value that is received from the Client. If the value matches, the Client is deemed authenticated and the Server sends the Server Validator Request packet described in section 4.2.4.5. If the M1 value does not match, authentication has failed. The Server shall send the Failure packet described in section 4.2.5 and shall disconnect the link. 4.2.4.5. EAP SRP-SHA256 Server Validator Request Packet The EAP SRP-SHA256 Server Validator is a Request packet sent by the Server in response to the Client Validator packet described in section 4.2.4.4. The packet format is shown in Figure 12. Figure 12: EAP SRP-SHA256 Server Validator Packet Format :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x13 | Subtype=0x03 | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 |U| Value M2 (32 octets) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Server shall set the fields in Figure 12 as follows: Ammirata, et al. Expires 27 May 2023 [Page 18] Internet-Draft EAP SHA256 SRP6a November 2022 Reserved1 (16 bits), Reserved2 (15 bits): the Server shall set these bits to zero on transmission, and the Client shall ignore them on reception. U (1 bit): the Server shall set this bit to signal to the Client that it intends to use the derived key K (see section 4.1 and the M2 computation below) as the PSK passphrase. If this bit is set, the Client shall use K as the passphrase to decrypt the subsequent traffic received from the Server. M2 (32 octets): the 32 octet values are calculated as follows: u = SHA256(A, B) S = ((Av^u) ^ b) % N K = SHA256(S) M2 = SHA256(A, M1, K) Upon reception of the Server Validator request, the Client shall compute the M2 value and check against what was received from the Server. If the value matches, the Server is deemed authenticated and the Client shall send the Success packet described in section 4.2.5 and the authentication process is complete. If the M2 value does not match, authentication has failed. The Client shall send the Failure packet described in section 4.2.5 and shall disconnect the link. 4.2.4.6. EAP SRP-SHA256 Passphrase Request Packet The EAP SRP-SHA256 Passphrase Request packet is used to request the passphrase currently in use. This packet may be used by the Client and/or the Server, as different passphrases may be in use on either communication direction. The packet format is shown in Figure 13. Figure 13: EAP SRP-SHA256 Passphrase Request Packet :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length=6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 | Identifier | Length=6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x13 | Subtype=0x10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If used, this packet shall only be transmitted after both the Server and the Client have been authenticated. The recipient of the packet shall respond to it as follows: Ammirata, et al. Expires 27 May 2023 [Page 19] Internet-Draft EAP SHA256 SRP6a November 2022 If the recipient of the packet does not support passphrase requests, it shall respond with the Nak packet as per section 4.2.3.2. If the recipient of the packet supports passphrase requests, it shall respond as follows: If authentication is not complete, the recipient of the packet shall respond with the Failure packet as per section 4.2.5. If authentication is complete, the recipient of the packet shall respond with the EAP SRP-SHA256 Passphrase Response as per section 4.2.4.7. 4.2.4.7. EAP SRP-SHA256 Passphrase Response Packet The EAP SRP-SHA256 Passphrase Response provides the passphrase, encrypted by the common session K. As indicated in section 4.2.4.6, this response is only issued if authentication has successfully completed. The packet format is shown in Figure 14. Figure 14: EAP SRP-SHA256 Passphrase Response Packet :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x13 | Subtype=0x10 |U|H| Reserved | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : Encrypted Passphrase (variable) ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in Figure 14 shall be set as follows: U (1 bit): this bit shall be set to the same value as the U bit in the validator packet transmitted by the sender (either the Client Validator in Figure 29 or the Server Validator in Figure 30). If this bit is set, it indicates that the session key K is to be used as the passphrase. In this case, the Encrypted Passphrase field in Figure 32 is not included in the packet. H (1 bit): this bit indicates the AES key length used in the encryption of the passphrase. The current values are currently limited to the following, but may be added to in the future: H=0: 128-bit H=1: 256-bit Ammirata, et al. Expires 27 May 2023 [Page 20] Internet-Draft EAP SHA256 SRP6a November 2022 Reserved (6 bits): this field shall be set to zero by the sender and ignored by the receiver. Encrypted Passphrase (variable): this field shall be set to the encrypted passphrase, generated as follows: Encryption algorithm: AES-CTR. Key length: as indicated by the H bit. Key: the first 128 or 256 bits of the session key K. IV: Initialization Vector. The most significant 8 bits of the IV shall be set to the value in the Identifier field. The remainder of the IV shall be padded with zeros. The recipient of the EAP SRP-SHA256 Passphrase Response packet shall acknowledge its reception by sending a Success packet (see section 4.2.5) with the same Identifier as the Passphrase Response packet being acknowledged. If this protocol is to be used within an application employing an on- the-fly passphrase change mechanism, the side responsible for generating the passphrase may optionally send an unsolicited Passphrase Response Packet with a new passphrase. In such a situation, it shall use a value for the Identifier field that is different from the previous Passphrase Response packet. It shall not send a new passphrase until it starts using the passphrase from the last Passphrase Response packet to generate the key used to encrypt the stream. In a multicast environment, this same side is responsible for contacting all others that are selected to receive the new passphrase; the details of this process are left to the discretion of the implementer. 4.2.4.8. Success and Failure Packet Formats Figure 15 shows the packet format for Success (code 3) and Failure (code 4) packets. Such packets have no additional data. Set the Identifier to match the value of the corresponding Request/Response packet. Figure 15: Packet Payload Format for Success/Failure Packets :0 1 2 3 :0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Version=3 | EAPoL Type=0 | Payload Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=3 or 4 | Identifier | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ammirata, et al. Expires 27 May 2023 [Page 21] Internet-Draft EAP SHA256 SRP6a November 2022 4.3. Protocol Exchanges This section describes the authentication protocol exchanges. For each exchange, the Server selects a starting value for the 8-bit Identifier field as described in section 4.2.2, and increments this value for each successive request. In the protocol exchanges presented in this section, the starting value of the Identifier field is denoted by n. Figure 16 shows the protocol exchange for a successful authentication exchange. The Client can start the process (message 1) using the EAPoL-Start message or any unsolicited message, such as a keep-alive packet. Figure 16: Protocol Exchange for Successful Authentication +----+----------------------------+---+----------------------------+ | | Client | | Server | | | Message | Doc | ID | | Message | Doc | ID | +----+--------------+-------+-----+---+--------------+-------+-----+ | 1 | EAPoL-Start | 4.1 | | > | | | | | 2 | | | | < | Identity Req | 4.3.1 | n | | 3 | Identity Res | 4.3.1 | n | > | | | | | 4 | | | | < | Challenge | 4.4.3 | n+1 | | 5 | Client Key | 4.4.4 | n+1 | > | | | | | 6 | | | | < | Server Key | 4.4.4 | n+2 | | 7 | Client Val | 4.4.6 | n+2 | > | | | | | 8 | | | | < | Server Val | 4.4.7 | n+3 | | 9 | Success | 4.5 | n+3 | > | | | | +----+----------------------------+---+----------------------------+ Figure 17 shows a possible protocol exchange for the case where the username is unknown to the Server. Use of this protocol exchange for unknown usernames allows a third party to "test" whether some usernames exist in the Server. If this is a concern, the protocol exchange shown in Figure 18 may be used instead, with the Server sending random data in messages 4 and 6. Figure 17: Protocol Exchange for Unknown Username Ammirata, et al. Expires 27 May 2023 [Page 22] Internet-Draft EAP SHA256 SRP6a November 2022 +----+----------------------------+---+----------------------------+ | | Client | | Server | | | Message | Doc | ID | | Message | Doc | ID | +----+--------------+-------+-----+---+--------------+-------+-----+ | 1 | EAPoL-Start | 4.1 | | > | | | | | 2 | | | | < | Identity Req | 4.3.1 | n | | 3 | Identity Res | 4.3.1 | n | > | | | | | 4 | | | | < | Failure | 4.5 | n | +----+--------------+-------+-----+---+--------------+-------+-----+ Figure 18 shows the protocol exchange when the Client authentication fails. This is determined at the Server when the value carried in the Client Validator packet in message 7 does not match the value computed by the Server. This will happen if the Client does not have the correct password. This exchange can also be used when the Client username does not exist in the Server, with random (fake) data in messages 4 and 6. Figure 18: Protocol Exchange for Client Authentication Failure +----+----------------------------+---+----------------------------+ | | Client | | Server | | | Message | Doc | ID | | Message | Doc | ID | +----+--------------+-------+-----+---+--------------+-------+-----+ | 1 | EAPoL-Start | 4.1 | | > | | | | | 2 | | | | < | Identity Req | 4.3.1 | n | | 3 | Identity Res | 4.3.1 | n | > | | | | | 4 | | | | < | Challenge | 4.4.3 | n+1 | | 5 | Client Key | 4.4.4 | n+1 | > | | | | | 6 | | | | < | Server Key | 4.4.4 | n+2 | | 7 | Client Val | 4.4.6 | n+2 | > | | | | | 8 | | | | < | Failure | 4.5 | n+2 | +----+--------------+-------+-----+---+--------------+-------+-----+ Figure 18 shows the protocol exchange when the Server validation fails. This will likely only happen if the Client is connecting to a device who is impersonating the Server. Such a device will have no knowledge of the password; it can go through the steps and pretend they completed successfully, but at message 8, the Client detects that the Server validation has failed. Message 9 in Figure 19 is at the option of the Client. If Server validation fails, the Client may simply stop communicating with the Server and may ignore all further messages from it. Figure 19: Protocol Exchange for Server Authentication Failure Ammirata, et al. Expires 27 May 2023 [Page 23] Internet-Draft EAP SHA256 SRP6a November 2022 +----+----------------------------+---+----------------------------+ | | Client | | Server | | | Message | Doc | ID | | Message | Doc | ID | +----+--------------+-------+-----+---+--------------+-------+-----+ | 1 | EAPoL-Start | 4.1 | | > | | | | | 2 | | | | < | Identity Req | 4.3.1 | n | | 3 | Identity Res | 4.3.1 | n | > | | | | | 4 | | | | < | Challenge | 4.4.3 | n+1 | | 5 | Client Key | 4.4.4 | n+1 | > | | | | | 6 | | | | < | Server Key | 4.4.4 | n+2 | | 7 | Client Val | 4.4.6 | n+2 | > | | | | | 8 | | | | < | Server Val | 4.4.7 | n+3 | | 9 | Failure | 4.5 | n+3 | > | | | | +----+--------------+-------+-----+---+--------------+-------+-----+ 4.4. Re-Authentication In some situations, it is desirable to periodically re-authenticate the endpoints (Server and/or Client). If requested by the other endpoint, Server or Client shall respond to the re-authentication process described in this section. Server and Client may support initiating the re-authentication process. During re-authentication, normal data exchange between Server and Client shall continue. If re-authentication fails, all communication between Server and Client shall stop. To start re-authentication by Server request, the Server shall send an Identity Request packet (section 4.2.3.1) to the Client to start the process. This is packet 2 in Figure 16. The protocol will then follow the steps shown in Figure 16 for successful authentication, or Figure 17, Figure 18 or Figure 19 for authentication failures. To start re-authentication by Client request, the Client shall send an EAPoL-Start packet (section 4.2.2) to the Server to start the process. This is packet 1 in Figure 16. The protocol will then follow the steps shown in Figure 16 for successful authentication, or Figure 17, Figure 18 or Figure 19 for authentication failures. The re-authentication process will yield a new session key K. If either the Server and/or the Client signal the use of the session key K as the PSK passphrase by using the U bit in the messages described in sections 4.2.4.6 and/or 4.2.4.7, the protocol described in section 4.4 shall be used to switch to the new passphrase. If Server and/or Client are using the session key as the PSK passphrase, they are not required to set the U bit in the re-authentication session; in such a case, the original passphrase remains in use. Ammirata, et al. Expires 27 May 2023 [Page 24] Internet-Draft EAP SHA256 SRP6a November 2022 The interval between successive re-authentication sessions between a Server and a given Client shall be no less than 60 seconds. 4.5. UDP Transport Considerations The protocol described in this document runs over UDP. Therefore, it is possible for packets to be re-ordered, duplicated, or dropped. The authentication process is driven by the Server. If an expected response is not received by a given timeout interval, the request is retried. The Server shall discard duplicate responses. After a certain number of retries, the Server shall discard all the information received and shall wait to be contacted again by the Client. The number of retries is left at the discretion of the implementer but should be no less than three. The timeout is also left at the discretion of the implementer. It is recommended that it be a multiple of the round-trip time between Server and Client. As indicated in Figure 16, a successful authentication exchange requires four packets from the Server, and the first packet is the Identity Request (section 4.2.3.1). The Client shall save the Identifier from that message, which we will denote by n. The Client shall only respond to packets with Identifier in the range of n to n+3 and shall silently discard all packets with identifier values not in this range. If a Client receives a packet with an identifier value of k, with n < k less than or equal to n+3, the Client shall silently discard this packet if it has yet not received the packet with identifier k-1. If the last response the Client sent was for identifier k, with n < k less than or equal to n+3, and now the Client receives a packet with identifier m, with n less than or equal to m less than or equal to k, it shall re-send the original response for identifier m. During an authentication session, the random Server and Client keys shall not change. For example, if the Client receives a duplicate Challenge packet (message 4 in Figure 16), it shall re-send the same Client Key response as with the original request. The Client shall implement a timeout mechanism for expected messages from the Server, until authentication completes. If a protocol message does not arrive by a given timeout interval, the Client shall restart the authentication process. This timeout is left to the discretion of the implementer and should be a multiple of the round- trip time. Ammirata, et al. Expires 27 May 2023 [Page 25] Internet-Draft EAP SHA256 SRP6a November 2022 For the Passphrase Request/Response messages in sections 4.2.4.6 and 4.2.4.7, the sender of each message shall implement a timeout mechanism after each message. If a response is not received by a given timeout interval, the message is retried. After a certain number of retries, the sender shall abort the process. The recovery mechanism in this case is left to the discretion of the implementer. 4.6. Multicast Authentication (Informative) The mechanism described in this document can be used to provide authentication in a multicast streaming environment under the following conditions: When directed to an IP multicast address, while any device in the network can join the multicast, only authenticated devices are allowed to decrypt the content. Unicast bidirectional communication is possible between the sender and all receivers of the multicast. Receivers are configured with the multicast address and UDP port through external means not covered by this Specification. The sender of the stream is also the authentication Server. Alternatively, a separate authentication Server can be used, under the following conditions: The multicast receivers are configured with the IP address and UDP port of the authentication Server through external means not covered by this Specification. The authentication Server has knowledge of the passphrase in use to encrypt the multicast stream. Operation is as follows: The Client joins the multicast. Since it does not have the passphrase yet, it cannot decrypt the content. The Client uses the source IP address and source UDP port from the received multicast packets to initiate an authentication session with the Server/sender of the content. Alternatively, the Client may instead contact a pre-configured authentication Server. The authentication session is initiated with an EAPoL-Start packet, as described in in section 4.2.2. If the authentication session finishes successfully, the receiver requests the PSK passphrase using the passphrase request packet described in section 4.2.4.6, and the Server responds with the passphrase response packet described in section 4.2.4.7. Ammirata, et al. Expires 27 May 2023 [Page 26] Internet-Draft EAP SHA256 SRP6a November 2022 At this point, the Client can now decrypt the PSK stream. The Client may send keep-alive unicast packets back to the sender. The re-authentication process described in section 4.4 can be used in this multicast environment. As indicated in that section, the re- authentication can be started either by the Client or the Server. If a Client-initiated re-authentication fails, the Client shall leave the multicast and stop processing the data. Servers know which Clients are active due to the keep-alive messages. If the re-authentication fails with a subset of the receivers, the Server should change the PSK passphrase to remove their access. The process will happen as follows: The Server generates a new passphrase through means outside this Specification. The Server sends the new passphrase to the subset of receivers for which authentication succeeded, using the passphrase response packet and mechanism from section 3.4.9. For each allowed receiver, the session key from the new successful authentication will be used. Once all the allowed receivers have the new passphrase, the on- the-fly passphrase change mechanism from section 3.4 is used to switch to the new passphrase. 4.7. Multi-Link Operation It is possible to use the authentication mechanism described in this document in a multi-link application. In this case, there are multiple links between the Server and the Client. The following considerations apply to multi-link operation, at the discretion of the implementer: One option is to run independent authentication sessions on each link. Even if the same username/password is used in all links, the session key will be different per link. If the session key is used as the passphrase, each link will have its own PSK encryption key. Ammirata, et al. Expires 27 May 2023 [Page 27] Internet-Draft EAP SHA256 SRP6a November 2022 Another option is to combine the links. In this case, it is recommended that GRE use is implemented, whereby the GRE sequence number shall be included in the packet. The resulting combined and re-ordered packet flow is then used for authentication. In this case, a single authentication session and passphrase will be used across all links. This also allows for links to be dynamically added as needed at any time. 4.8. Authentication Example This section provides a numerical example of an authentication exchange. It is provided to allow implementations to be checked against known values. In the example below, all numeric values are presented in base 16 (hexadecimal). Underlined values are random numbers, bold values are computation results. The example uses the weakest legal modulus value (512-bit) for simplicity. Use of greater modulus length in actual implementations is encouraged. The inputs for the algorithm in this example are: Modulus "N": D66AAFE8E245F9AC245A199F62CE61AB8FA90A4D80C71CD2ADFD0 B9DA163B29F2A34AFBDB3B1B5D0102559CE63D8B6E86B0AA59C14E79D4AA62D174 8E4249DF3 Generator "g": 2 Username "I": rist Password "P": mainprofile The Server generates a random salt "s" for each username/password pair. In this example, the following salt value is used: Salt "s": 72F9D5383B7EB7599FB63028F47475B60A55F313D40E0BE023E026C97C0A2C32 The Server computes the password verifier "v" as follows (see section 3.1): x = SHA256(s, SHA256(I | ":" | P)) v = g^x For the example inputs, the values will be: Value "x": 8578DED647FC7E82D37886EBEF2C300EB0213CCC321D8A43A0DE2131B720C9C8 Ammirata, et al. Expires 27 May 2023 [Page 28] Internet-Draft EAP SHA256 SRP6a November 2022 Verifier "v": 557EA208F87A23C28936423EC16ABE6BD959933DFBEFC0B36EBD 9335DE3997C97DDFA081D64CFBC6EFBFD5BE19F2ED9F77922FD7E88BBA6C6B310A 9018EC4305 The Server stores the salt "s" and the verifier "v" indexed by the username "I". There is no need for the Server to store the password "P". Once this is in place, the Server is ready to authenticate the Client. As illustrated in Figure 16, the Client starts the authentication process by sending the EAPoL-Start packet. The Server will send the Identity Request packet, and the Client will respond with the Identity Response packet, indicating the (in this example) "rist" username. The Server will then send the Challenge Request packet from section 4.2.4.1 containing the values "s", "g" and "N", which are cached by the Client. The Client generates a random number "a" between 1 and N-1. In this example, the following value is used: Value "a": 138AB4045633AD14961CB1AD0720B1989104151C0708794491113302CCCC27D5 The Client uses the random value "a" to compute the Client key "A" using the following formula: A = g^a In this example, the Client key "A" value is computed as: Client key "A": 92C4CEFB95A1AE2E576A252B19273FD4613F44FDA4AC8CC84A 089D5740756223943882BAD34CB55F35139CDDB60E0D19ACD2B884CFB27F53C8EA 969269ABE014 The Client key "A" is returned to the Server using the Client Key Response Packet from section 4.2.4.2. The Server checks that A % N is not zero and caches the value "A". The Server generates a random number "b" between 1 and N-1. In this example, the following value is used: Value "b" ED0D58FF861A1FC75A0829BEA5F1392D2B13AB2B05CBCD6ED1E71AAAD761E856 The Server computes the Server key "B" as follows: k = SHA256(N, g) Ammirata, et al. Expires 27 May 2023 [Page 29] Internet-Draft EAP SHA256 SRP6a November 2022 B = (kv + g^b) % N In this example, the Server key "B" is computed as follows: Value "k": 890D0AC9E42A7F909D3CAA9A0FF115C52A1DC8DED10839EF9583C4E35EA76E78 Server key "B: 85CAE0C578E6927B78BEB173FB0F9BFC8ECB4C13542BB8BE3B0 F3447B3764A234177E22D180DCAD21F33302248B7452916DC58ABD309C8A77440A 228B8516A4E The Server key "B" is sent to the Client using the Server Key Request Packet from section 4.2.4.5. Upon receiving this value, the Client performs the following computations: x = SHA256(s, SHA256(I, ":", P)) k = SHA256(N, g) u = SHA256(A, B) S = ((B - kg^x) ^ (a +ux)) % N K = SHA256(S) M1 = SHA256(SHA256(N) xor SHA256(g), SHA256(I, s, A, B, K)) The values "x" and "k" for this example have already been computed and their values can be found above. The remaining values are: Value "u": 47BFBFEC70D89D5D9D61D52F9F446225A12C5DD7E3F55257C88772B0AEBB532A Value "S": 11426AB55E6550013743D08EB70D82F91404AA90CF0C63D8C168741 4C2F8DC9240795EEE40BAC37C5F29B07BBAEB2C0D6CF59CFADCBACD4D93F948FB6 2A0C96D Session key "K": 771A81C5888B81BA1BE71C8250EC1CC2A3BA67555364F4603260BE65099C5B97 Validator value "M1": EBFC2D79BEB3CBF7BA83C27E2B51524F8CD3F3B2C4804815AD2516D465DF80C9 The Client caches the session "K" for possible future use as a passphrase and returns the validator value "M1" back to the Server using the Client Validator Response Packet from section 4.2.4.4. Ammirata, et al. Expires 27 May 2023 [Page 30] Internet-Draft EAP SHA256 SRP6a November 2022 Upon receiving the "M1" value from the Client, the Server computes its own version of "K" and "M1" using the following formulas: u = SHA256(A, B) S = ((Av^u) ^ b) % N K = SHA256(S) M1 = SHA256(SHA256(N) xor SHA256(g), SHA256(I, s, A, B, K)) If the "M1" value computed by the Server matches what it received from the Client, the Client is deemed authenticated. In this case, the session key "K" will also match. The Server computes its validator value "M2" as follows: M2 = SHA256(A, M1, K) For this example, the value is: Validator value "M2": FB14D73B5ACBBA101E5A799F80EBCBB43D83890E23DED979110EEFF109C0441A 5. IANA Considerations The current document does not contain additional types or IDs for submission. 6. Internationalization Considerations Not applicable. 7. Security Considerations This entire document describes a security protocol, based upon other security protocols, for optional use with other security mechanisms. 8. References 8.1. Normative References [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . Ammirata, et al. Expires 27 May 2023 [Page 31] Internet-Draft EAP SHA256 SRP6a November 2022 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 2017, . 8.2. Informative References [Video_Services_Forum] Video Services Forum, "Video Services Forum (VSF) Technical Recommendation TR-06-2:2022", 2022, . Acknowledgements We acknowledge the editing assistance provided by John Iacovelli and Ciro Noronha. The description of this protocol was originally published by the Videos Services Forum [Video_Services_Forum] as part of a technical recommendation for the RIST error correction protocol. Authors' Addresses Sergio Ammirata SipRadius LLC. 6810 N. State Rd. 7 Suite 246 Coral Springs, Florida 33073 United States of America Email: sergio@ammirata.net URI: https://www.sipradius.com Gijs Peskens SipRadius LLC. 6810 N. State Rd. 7 Suite 246 Coral Springs, Florida 33073 United States of America Email: gils@ammirata.net Brad Gilmer Video Services Forum United States of America Email: brad@gilmer.tv URI: https://www.vsf.tv John Iacovelli (editor) Video Services Forum United States of America Ammirata, et al. Expires 27 May 2023 [Page 32] Internet-Draft EAP SHA256 SRP6a November 2022 Email: john.iacovelli@gmail.com URI: https://www.sipradius.com Ammirata, et al. Expires 27 May 2023 [Page 33]