CableLabs

t.wan@cablelabs.com

Security EMU EAP-AKA' EAP SUCI SUPI fragmentation post-quantum cryptography This document updates EAP-AKA’ (RFC 9048) by defining the use of the AT_FRAGMENT mechanism, as defined in I-D.ietf-emu-pqc-eapaka, for fragmentation of the AT_IDENTITY attribute. This update allows a peer to convey a large network access identifier, such as a Subscription Concealed Identifier (SUCI), during the EAP-AKA’ identity exchange when the encoded identity is too large to fit reliably in a single EAP packet. This is intended to support large SUCI values produced by post-quantum cryptographic concealment schemes, while preserving the existing EAP-AKA’ challenge and key derivation procedures.

EAP-AKA’ is an improved Extensible Authentication Protocol (EAP) method based on the Authentication and Key Agreement protocol. EAP-AKA’ supports the use of 5G identifiers, including the Subscription Concealed Identifier (SUCI), during identity exchange. In EAP-AKA’, the peer’s identity can be conveyed either in the initial EAP-Response/Identity packet or in the AT_IDENTITY attribute in an EAP-Response/AKA-Identity packet. Some SUCI concealment schemes may produce encoded identities that are larger than can be carried reliably in a single EAP packet. This can become more likely when post-quantum cryptographic (PQC) schemes are used for Subscription Permanent Identifier (SUPI) concealment. For example, a PQC-protected SUCI may require a few thousand octets when the scheme input and scheme output are encoded as part of the identity. EAP does not provide a generic fragmentation mechanism, and expects EAP methods that may carry large payloads to provide method-specific fragmentation. This document specifies how the generic AT_FRAGMENT mechanism defined in I-D.ietf-emu-pqc-eapaka can be used to fragment AT_IDENTITY during the EAP-AKA’ identity exchange. The mechanism defined here is intentionally scoped. It does not provide a general EAP-AKA’ fragmentation layer for all attributes or all EAP-AKA’ packets. It only fragments the identity value that would otherwise be carried in AT_IDENTITY. This avoids changes to the EAP-AKA’ challenge, response, AT_MAC validation, and key derivation procedures. This document does not alter the processing of AT_IDENTITY when identity fragmentation is not used. This document makes the following updates to RFC 9048: It defines the AT_FRAGMENT_SUPPORTED attribute, which allows an EAP-AKA’ server to indicate support for fragmented identity transport and to advertise the maximum supported fragment size and maximum reassembled attribute size. It permits an EAP-AKA’ peer to use the AT_FRAGMENT mechanism defined in I-D.ietf-emu-pqc-eapaka to transport an identity value that cannot be carried in a single AT_IDENTITY attribute. Except for the procedures described above, this document does not modify any other aspect of the EAP-AKA’ protocol specified in RFC 9048.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document uses the terminology of , , , and . The following additional terms are used: An identity value that is too large to fit reliably in a single EAP-Response/AKA-Identity packet as an AT_IDENTITY attribute. The identity value obtained after successful reassembly of all fragments belonging to the same AT_IDENTITY value.

Since EAP does not provide a generic fragmentation mechanism, a large identity value cannot be fragmented within the initial EAP-Response/Identity exchange. Therefore, a peer that needs to convey a large identity first responds with an anonymous identity in EAP-Response/Identity and then provides the large identity during the EAP-AKA’ identity exchange using the procedures defined in this document. After receiving an anonymous identity from a peer, the server requests the peer identity using EAP-Request/AKA-Identity packet containing AT_FRAGMENT_SUPPORTED. The attribute advertises support for fragmented identity transport and indicates the maximum supported fragment size and reassembled identity size. If the peer supports this extension and needs to send a large identity, the peer sends the identity as a sequence of EAP-Response/AKA-Identity packets. Each such response contains one or more AT_FRAGMENT attributes carrying fragmented portions of the AT_IDENTITY value. Fragment acknowledgement, retransmission, and sequencing follow the procedures defined for AT_FRAGMENT in I-D.ietf-emu-pqc-eapaka. This preserves the lock-step EAP request and response model. After receiving all AT_FRAGMENT payloads, the server reassembles the identity value and processes the reassembled value as if it had been received in a single AT_IDENTITY attribute. The server then continues with the normal EAP-AKA’ exchange. Figure 1 shows the message flow of fragmented identity transport for a large SUCI.

EAP-Request/AKA-Identity AT_ANY_ID_REQ AT_FRAGMENT_SUPPORTED <------------------------------------------------------ EAP-Response/AKA-Identity AT_FRAGMENT carrying first identity fragment ------------------------------------------------------> EAP-Request/AKA-Identity AT_FRAGMENT acknowledgement <------------------------------------------------------ EAP-Response/AKA-Identity AT_FRAGMENT carrying next identity fragment ------------------------------------------------------> EAP-Request/AKA-Identity AT_FRAGMENT acknowledgement <------------------------------------------------------ EAP-Response/AKA-Identity AT_FRAGMENT carrying final identity fragment ------------------------------------------------------> EAP-Request/AKA-Challenge AT_RAND, AT_AUTN, AT_KDF, ... AT_MAC <------------------------------------------------------ EAP-Response/AKA-Challenge AT_RES, AT_MAC ------------------------------------------------------> EAP-Success <------------------------------------------------------ ]]>

