Internet DRAFT - draft-eap-sha256-srp6a
draft-eap-sha256-srp6a
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,
<https://www.rfc-editor.org/info/rfc2784>.
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, <https://www.rfc-editor.org/info/rfc8086>.
8.2. Informative References
[Video_Services_Forum]
Video Services Forum, "Video Services Forum (VSF)
Technical Recommendation TR-06-2:2022", 2022,
<https://vsf.tv/download/technical_recommendations/VSF_TR-
06-2_2022-08-11.pdf>.
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]
