RFC 3310

💖 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) ✨

okay bestie, here's the header info first 🎀

• Series: Network Working Group
• RFC number: 3310
• Authors: A. Niemi (Nokia), J. Arkko (Ericsson), V. Torvinen (Ericsson) 💅
• Category: Informational 🧚
• Date: September 2002 🌸
• Obsoletes / Updates: none listed in the header, so it doesn't replace or change any other RFC 🦋

---

Abstract

so this memo is all about an AKA-based one-time password generator for HTTP Digest access authentication 🔐 HTTP's auth framework has two schemes, Basic and Digest, and both use a shared secret for access auth. AKA is the thing that does user authentication and session key distribution in UMTS networks. It's challenge-response and uses symmetric cryptography, which is honestly a whole vibe 💜

Table of Contents

   1.  Introduction and Motivation  . . . . . . . . . . . . . . . . .  2
   1.1 Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  AKA Mechanism Overview . . . . . . . . . . . . . . . . . . . .  4
   3.  Specification of Digest AKA  . . . . . . . . . . . . . . . . .  5
   3.1 Algorithm Directive  . . . . . . . . . . . . . . . . . . . . .  5
   3.2 Creating a Challenge . . . . . . . . . . . . . . . . . . . . .  6
   3.3 Client Authentication  . . . . . . . . . . . . . . . . . . . .  7
   3.4 Synchronization Failure  . . . . . . . . . . . . . . . . . . .  7
   3.5 Server Authentication  . . . . . . . . . . . . . . . . . . . .  8
   4.  Example Digest AKA Operation . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   5.1 Authentication of Clients using Digest AKA . . . . . . . . . . 13
   5.2 Limited Use of Nonce Values  . . . . . . . . . . . . . . . . . 13
   5.3 Multiple Authentication Schemes and Algorithms . . . . . . . . 14
   5.4 Online Dictionary Attacks  . . . . . . . . . . . . . . . . . . 14
   5.5 Session Protection . . . . . . . . . . . . . . . . . . . . . . 14
   5.6 Replay Protection  . . . . . . . . . . . . . . . . . . . . . . 15
   5.7 Improvements to AKA Security . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   6.1 Registration Template  . . . . . . . . . . . . . . . . . . . . 16
       Normative References . . . . . . . . . . . . . . . . . . . . . 16
       Informative References . . . . . . . . . . . . . . . . . . . . 16
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18

---

Status of this Memo

this memo is for information only, so the Internet community can read it 📚 it is not an Internet standard of any kind, and distribution is unlimited 🌈

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved. 🎀

1. Introduction and Motivation ✨

okay so HTTP's Authentication Framework (see RFC 2617 [2]) has Basic and Digest. Both use a shared secret for access auth 🔑 Basic is inherently insecure because it sends user credentials in plain text, which is literally the worst. Digest is way better: it hides credentials with cryptographic hashes, and it also gives you limited message integrity 💅

AKA [6] does authentication and session key distribution in UMTS networks 📱 It's challenge-response and uses symmetric cryptography. It usually runs in a UMTS IM Services Identity Module (ISIM), which lives on a smart-card-like device that also gives you tamper resistant storage for shared secrets 🔐

so this document maps AKA parameters onto HTTP Digest authentication. Basically, that mapping lets you use AKA as a one-time password generator for Digest auth 🦋

And the SIP [3] Authentication Framework follows the HTTP one really closely, so Digest AKA applies directly to SIP too, plus any other embodiment of HTTP Digest 🧚

1.1 Terminology

this chapter explains the terms used in this document 📖

AKA Authentication and Key Agreement.

AuC Authentication Center. The network element in mobile networks that can authorize users in either GSM or UMTS networks. 🛰️

AUTN Authentication Token. A 128 bit value generated by the AuC. Together with the RAND parameter, it authenticates the server to the client. 🔐

AUTS Authentication Token. A 112 bit value that the client generates when it hits an SQN synchronization failure. 😭

CK Cipher Key. An AKA session key used for encryption. 🎀

IK Integrity Key. An AKA session key used for integrity checks. 💜

ISIM IP Multimedia Services Identity Module. 🌸

PIN Personal Identification Number. The passcodes commonly assigned for automatic cash machines, smart cards, and similar things. 🍓

RAND Random Challenge. Generated by the AuC using the SQN. 🎲