AT_FRAGMENT_SUPPORTED is sent by the server in an EAP-Request/AKA-Identity packet to indicate support for use of AT_FRAGMENT during identity exchange. The peer MUST NOT send AT_FRAGMENT carrying identity fragments unless the server has advertised AT_FRAGMENT_SUPPORTED in the same EAP-AKA’ identity exchange. The format of AT_FRAGMENT_SUPPORTED is:

TBD1. The length of this attribute in units of four octets. The total attribute length is 8 octets. The maximum number of payload octets that the server is willing to receive in a single AT_FRAGMENT attribute. A server SHOULD advertise a value that is smaller than the minimal EAP MTU of 1020 bytes. The maximum number of octets in a complete reassembled EAP-AKA’ attribute value that the server is willing to accept when AT_FRAGMENT is used. For this specification, the applicable reassembled attribute value is the AT_IDENTITY value. The server MAY configure this value based on the maximum identity size it is willing to accept. A server supporting large SUCI transport SHOULD support at least 3000 octets, as required by . Reserved for future use. The sender MUST set this field to zero. The receiver MUST ignore this field.

If the peer determines that the identity value cannot be carried in a single AT_IDENTITY attribute and the server has advertised AT_FRAGMENT_SUPPORTED, the peer fragments the identity using AT_FRAGMENT. The peer MUST NOT transmit AT_FRAGMENT carrying identity data unless AT_FRAGMENT_SUPPORTED has been received during the current EAP-AKA’ identity exchange. The peer MUST follow the AT_FRAGMENT procedures specified in I-D.ietf-emu-pqc-eapaka. The fragment payload size MUST NOT exceed the Max-Fragment-Size advertised by the server.

Upon receipt of AT_FRAGMENT carrying portions of an AT_IDENTITY value, the server performs validation and reassembly according to I-D.ietf-emu-pqc-eapaka. The server MUST verify that the reassembled attribute length does not exceed the advertised Max-Attribute-Length. If the reassembled attribute length exceeds Max-Attribute-Length, the server MUST fail the EAP-AKA’ exchange. After successful reassembly, the resulting octet sequence is processed as the value of AT_IDENTITY, and the server continues processing according to RFC 9048.

If a peer or server detects an error in the fragmentation exchange, it MUST fail the EAP-AKA’ exchange according to the error handling procedures of . A server SHOULD treat the following as fragmentation errors: receipt of AT_FRAGMENT without prior advertisement of AT_FRAGMENT_SUPPORTED; malformed AT_FRAGMENT attribute; reassembled identity length exceeds Max-Attribute-Length; reassembly timeout; identity syntax failure after reassembly. The server MAY send EAP-Failure after detecting a fragmentation error.

This extension is backward compatible with existing EAP-AKA’ peers and servers. A peer that does not implement this specification will ignore the AT_FRAGMENT_SUPPORTED attribute advertised by the server. A compliant peer MUST NOT use AT_FRAGMENT carrying identity fragments unless the server advertises AT_FRAGMENT_SUPPORTED. Therefore, a server that does not implement this specification will not receive AT_FRAGMENT from a compliant peer.

As in RFC 9048, AT_FRAGMENT payloads carrying identity information are exchanged before AT_MAC protection becomes available. This specification does not change that property. This specification does not change any other security properties of EAP-AKA’ . Fragmentation can increase denial-of-service risk because a server may need to allocate state before authentication completes. Servers MUST enforce limits on reassembled attribute length, fragment size, and reassembly lifetime.

This extension is intended to preserve the ability to use concealed identities when those identities become large. A peer that cannot send a large SUCI because fragmentation is unavailable may otherwise be forced to fail authentication or use a less private identity. This extension therefore improves privacy in deployments where concealed identities exceed practical single-packet limits. Fragment counts and packet sizes may reveal approximate identity length. This document does not attempt to hide the length of the concealed identity. An implementation MAY pad the identity before fragmentation if local policy requires length hiding, but such padding is outside the scope of this document.

IANA is requested to allocate one new Attribute Type value from the “EAP-AKA and EAP-SIM Parameters” registry: Value Attribute Name Reference TBD1 AT_FRAGMENT_SUPPORTED RFC-TBD

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK] This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card. EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community. This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community. The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA. This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks. EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA. This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'. This document updates both RFCs 4187 and 5448. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. 3GPP 3GPP

The author thanks the participants of 3GPP SA3 and IETF EMU working groups for discussions on supporting large SUCI values. The author also thanks the authors of I-D.ietf-emu-pqc-eapaka for defining the AT_FRAMENT mechanism that is reused in this document.