EAP SHA256-SRP6a Authentication Protocol

Internet-Draft	EAP SHA256 SRP6a	November 2022
Ammirata, et al.	Expires 27 May 2023	[Page]

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 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.¶

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)¶

| 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:¶

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.¶

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 | | : +------------------+ | : | | : +------------------+ +------------------+ : | 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¶

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.¶

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¶

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¶

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¶

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¶

Set the fields in Figure 7 as follows:¶

Subtype (8 bits): the subtype field shall be set to one of the following values:¶

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¶

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.¶
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, 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¶

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.¶

Figure 10: EAP SRP-SHA256 Server Key Packet Format¶

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¶

The Client shall set the fields in Figure 11 as follows:¶

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¶

The Server shall set the fields in Figure 12 as follows:¶

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¶

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:
¶

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¶

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¶
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¶

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¶

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¶

+----+----------------------------+---+----------------------------+ | | 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.¶

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.¶

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.¶
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.¶
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": D66AAFE8E245F9AC245A199F62CE61AB8FA90A4D80C71CD2ADFD0B9DA163B29F2A34AFBDB3B1B5D0102559CE63D8B6E86B0AA59C14E79D4AA62D1748E4249DF3¶
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¶
Verifier "v": 557EA208F87A23C28936423EC16ABE6BD959933DFBEFC0B36EBD9335DE3997C97DDFA081D64CFBC6EFBFD5BE19F2ED9F77922FD7E88BBA6C6B310A9018EC4305¶

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": 92C4CEFB95A1AE2E576A252B19273FD4613F44FDA4AC8CC84A089D5740756223943882BAD34CB55F35139CDDB60E0D19ACD2B884CFB27F53C8EA969269ABE014¶

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)¶
B = (kv + g^b) % N¶

In this example, the Server key "B" is computed as follows:¶

Value "k": 890D0AC9E42A7F909D3CAA9A0FF115C52A1DC8DED10839EF9583C4E35EA76E78¶
Server key "B: 85CAE0C578E6927B78BEB173FB0F9BFC8ECB4C13542BB8BE3B0F3447B3764A234177E22D180DCAD21F33302248B7452916DC58ABD309C8A77440A228B8516A4E¶

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": 11426AB55E6550013743D08EB70D82F91404AA90CF0C63D8C1687414C2F8DC9240795EEE40BAC37C5F29B07BBAEB2C0D6CF59CFADCBACD4D93F948FB62A0C96D¶
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.¶

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¶