RES Authentication Response. Generated by the ISIM. 🧚

SIM Subscriber Identity Module. The GSM counterpart to the ISIM. 📱

SQN Sequence Number. Both the AuC and the ISIM keep track of the SQN value. 🔢

UMTS Universal Mobile Telecommunications System. 🌍

XRES Expected Authentication Response. In a successful authentication, this is equal to RES. ✨

1.2 Conventions

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1]. 👑

2. AKA Mechanism Overview 🔥

this chapter walks through the AKA operation step by step, so grab a snack 🍓

1. Bestie, first a shared secret K gets set up ahead of time between the ISIM and the Authentication Center (AuC). The secret is stored in the ISIM, which lives on a smart-card-like, tamper resistant device 🔐
2. The AuC of the home network makes an authentication vector AV, using the shared secret K and a sequence number SQN. The vector has a random challenge RAND, a network authentication token AUTN, an expected authentication result XRES, an integrity key IK, and an encryption key CK. Iconic 💜
3. The authentication vector gets downloaded to a server. Optionally, the server can also download a batch of AVs, which means more than one authentication vector 📦
4. The server builds an authentication request that contains the random challenge RAND and the network authenticator token AUTN. 🧚
5. The authentication request gets delivered to the client 🚚
6. Using the shared secret K and the sequence number SQN, the client checks the AUTN with the ISIM. If the check works, the network has been authenticated. Then the client makes an authentication response RES, using the shared secret K and the random challenge RAND. 🫶
7. The authentication response, RES, gets delivered to the server 💌
8. The server compares the authentication response RES with the expected response XRES. If they match, the user has been successfully authenticated, and the session keys IK and CK can be used to protect further communication between the client and the server. Main character energy 👑

okay so when the client checks the AUTN, it might notice that the sequence numbers between the client and the server have fallen out of sync 😬 In that case, the client makes a synchronization parameter AUTS, using the shared secret K and the client's sequence number SQN. The AUTS parameter gets delivered to the network in the authentication response, and then the authentication can be tried again with authentication vectors generated from the synchronized sequence number 🔄

for the full AKA spec, and how the AUTN, RES, IK, CK, and AUTS get generated, see reference 3GPP TS 33.102 [6]. 📚

3. Specification of Digest AKA 💅

in general, the Digest AKA operation is identical to the Digest operation in RFC 2617 [2]. This chapter only covers the parts where Digest AKA extends the Digest operation. The notation used in the Augmented BNF definitions for the new and modified syntax elements here is the same as in SIP [3]. Anything not defined in this section is defined in SIP and the documents it refers to 🦋

3.1 Algorithm Directive

so to get the client to use AKA for authentication instead of the standard password system, the algorithm directive from RFC 2617 gets overloaded in Digest AKA 🎀

        algorithm           =  "algorithm" EQUAL ( aka-namespace
                               / algorithm-value )
        aka-namespace       =  aka-version "-" algorithm-value
        aka-version         =  "AKAv" 1*DIGIT
        algorithm-value     =  ( "MD5" / "MD5-sess" / token )

algorithm A string that says which algorithm was used to produce the digest and the checksum. If the directive isn't understood, the nonce SHOULD be ignored, and another challenge (if one is present) should be used instead. The default aka-version is "AKAv1". 🧩

Further AKA versions can be specified, with version numbers assigned by IANA [7]. When the algorithm directive isn't present, it's assumed to be "MD5". This means AKA is not used to produce the Digest password. 🙈

Example, bestie:

algorithm=AKAv1-MD5

okay, here's the important bit ⚠️ If the entropy of the RES value is limited (for example, only 32 bits), reusing the same RES value to authenticate later requests and responses is NOT RECOMMENDED. A RES value like that SHOULD only be used as a one-time password. And algorithms like "MD5-sess", which limit how much material gets hashed with a single key by producing a session key for authentication, SHOULD NOT be used. Not me reading this and going "absolutely not" 💀🔥

3.2. Creating a Challenge 🦋

Okay bestie, so to deliver the AKA authentication challenge to the client in Digest AKA, we extend the nonce directive that RFC 2617 already defines. It's giving glow-up energy 💖

        nonce               =  "nonce" EQUAL ( aka-nonce
                               / nonce-value )
        aka-nonce           =  LDQUOT aka-nonce-value RDQUOT
        aka-nonce-value     =  <base64 encoding of RAND, AUTN, and
                                server specific data>

