Forward Secure Reauthentication in the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA')
draft-wang-emu-fs-reauth-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Guilin WANG , Zander Lei | ||
| Last updated | 2026-07-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-emu-fs-reauth-02
EAP Method Update G. Wang, Ed.
Internet-Draft Z. Lei
Intended status: Standards Track Huawei Int. Pte Ltd
Expires: 24 January 2027 23 July 2026
Forward Secure Reauthentication in the Extensible Authentication
Protocol Method for Authentication and Key Agreement (EAP-AKA')
draft-wang-emu-fs-reauth-02
Abstract
This draft specifies an update to RFC 9678, "Forward Secrecy
Extension to the Improved Extensible Authentication Protocol Method
for Authentication and Key Agreement (EAP-AKA' FS)". This update
enables forward security of the Transient EAP Keys (TEKs) for
protecting EAP packets, which are not in EAP-AKA' FS. Based on this
extension, the executions of reauthentication after a full
authentication will be unlinkable to each other and then the privacy
of end users is enhanced. This update is also applicableto the
successors of RFC 9678, with post-quantum key encapsulation
mechanisms (KEMs) or hybrid KEMs.
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 24 January 2027.
Copyright Notice
Copyright (c) 2026 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.
Wang & Lei Expires 24 January 2027 [Page 1]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
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. Revision History . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Linkable Reauthentication in EAP-AKA' FS . . . . . . . . . . 4
4.1. Review of EAP-AKA' FS . . . . . . . . . . . . . . . . . . 4
4.2. Linkable Reauthentication Identities . . . . . . . . . . 6
5. Forward Secure Reauthentication . . . . . . . . . . . . . . . 7
6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
7. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. Normative References . . . . . . . . . . . . . . . . . . . . 11
12. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Revision History
Changes made in version 02:
* Added protocol call flows and the corresponding description.
Changes made in version 01:
* Editorial issues.
2. Introduction
EAP-AKA (Extensible Authentication Protocol method for 3rd Generation
Authentication and Key Agreement) [RFC4187] is a secure
authentication method used for mobile devices connecting to networks
(like Wi-Fi) using their credentials from SIM/USIM cards. It enables
mutual authentication and key exchange between the mobile devices and
their mobile network operator. After that, communication data can be
securely transmitted between them by using various key materials
agreed in EAP-AKA.
EAP-AKA' (Improved Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement) [RFC5448], introduces a
new key derivation function, SHA-256, instead of SHA-1. This
Wang & Lei Expires 24 January 2027 [Page 2]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
function is also used to bind the keys derived within the method to
the name of the access network. This limits the effects of
compromised access network nodes and keys.
Moreover, "Improved Extensible Authentication Protocol Method for
3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')"
[RFC9048] specifies the protocol behavior for both 4G and 5G
deployments using EAP-AKA'. For example, how the Network Name field
is constructed in the protocol; how EAP-AKA' uses identifiers in 5G;
how to define session identifiers and other exported parameters
(including the case for fast reauthentication), and how to update the
requirements on generating pseudonym usernames and fast
reauthentication identities to ensure identity privacy.
"Forward Secrecy Extension to the Improved Extensible Authentication
Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)"
[RFC9678] enhances the forward security for the session keys
generated as a part of the authentication run in EAP-AKA', by
introducing ephemeral Diffie-Hellman key exchange. This prevents an
attacker who has gained access to the long-term key from compromising
session keys established in the past. However, as noted in
Section 7.6 of [RFC9678], K_encr, the key for encrypting
reauthentication pseudonym identities, is not forward secure, as it
is generated before ephemeral DH. Therefore, "an adversary
compromising the long-term key would be able to link reauthentication
protocol runs when pseudonyms are used, within a sequence of runs
followed after a full EAP-AKA' authentication. No such linking would
be possible across different full authentication runs. If the
pseudonym linkage risk is not acceptable, one way to avoid the
linkage is to always require full EAP-AKA' authentication."
However, as discussed in [RFC4187], reauthentication is much faster
and then benefits both mobile devices and the network operator.
Having full EAP AKA' authentication defeats the purpose of fast
reauthentication. This document specifies an update to enhance the
forward security for TEKs (including K_encr) in EAP-AKA' FS. Based
on this, it is not feasible to link the executions of
reauthentication within the session of a full authentication. When
this extension is enabled, the privacy of mobile device users is
protected against long-term key compromise. This update is
applicable and optional to [RFC9678].
This extension is also applicable and optional to the drafts
specified in [I-D.ietf-emu-pqc-eapaka] and
[I-D.ietf-emu-hybrid-pqc-eapaka], where the ephemeral DH key exchange
is replaced by post-quantum (PQ) KEM and hybrid KEMs [RFC9794],
respectively.
Wang & Lei Expires 24 January 2027 [Page 3]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
3. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers are assumed familiar with the terms in EAP-AKA [RFC4187],
EAP-AKA' [RFC5448] [RFC9048], and EAP-AKA' FS [RFC9678]. The
implication of forward security is discussed in Sections 1 and 4.3 of
[RFC9678], and the usage of reauthentication is discussed in
Section 5 of [RFC4187], and Sections 6.5.4 and 6.5.5 of [RFC9678].
4. Linkable Reauthentication in EAP-AKA' FS
4.1. Review of EAP-AKA' FS
The normal process of EAP-AKA' FS is briefly reviewed in Figure 1,
where AD denotes the 3GPP Authentication Database. Details can be
found in Section 5 of [RFC9678].
Wang & Lei Expires 24 January 2027 [Page 4]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
USIM Peer Server AD
| | | |
| | (1) EAP-Req/Identity | |
| |<----------------------------| |
| | (2) EAP-Resp/Identity | |
| | (Privacy-Friendly) | |
| |---------------------------->| |
| | |(3) ID, KDF,network name|
| | |----------------------->|
| | |(4) RAND, AUTN, XRES, |
| | | CK', IK' |
| | |<-----------------------|
| | (5) EAP-Req/AKA'-Challenge | |
| | AT_RAND, AT_AUTN, AT_KDF, | |
| | AT_KDF_FS, AT_KDF_INPUT, | |
| | AT_PUB_ECDHE, AT_MAC | |
| |<----------------------------| |
|(6) RAND, AUTN | | |
|<---------------| | |
|(7) CK, IK, RES | | |
|--------------->| | |
| |(8) EAP-Resp/AKA'-Challenge | |
| | AT_RES, AT_PUB_ECDHE, AT_MAC| |
| |---------------------------->| |
| | (9) EAP-Success | |
| |<----------------------------| |
Figure 1. EAP-AKA' FS Authentication Process (Section 5 of RFC 9678)
Key materials are derived in EAP-AKA' FS as shown in Figure 2
(Section 6.3 of [RFC9678]). Note that the TEKs, consisting of both
K_encr and K_aut, are part of MK (Master Key). However, MK itself is
derived from IK' and CK' without the ephemeral SHARED_SECRET,
obtained via running ephemeral DH key exchange. Therefore, both
K_encr and K_aut are not forward secure, as they just rely on the
security of the long-term key, shared by the peer's USIM and the
mobile network operator's AD. Note that IK' and CK' are derived from
this long-term key.
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)
K_encr = MK[0..127]
K_aut = MK[128..383]
K_re = MK_ECDHE[0..255]
MSK = MK_ECDHE[256..767]
EMSK = MK_ECDHE[768..1279]
Figure 2. Key Derivation in EAP-AKA' FS (Section 6.3 of RFC 9678)
Wang & Lei Expires 24 January 2027 [Page 5]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
In more detail, the ephemeral SHARED_SECRET is generated from
ephemeral DH values available in two AT_PUB_ECDHE attributes,
exchanged by the peer and server in Steps (5) and (8) in Figure 1.
However, K_encr and K_aut are generated by the server after Step (4)
and used in Step (5) to protect the info for the peer. And
similarly, they are generated after Step (7) by the peer and used to
verify and decrypt ciphertext sent in Step (5), and used in Step (8)
to protect the info for the server. So, the ephemeral SHARED_SECRET
is available later than when K_encr and K_aut are generated and used
by the server and the peer. So, in case the long-term key is
compromised, K_encr and K_aut will be compromised too.
4.2. Linkable Reauthentication Identities
Figure 3 is a brief review of the reauthentication procedure, which
is specified in Section 5.4 of [RFC4187]. Here all attributes with
'*' denote that they are encrypted using the encryption key K_encr,
and encapsulated in the AT_ENCR_DATA attribute. For offering the
peer a new reauthentication identity for the next run, the
authenticator generates a pseudonym and uses K_encr to encrypt it in
the optional attribute AT_NEXT_REAUTH_ID. At the same time, the
authenticator uses integrity key K_aut to produce a MAC in the
atttibute AT_MAC in Step (3).
Peer Authenticator
| |
| (1) EAP-Request/Identity |
|<----------------------------------------------------------|
| (2) EAP-Response/Identity |
| (Includes a fast reauthentication identity) |
|---------------------------------------------------------->|
| (3) EAP-Request/AKA-Reauthentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S, |
| *AT_NEXT_REAUTH_ID, AT_MAC) |
|<----------------------------------------------------------|
| (4) EAP-Response/AKA-Reauthentication |
|(AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, AT_MAC) |
|---------------------------------------------------------->|
| (5) EAP-Succes |
|<----------------------------------------------------------|
Figure 3. Reauthentication Procedure (Section 5.4 of RFC 4187)
Wang & Lei Expires 24 January 2027 [Page 6]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
As discussed above, K_encr and K_aut will be compromised if the long-
term key is leaked. So, in such case, the attacker with access to
the long-term key will be able to decrypt all reauthentication
identities delivered from the server to the peer. When these
identities are used for reauthentication, the attacker will be able
to link these runs of reauthentication, even those reauthentication
identities are pseudonyms generated by the server independently.
Moreover, even without decrypting the reauthentication identities
from the AT_NEXT_REAUTH_ID attributes, the attacker can also link two
or more runs of reauthentication by using the integrity key K_aut.
Namely, the attacker can check the AT_MAC attributes sent by either
the authenticator in Step (3) or the peer in Step (4) to be sure that
different runs belong to the same peer, if all these AT_MAC
attributes are valid with respect to the given K_aut.
Therefore, to guarantee the privacy of mobile users running
reauthentication with compromised long-term key, it is necessary to
enhance the forward security of the TEKs, i.e, K_encr and K_aut.
5. Forward Secure Reauthentication
To enable the forward security of K_encr and K_aut, this document
specifies a concrete key derivation process given in Figure 4.
(EDITOR'S NOTE: Other variants are also available.)
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)
K_encr = MK[0..127]
K_aut = MK[128..383]
K_encr' = MK_ECDHE[0..127]
K_aut' = MK_ECDHE[128..383]
K_re = MK_ECDHE[384..639]
MSK = MK_ECDHE[640..1060]
EMSK = MK_ECDHE[1061..1633]
Figure 4. The Proposed Key Derivation Process
In this process, K_encr and K_aut are updated after completing full
EAP-AKA' FS authentication in Figure 1 to forward secure K_encr' and
K_aut', which are derived from IK', CK' and SHARED_SECRET, the
ephemeral secret. And only K_encr' and K_aut' are used to protect
the transmission and usage of reauthenticaton identities in
reauthentication procedure in Figure 3.
The whole process will be elaborated later.
Wang & Lei Expires 24 January 2027 [Page 7]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
6. Protocol Overview
In the following, the protocol is overviewed to explain how to enable
the forward security of the Transient EAP Keys (TEKs), namely,
K_encr' and K_aut'. The protocol is integrated from the
reauthentication procedure reviewed in Section 4.2, the procedure of
EAP-AKA' FS reviewed in Section 4.1, and the description of message
processing for reauthentication given in Sections 6.5.5 and 6.5.6 of
[RFC9678].
For simplicity, only new attributes in Figure 5 are described here.
Other attributes are the same as in [RFC9678] (and reviewed in
Section 4.2). Note that * denotes an encrypted attribute. The
NEXT_REAUTH_ID in message (5) is the reauthentication ID, which is
newly generated by the server and encrypted by K_encr. At this
moment, the sever is not sure if the peer also supports this udpate
for enhancing the forward security of the TEKs. To check if the
peepr has this capability, the server sends out the attribute
AT_SUPPORT_TEKs_FS, which is a new attribute introduced in this
draft. Its format is defined in Section 7.
In message (9), if the peer does support the forward security of the
TEKs, it will reply the attribute AT_SUPPORT_TEKs_FS as well. On
successfully received this attribute and other attributes, the sever
will be able to update K_encr to K_encr', and K_aut to K_aut'. The
concrete key derivation is specifed in Section 5, where the ephemeral
shared secret key is an input for the key derivation. Note that
K_encr' and K_aut' are forward secure. Then, in message (10), the
sever will also send another new reauth-ID in the atrribute
AT_NEXT_REAUTH_ID, which is encrypted by K_encr'. If the peer
supports the update specified in this draft, it will obtain this new
reauth-ID for the coming fast reauthentication, as shown in Figure 6.
Wang & Lei Expires 24 January 2027 [Page 8]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
USIM Peer Server AD
| | | |
| | (1) EAP-Req/Identity | |
| |<----------------------------| |
| | (2) EAP-Resp/Identity | |
| | (Privacy-Friendly) | |
| |---------------------------->| |
| | |(3) ID, KDF,network name|
| | |----------------------->|
| | |(4) RAND, AUTN, XRES, |
| | | CK', IK' |
| | |<-----------------------|
| | (5) EAP-Req/AKA'-Challenge | |
| | AT_RAND, AT_AUTN, AT_KDF, | |
| | AT_KDF_FS, AT_KDF_INPUT, | |
| | AT_PUB_ECDHE, | |
| | *AT_NEXT_REAUTH_ID, | |
| | AT_SUPPORT_TEKs_FS, AT_MAC | |
| |<----------------------------| |
|(6) RAND, AUTN | | |
|<---------------| | |
|(7) CK, IK, RES | | |
|--------------->| | |
| |(8) EAP-Resp/AKA'-Challenge | |
| | AT_RES, AT_PUB_ECDHE, | |
| | AT_SUPPORT_TEKs_FS, AT_MAC | |
| |---------------------------->| |
| | (9) EAP-Success, | |
| | *AT_NEXT_REAUTH_ID | |
| |<----------------------------| |
Figure 5. EAP-AKA' FS Authentication Process with TEKs Foward Security
Figure 6 shows the procedure of reauthentication run by the peer and
server, without the involvement of USIM and AD. Note that the
attribute AT_NEXT_REAUTH_ID and AT_MAC in message (3) are still the
same as in the case without forward security (reviewed in
Section 4.2). However, those two attributes now are protected by
K_encr' and K_aut'. This applies to the attribute AT_MAC in message
(4) too, which is sent from the peer to the server.
Wang & Lei Expires 24 January 2027 [Page 9]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
Peer Server
| |
| (1) EAP-Request/Identity |
|<----------------------------------------------------------|
| (2) EAP-Response/Identity |
| (Include a reauth-ID) |
|---------------------------------------------------------->|
| (3) EAP-Request/AKA-Reauthentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S, |
| *AT_NEXT_REAUTH_ID, AT_MAC) |
|<----------------------------------------------------------|
| (4) EAP-Response/AKA-Reauthentication |
|(AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, AT_MAC) |
|---------------------------------------------------------->|
| (5) EAP-Succes |
|<----------------------------------------------------------|
Figure 6. EAP-AKA' FS Reauthentication Procedure
7. Attributes
The format of the AT_SUPPORT_TEKs_FS attribute is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_SUPPORT_ | Length = 1 | Reserved |
| TEKs_FS | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* AT_SUPPORT_TEKs_FS: This is set to TBA1 BY IANA.
* Length: fixed value of 1, which denotes that the length of this
attribute in one multiple of 4 octets, including the Type, Length,
and Reserved.
* Reserved: The value field of this attribute consists of two
reserved bytes, which are set to zero upon sending and ignored
upon reception.
8. Security Considerations
Security considerations will be added later.
Wang & Lei Expires 24 January 2027 [Page 10]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
9. IANA Considerations
One new Attribute Type value (TBA1) from the skippable range is
requested from IANA for AT_SUPPORT_TEKs_FS (Section 7), in the
"Attribute Types" registry under the "EAP-SIM/AKA/AKA'" group.
10. Acknowledgments
To be added later.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
January 2006, <https://www.rfc-editor.org/info/rfc4187>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009,
<https://www.rfc-editor.org/info/rfc5448>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9048] Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
"Improved Extensible Authentication Protocol Method for
3GPP Mobile Network Authentication and Key Agreement (EAP-
AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
<https://www.rfc-editor.org/info/rfc9048>.
[RFC9678] Arkko, J., Norrman, K., and J. Preuß Mattsson, "Forward
Secrecy Extension to the Improved Extensible
Authentication Protocol Method for Authentication and Key
Agreement (EAP-AKA' FS)", RFC 9678, DOI 10.17487/RFC9678,
March 2025, <https://www.rfc-editor.org/info/rfc9678>.
Wang & Lei Expires 24 January 2027 [Page 11]
Internet-Draft Forward Secure Reauthentication in EAP-A July 2026
[FIPS203] National Institute of Standards and Technology, "FIPS 203:
Module-Lattice-Based Key-Encapsulation Mechanism
Standard", Federal Information Processing Standards
Publication , August 2024,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.203.pdf>.
12. Informative References
[I-D.ietf-emu-hybrid-pqc-eapaka]
Banerjee, A. and T. Reddy.K, "Enhancing Security in EAP-
AKA' with Hybrid Post-Quantum Cryptography", Work in
Progress, Internet-Draft, draft-ietf-emu-hybrid-pqc-
eapaka-01, 26 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-
hybrid-pqc-eapaka-01>.
[I-D.ietf-emu-pqc-eapaka]
Reddy.K, T. and A. Banerjee, "Post-Quantum Key
Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime", Work
in Progress, Internet-Draft, draft-ietf-emu-pqc-eapaka-02,
17 March 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-emu-pqc-eapaka-02>.
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/info/rfc9794>.
Authors' Addresses
Guilin Wang (editor)
Huawei Int. Pte Ltd
9 North Buona Vista Drive, #13-01
The Metropolis Tower 1
SINGAPORE 138588
Singapore
Email: wang.guilin@huawei.com
Zhongding Lei
Huawei Int. Pte Ltd
9 North Buona Vista Drive, #13-01
The Metropolis Tower 1
SINGAPORE 138588
Singapore
Email: lei.zhongding@huawei.com
Wang & Lei Expires 24 January 2027 [Page 12]