nonce ✨ is the parameter that gets filled with the Base64 [4] encoding of the concatenation of the AKA authentication challenge RAND, the AKA AUTN token, and optionally some server specific data, as shown in Figure 1. Here's an example:

nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK="

Here's the layout of Figure 1 🌈

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                            RAND                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                            AUTN                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Server Data...
   +-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Generating the nonce value.

Now the important bit 👑 If the server receives a client authentication containing the auts parameter defined in Section 3.4, and that includes a valid AKA AUTS parameter, the server MUST use it to generate a new challenge to the client. Also, when the AUTS is present, the included response parameter is calculated using an empty password (password of ""), instead of a RES. Not me being all about the details 🙈

---

3.3. Client Authentication 💅

When a client receives a Digest AKA authentication challenge, it pulls the RAND and AUTN out of the nonce parameter and checks out the AUTN token the server sent over. If the client successfully authenticates the server with the AUTN, and decides that the SQN used to generate the challenge is within the expected range, then the AKA algorithms run with the RAND challenge and the shared secret K. Iconic behavior 🔥

The resulting AKA RES parameter is treated as a "password" when calculating the response directive of RFC 2617. ✨

3.4. Synchronization Failure 💀

So when things go sideways with the AKA sequence number, we need a way to say "hey, my SQN is out of sync" 😭 To indicate an AKA sequence number synchronization failure, and to re-synchronize the SQN in the AuC using the AUTS token, a new directive is defined for the digest-response of the Authorization request header from RFC 2617:

        auts                =  "auts" EQUAL auts-param
        auts-param          =  LDQUOT auts-value RDQUOT
        auts-value          =  <base64 encoding of AUTS>

auts 🧚 is a string carrying a base64 encoded AKA AUTS parameter. This directive is used to re-synchronize the server side SQN. If the directive is present, the client doesn't use any password when calculating its credentials. Instead, the client MUST calculate its credentials using an empty password (password of ""). Example:

auts="CjkyMzRfOiwg5CfkJ2UK="

Once the server gets the auts parameter, it checks whether the value is valid using the shared secret K. A valid AUTS parameter is used to re-synchronize the SQN in the AuC. The synchronized SQN is then used to generate a fresh authentication vector AV, and that's how the client gets re-challenged 🌸

3.5. Server Authentication 🫶

Even though AKA gives you inherent mutual authentication with the AKA AUTN token, the mutual authentication mechanisms in Digest can still be useful for message integrity. Lowkey a double layer of protection 🔒

In Digest AKA, the server uses the AKA XRES parameter as the "password" when calculating the response-auth of the Authentication-Info header defined in RFC 2617. Periodt 💜

4. Example Digest AKA Operation ✨

okay so Figure 2 shows the whole Digest AKA flow for authenticating a SIP request, and the request in question is a SIP REGISTER 📱✨

Client Server

+------------------------------------+ |

+------------------------------------+ |

Figure 2: Message flow representing a successful authentication.

Here's the play-by-play 💅

1) Initial request

REGISTER sip:home.mobile.biz SIP/2.0

2) Response containing a challenge

SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
        realm="RoamingUsers@mobile.biz",
        nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==",
        qop="auth,auth-int",
        opaque="5ccc069c403ebaf9f0171e9517f40e41",
        algorithm=AKAv1-MD5

3) Request containing credentials

REGISTER sip:home.mobile.biz SIP/2.0
Authorization: Digest
        username="jon.dough@mobile.biz",
        realm="RoamingUsers@mobile.biz",
        nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==",
        uri="sip:home.mobile.biz",
        qop=auth-int,
        nc=00000001,
        cnonce="0a4f113b",
        response="6629fae49393a05397450978507c4ef1",
        opaque="5ccc069c403ebaf9f0171e9517f40e41"

4) Successful response

SIP/2.0 200 OK
Authentication-Info:
        qop=auth-int,
        rspauth="6629fae49393a05397450978507c4ef1",
        cnonce="0a4f113b",
        nc=00000001

Next up, Figure 3 shows a Digest AKA authentication that hits a synchronization failure 🙈

Client Server

+------------------------------------+ |

+------------------------------------+ |

Figure 3: Message flow representing an authentication synchronization failure.

And the messages for that one:

1) Initial request

REGISTER sip:home.mobile.biz SIP/2.0

2) Response containing a challenge

SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
      realm="RoamingUsers@mobile.biz",
      qop="auth",
      nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==",
      opaque="5ccc069c403ebaf9f0171e9517f40e41",
      algorithm=AKAv1-MD5

3) Request containing credentials

REGISTER sip:home.mobile.biz SIP/2.0
Authorization: Digest
      username="jon.dough@mobile.biz",
      realm="RoamingUsers@mobile.biz",
      nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==",
      uri="sip:home.mobile.biz",
      qop=auth,
      nc=00000001,
      cnonce="0a4f113b",
      response="4429ffe49393c02397450934607c4ef1",
      opaque="5ccc069c403ebaf9f0171e9517f40e41",
      auts="5PYxMuX2NOT2NeQ="

4) Response containing a new challenge

SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
      realm="RoamingUsers@mobile.biz",
      qop="auth,auth-int",
      nonce="9uQzNPbk9jM05Pbl5Pbl5DIz9uTl9uTl9jM0NTHk9uXk==",
      opaque="dcd98b7102dd2f0e8b11d0f600bfb0c093",
      algorithm=AKAv1-MD5

---

5. Security Considerations 🔐

Real talk, bestie: Digest AKA is vulnerable to the same security threats as HTTP authentication [2]. This section covers the relevant exceptions, and they matter 😭

5.1 Authentication of Clients using Digest AKA

AKA is typically (though this isn't a theoretical limitation) run on an ISIM application that usually lives in a tamper resistant smart card 💳. There are interfaces to the ISIM that let the host device ask for authentication to be performed on the card. However, these interfaces don't give access to the long-term secret outside the ISIM, and the authentication can only happen if the device accessing the ISIM knows a PIN code shared between the user and the ISIM. PIN codes usually come from user input and are typically needed when the device is powered on.

The tamper resistant card and secure interfaces mean Digest AKA is typically more secure than regular Digest implementations 🛡️✨. Neither owning the host device nor Trojan Horses in the software gets you the long-term secret. When a PIN scheme is used, the user is also authenticated when the device powers on. Still, the resulting security can differ from traditional Digest implementations, depending on whether those implementations cache or store passwords received from the user.

5.2 Limited Use of Nonce Values

The Digest scheme uses server-specified nonce values to seed the generation of the request-digest value. The server can construct the nonce so that it's only usable from a particular client, for a particular resource, for a limited period of time or number of uses, or with any other restrictions. Doing that strengthens the protection against things like replay attacks 🔁.

Digest AKA limits a nonce value's applicability to a particular ISIM. The ISIM is usually accessible to only one client device at a time. The nonce values are still strong and secure even though they're limited to one ISIM. This also means the server needs the client identity before it can generate an authentication challenge. If a client identity isn't available, an extra round trip is needed to get it, and that case is analogous to an AKA synchronization failure.

A server may let each nonce value be used only once by sending a next-nonce directive in the Authentication-Info header field of every response. Heads up though: this may cause a synchronization failure, and as a result some extra round trips in AKA, if the same SQN space is also used for other access schemes at the same time 🙃.

5.3 Multiple Authentication Schemes and Algorithms

In HTTP authentication, a user agent MUST choose the strongest authentication scheme it understands and request credentials from the user, based upon that challenge. Strongest-only, no settling 💪.

In general, using passwords generated by Digest AKA with other HTTP authentication schemes is not recommended, even though the realm values or protection domains would coincide. In these cases, a password should be requested from the end-user instead. Digest AKA passwords MUST NOT be re-used with such HTTP authentication schemes, because those send the password in clear. In particular, AKA passwords MUST NOT be re-used with HTTP Basic 🚫.

The same principle must be applied within a scheme if several algorithms are supported. A client receiving an HTTP Digest challenge with several available algorithms MUST choose the strongest algorithm it understands. For example, Digest with "AKAv1-MD5" would be stronger than Digest with "MD5" 💖.

5.4 Online Dictionary Attacks 🔐

Okay so, user-picked passwords are usually pretty simple 😬, which is why people have suggested that servers should not accept HTTP Digest passwords that are in the dictionary [2]. This threat doesn't exist for HTTP Digest AKA 💖, because the algorithm uses ISIM originated passwords 🎀. BUT the end-user still has to be careful with PIN codes 🙈. Even though HTTP Digest AKA password requests are never displayed to the end-user, she still gets authenticated to the ISIM via a PIN code. Commonly known initial PIN codes are usually installed on the ISIM during manufacturing, so if end-users don't change them, an unauthorized user may be able to use the device 💀. That only works if the unauthorized user has access to the physical device AND the end-user never changed the initial PIN code. So end-users are strongly encouraged to change their PIN codes when they receive an ISIM 🫶✨.

5.5 Session Protection 🛡️

Digest AKA can generate extra session keys for integrity (IK) and confidentiality (CK) protection 🔑. This document doesn't specify how to use these extra keys, but they may be used for creating additional security within HTTP authentication or some other security mechanism 🌸.

5.6 Replay Protection ⏪

AKA lets sequence numbers be tracked for each authentication, using the SQN parameter 🔢. This means authentications can be replay protected even if the RAND parameter happened to be the same for two authentication requests 💅. Even more important, it adds protection for the case where an attacker replays an old authentication request sent by the network. The client will be able to detect that the request is old and refuse authentication 🙅‍♀️. This proves liveliness of the authentication request, even when a MitM attacker tries to trick the client into giving an authentication response and then swaps parts of the message for something else 😭. In other words, a client challenged by Digest AKA is not vulnerable to chosen plain text attacks 👑. Finally, frequent sequence number errors would reveal an attack where the tamper resistant card has been cloned and is being used in multiple devices 🚨.

The catch: sequence number tracking means servers have to hold more information for each user than just their long-term secret, namely the current SQN value 📝. The good news is this information is typically not stored in the SIP nodes, but in dedicated authentication servers instead 🧚.

5.7 Improvements to AKA Security 📈

AKA is seen as a secure mechanism, and yet Digest AKA can still improve it 🦋. More specifically, the AKA parameters carried between the client and the server during authentication may be protected along with other parts of the message when you use Digest AKA. This is not possible with plain AKA 🙌.

---

6. IANA Considerations 📋

This document specifies an aka-version namespace in Section 3.1, which requires a central coordinating body. That body is the Internet Assigned Numbers Authority (IANA) 🌈.

The default aka-version defined in this document is "AKAv1". Following the policies outlined in [5], versions above 1 are allocated as Expert Review 🧐.

Registrations with the IANA MUST include the version number being registered, including the "AKAv" prefix. For example, a registration for "AKAv2" would potentially be valid, whereas a registration for "FOOv2" or "2" would not be valid 🚫. Further, the registration MUST include contact information for the party responsible for the registration 📇.

As this document defines the default aka-version, the initial IANA registration for aka-version values will contain an entry for "AKAv1" 💜.

6.1 Registration Template 📝

To: ietf-digest-aka@iana.org
Subject: Registration of a new AKA version

Version identifier:

    (Must contain a valid aka-version value,
     as described in section 3.1.)

Person & email address to contact for further information:

    (Must contain contact information for the
     person(s) responsible for the registration.)

---

Normative References 📚

[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[2]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
     Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
     Basic and Digest Access Authentication", RFC 2617, June 1999.

[3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
     Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
     Session Initiation Protocol", RFC 3261, June 2002.

[4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part One: Format of Internet Message Bodies",
     RFC 2045, November 1996.

Informative References 🔎

[5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
     Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[6]  3rd Generation Partnership Project, "Security Architecture
     (Release 4)", TS 33.102, December 2001.

[7]  http://www.iana.org, "Assigned Numbers".

Appendix A. Acknowledgements 🙏

The authors would like to thank Sanjoy Sen, Jonathan Rosenberg, Pete McCann, Tao Haukka, Ilkka Uusitalo, Henry Haverinen, John Loughney, Allison Mankin and Greg Rose 💖.

Authors' Addresses 💌

Aki Niemi
Nokia
P.O. Box 301
NOKIA GROUP, FIN  00045
Finland

Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com


Jari Arkko
Ericsson
Hirsalantie 1
Jorvas, FIN  02420
Finland

Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com


Vesa Torvinen
Ericsson
Joukahaisenkatu 1
Turku, FIN  20520
Finland

Phone: +358 40 7230822
EMail: vesa.torvinen@ericsson.fi

Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2002). All Rights Reserved.

Bestie, here's the legal vibe 🫶. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The one exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's needed to translate it into languages other than English 🌍.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️.

This document and the information contained herein is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💅.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 💜✨.