RFC 4016

RFC 4016: PANA Threat Analysis and Security Requirements 🎀

okay bestie, first the receipts 🧾✨ This is RFC 4016 from the Network Working Group, written by M. Parthasarathy at Nokia. It's Informational (so it's giving info, not a standard 💅) and it's dated March 2005. The title is Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements 🌈. The title block doesn't list anything it obsoletes or updates.

---

Status of This Memo 📜

this memo is giving info for the Internet community 🫶 it does not specify an Internet standard of any kind, and distribution of it is unlimited 🦋

Copyright Notice ©️

Copyright (C) The Internet Society (2005).

Abstract 🌸

this doc talks about the threats to protocols that carry authentication for network access 😭 the security requirements that come out of these threats are going to be used as extra input for the Protocol for Carrying Authentication for Network Access (PANA) Working Group, who are designing the IP based network access authentication protocol. iconic work 👑

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
3.  Terminology and Definitions. . . . . . . . . . . . . . . . . .  2
4.  Usage Scenarios. . . . . . . . . . . . . . . . . . . . . . . .  3
5.  Trust Relationships. . . . . . . . . . . . . . . . . . . . . .  4
6.  Threat Scenarios . . . . . . . . . . . . . . . . . . . . . . .  5
    6.1.  PAA Discovery. . . . . . . . . . . . . . . . . . . . . .  6
    6.2.  Authentication . . . . . . . . . . . . . . . . . . . . .  6
    6.3.  PaC Leaving the Network. . . . . . . . . . . . . . . . .  9
    6.4.  Service Theft. . . . . . . . . . . . . . . . . . . . . . 10
    6.5.  PAA-EP Communication . . . . . . . . . . . . . . . . . . 11
    6.6.  Miscellaneous Attacks. . . . . . . . . . . . . . . . . . 12
7.  Summary of Requirements. . . . . . . . . . . . . . . . . . . . 13
8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 13
9.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15

1. Introduction 🧚

the PANA Working Group is building ways to authenticate clients to the access network using IP based protocols 💖 this doc is all about the threats to those IP based protocols, so it's giving threat analysis era 🔥

okay so a client that wants network access has to go through multiple steps 🫠 first it has to discover the IP address of the PANA authentication agent (PAA), and then it runs an authentication protocol to prove who it is to the network. once the client is authenticated, there might be other messages going back and forth during the whole time it has access ✨ this doc looks at the threats in these steps, but it does not talk about any solutions 🙈 the requirements that come out of these threats are going to be input for the PANA Working Group. also, when this doc says co-located, it means the entities are on the same node 📍

2. Keywords 🔑

so 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 [KEYWORDS]. these caps words are load-bearing, bestie, don't sleep on them 💅

3. Terminology and Definitions 📚

Client Access Device A network element (e.g., notebook computer, PDA) that requires access to a provider's network. it's giving gadget that wants in 📱

Network Access Server (NAS) A network device that provides access to the network. the gatekeeper energy is real 🚪

PANA Client (PaC) An entity in the edge subnet that seeks to obtain network access from a PANA authentication agent within a network. A PANA client is associated with a device and a set of credentials to prove its identity within the scope of PANA. the PaC is the main character who's asking to get in 🌟

PANA Authentication Agent (PAA) An entity whose responsibility is to authenticate the PANA client and to grant network access service to the client's device. the PAA is the bouncer who checks the ID and says yes or no 🫶

Authentication Server (AS) An entity that authenticates the PANA client. It may be co-located with the PANA authentication agent or part of the back-end infrastructure. the AS is the behind-the-scenes queen who does the verifying 👑

Device Identifier (DI) The identifier used by the network to control and police the network access of a client. Depending on the access technology, the identifier might contain the IP address, link-layer address, switch port number, etc., of a device. The PANA authentication agent keeps a table for binding device identifiers to the PANA clients. At most one PANA client should be associated with a DI on a PANA authentication agent. this is the device's name tag, and the PAA keeps the guest list 📋

Enforcement Point (EP) A node capable of filtering packets sent by the PANA client by using the DI information authorized by PANA authentication agent. the EP is the one filtering the traffic, so it's giving security guard 🛡️

Compound methods Authentication protocol in which methods are used in a sequence one after another or in which methods are tunneled inside another independently established tunnel between the client and server [TUN-EAP]. this one's a layered look, like methods inside other methods 🧁

4. Usage Scenarios 🌍

PANA is meant to be used in an environment where there's no a priori trust relationship or security association between the PaC and other nodes, like the PAA and EP. in these environments, you might see the following:

• the link between the PaC and PAA may be a shared medium (e.g., Ethernet) or may not be a shared medium (e.g., DSL network) 🌐
• all the PaCs may be authenticated to the access network at layer 2 (e.g., 3GPP2 CDMA network) and share a security association with a layer 2 authentication agent (e.g., BTS). the PaCs still don't trust each other; any PaC can pretend to be a PAA, spoof IP addresses, and launch various other attacks 💀

the scenarios above change the threat model of PANA, so this doc goes through the threats in the context of these network access scenarios so we actually understand them 🧠 in the discussion, any link that is not shared (or non-shared) is assumed to be physically secure. if you can't make that assumption about the link, then the case is the same as a link being shared by more than one node 🙈

5. Trust Relationships 🤝

PANA authentication involves a client (PaC), a PANA agent (PAA), an Authentication server (AS), and an Enforcement point (EP). the AS here is the AAA server that lives in the PaC's home realm 🏠

these entities already have a priori trust relationships before PANA begins:

1. PAA and AS: The PaC belonging to the same administrative domain that the AS does often has to use resources provided by a PAA that belongs to another administrative domain. A PAA authenticates the PaC before providing local network access. The credentials provided by the PaC for authentication may or may not be understood by the PAA. If the PAA does not understand the credentials, it needs to communicate with the AS in a different domain to verify the credentials. The threats in the communication path between the PAA and AS are already covered in [RAD-EAP]. To counter these threats, the communication between the PAA and AS is secured by using a static or dynamic security association. so the PAA and AS have their own handshake 🤝
2. PAA and EP: The PAA and EP belong to the same administrative domain. Hence, the network operator can set up a security association to protect the traffic exchanged between them. This document discusses the threats in this path. the PAA and EP are basically besties from the same domain, and this doc still checks their path 👀
3. PaC and AS: The PaC and AS belong to the same administrative domain and share a trust relationship. When the PaC uses a different domain than its home for network access, it provides its credentials to the PAA in the visited network for authentication. The information provided by the PaC traverses the PaC-PAA and PAA-AS paths. The threats in the PAA-AS path are already discussed in [RAD-EAP]. This document discusses the threats in the PaC-PAA path. 🧳

it's possible that some of the entities, like the PAA, AS, and EP, are co-located. in those cases, it can be safely assumed that there are no significant external threats in their communication 🫶

these entities do not have any trust relationship before PANA begins:

1. PaC and PAA: The PaC and PAA normally belong to two different administrative domains. They do not necessarily share a trust relationship initially. They establish a security association in the process of authentication. All messages exchanged between the PaC and PAA are subject to various threats, which are discussed in this document. stranger danger energy, so they have to build trust first 🫣
2. PaC and EP: The EP belongs to the same administrative domain as the PAA. Hence, the PaC and EP do not necessarily share a trust relationship initially. When the PaC is successfully authenticated, it may result in key establishment between the PaC and PAA, which can be further used to secure the link between the PaC and EP. For example, the EAP keying framework, [EAP-KEY], defines a three party EAP exchange in which the clients derive the transient sessions keys to secure the link between the peer and NAS in their final step. Similarly, PANA will provide the ability to establish keys between the PaC and EP that can be used to secure the link further. This is discussed further in Section 6.4 below. the keys are the glow-up here 🔐✨

6. Threat Scenarios 💥

first the PaC needs to discover the PAA. This involves either sending solicitations or waiting for advertisements. Once it has discovered the PAA, the two will enter authentication exchange. Once the access is granted, the PaC will most likely exchange data with other nodes in the Internet. These steps are vulnerable to man-in-the-middle (MITM), denial of service (DoS), and service theft attacks, which are discussed below. this is where the drama starts 😭

the threats are grouped by the stages the client goes through to get network access, so it's easy to follow along 🗺️ Section 6.1 covers the threats related to PAA discovery. Section 6.2 covers the threats related to authentication itself. Section 6.3 covers the threats involved when leaving the network. Section 6.4 covers service theft. Section 6.5 covers the threats in the PAA-EP path. Section 6.6 covers the miscellaneous threats.

some of the threats in the following sections may be specific to shared links, and they may be absent on non-shared links. So it's only required to prevent the threat on shared links. Instead of making a separate set of requirements for shared and non-shared links, this doc sets out one set of requirements with this wording: "PANA MUST be able to prevent threat X". That means the PANA protocol should be capable of preventing threat X. The feature that prevents threat X may or may not be used depending on the deployment 🦋

6.1. PAA Discovery 🔍

okay so the PAA gets found in one of two ways: you send out solicitations, or you receive advertisements. and this is where things get spicy 🌶️

T6.1.1: a malicious node can pretend to be a PAA by sending a spoofed advertisement 🎭

in existing dial-up networks, clients authenticate to the network but generally do not verify the messages coming from the Network Access Server (NAS). ngl this mostly works, because the link between the device and the NAS isn't shared with anyone else (assuming nobody messes with the physical link 👀), and clients trust the NAS and the phone network to deliver the service. spoofing isn't really a thing in that world, since the PaC can just assume the other end of the link is the PAA 💅

but when the link is shared, this threat shows up. any node can pretend to be a PAA. even if the nodes are authenticated at layer 2, the threat is still there 😭 protecting discovery is hard, because there's no a priori trust relationship between the PAA and PaC. in deployments where EP can police the packets sent among the PaCs, it's possible to filter out the unauthorized PANA packets (like PAA advertisements sent by a PaC) and stop this threat 🧱

the advertisement can also carry info that isn't just "hi, I'm the PAA," like supported authentication methods. this opens the door to a bidding down attack 📉 a malicious node can send a spoofed advertisement claiming authentication methods that are weaker than what the real PAA supports. the PaC gets fooled into negotiating a weaker method than would've been available otherwise. not okay 🙅‍♀️

Requirement 1 PANA MUST not assume that the discovery process is protected.

---

6.2. Authentication 🔐

this section is all about the threats specific to the authentication protocol. Section 6.2.1 covers the threat around the success/failure indications sent to the PaC at the end of authentication. Section 6.2.2 covers the man-in-the-middle attack when compound methods are used. Section 6.2.3 covers replay attacks, and Section 6.2.4 covers the device identifier attack. let's get into it 🧚

6.2.1. Success or Failure Indications 🎉❌

some authentication protocols (like EAP) have a special message that says success or failure. an attacker can send a fake one to the PaC. a fake failure keeps the client from getting onto the network at all, and a fake success can cut the authentication exchange short, which also ends up denying service to the PaC 😤

if the link isn't shared, this threat is gone, because ingress filtering can stop the attacker from impersonating the PAA 🛡️

if the link is shared, these packets are really easy to spoof. if layer 2 provides per-packet encryption with pair-wise keys, it might make it hard for the attacker to guess which success or failure packet the client would accept. but even when the node is already authenticated at layer 2, it can still pretend to be a PAA and spoof the success or failure 💀

this attack works if the success or failure indication isn't protected by a security association between the PaC and the PAA. to avoid it, the PaC and PAA should mutually authenticate each other. during that process, they should be able to establish keys that protect the success or failure indications. it's not always possible to protect the indication, though, since the keys might not be set up before the success or failure packet has to go out. if the client is re-authenticating to the network, it can use the security association it already has to protect those indications. similarly, all PANA messages exchanged before key establishment might not be protected 🔑

Requirement 2 PANA MUST be able to mutually authenticate the PaC and PAA. PANA MUST be able to establish keys between the PaC and PAA to protect the PANA messages.

6.2.2. MITM Attack 🕵️‍♀️

a malicious node can claim to be the PAA to the real PaC and claim to be the PaC to the real PAA. that's a man-in-the-middle (MITM) attack: the PaC thinks it's talking to the real PAA, and the PAA thinks it's talking to the real PaC. classic chaos 🍿

if the link isn't shared, this threat is absent, because ingress filtering can stop the attacker from acting as a man-in-the-middle ✨

if the link is shared, this threat is present. even if layer 2 provides per-packet protection, the attacker can still be the man-in-the-middle and pull this off. an instance of this MITM attack, where compound authentication methods are used, is described in [TUN-EAP]. in these attacks, the server authenticates to the client first. since the client hasn't proven its identity yet, the server acts as the man-in-the-middle, tunneling the legitimate client's identity to get onto the network 😳 the attack works because nothing verifies that the same entities took part in the compound methods. you can't do that verification at all if the compound methods aren't cryptographically bound together. so PANA will be vulnerable to these attacks if compound methods are used without being able to cryptographically bind them. side note: the attack doesn't exist if the keys derived while the tunnel is set up aren't used to authenticate the client (for example, if tunnel keys are only used to protect the client's identity) 🫶

Requirement 3 When compound authentication methods are used in PANA, the methods MUST be cryptographically bound.

6.2.3. Replay Attack 🔁

a malicious node can replay messages that caused an authentication failure or success at a later time to create false failures or successes. the attacker can also replay other PANA protocol messages to deny service to the PaC 🙃

if the link isn't shared, this threat is absent, because ingress filtering can stop the attacker from impersonating the PAA to replay packets 🚫

if the link is shared, this threat is present. if the packets are encrypted at layer 2 with pair-wise keys, it'll be hard for the attacker to learn the unencrypted (original) packet they need to replay. but even if layer 2 provides replay protection, the attacker can still replay the PANA messages (at layer 3) to deny service to the client 😤

Requirement 4 PANA MUST be able to protect itself against replay attacks.

6.2.4. Device Identifier Attack 🪪

once the client is successfully authenticated, the PAA sends access control information to the EP so it can grant access to the network. that access control info usually includes the PaC's device identifier, which is either pulled from the IP and MAC headers of the packets exchanged during authentication, or carried explicitly in the PANA protocol field. here's how an attacker can sneak into the network 👀

• an attacker pretends to be a PAA and sends advertisements. the PaC gets fooled and starts exchanging packets with the attacker.
• the attacker changes the IP source address on the packet, fixes up the UDP/TCP checksum, and forwards it to the real PAA. it does the same thing on return packets too.
• once the real PaC is successfully authenticated, the attacker gets access to the network, because the packets carried the attacker's IP address (and potentially its MAC address too) 😈

if the link isn't shared, this threat is absent, because the attacker can't impersonate the PAA and intercept packets from the PaC 🙅‍♀️

if the link is shared, this threat is present. if layer 2 provides per-packet protection, the MAC address can't be changed, so this threat may be absent in those cases as long as EP filters on both the IP and MAC address 🧠

Requirement 5 PANA MUST be able to protect the device identifier against spoofing when it is exchanged between the PaC and PAA.

6.3. PaC Leaving the Network 👋

when the PaC leaves the network, it can tell the PAA before disconnecting, so the resources the PaC used can be accounted for properly. the PAA can also revoke access whenever it deems necessary. but here are the threats 😬

T6.3.1: a malicious node can pretend to be a PAA and revoke the PaC's access.

T6.3.2: a malicious node can pretend to be a real PaC and send a disconnect message.

T6.3.3: the PaC can leave the network without telling the PAA or EP (for example, the Ethernet cable gets unplugged, or the system crashes). an attacker can pretend to be the PaC and start using the network 🫠

if the link isn't shared, threats T6.3.1 and T6.3.2 are absent. threat T6.3.3 may still be present. if there's no layer 2 indication, or if the layer 2 indication can't be relied upon, then T6.3.3 is still present on non-shared links 🌸

if the link is shared, all of the above threats are present, because any node on the link can spoof the disconnect message. even if layer 2 has per-packet authentication, the attacker can pretend to be a PaC (for example, by spoofing the IP address) and disconnect from the network. similarly, any node can pretend to be a PAA and revoke the PaC's access. so T6.3.1 and T6.3.2 are possible even on links where layer 2 is secured. T6.3.3 can be prevented if layer 2 provides per-packet authentication. the attacker can't take over the PaC that left the network without knowing the keys that protect packets at layer 2 🔐

Requirement 6 PANA MUST be able to protect disconnect and revocation messages. PANA MUST NOT depend on the PaC sending a disconnect message.

6.4. Service Theft 🎭

okay so bestie, service theft is when an attacker sneaks into the network by stealing a service that belongs to someone else 😤. Once the real PaC gets successfully authenticated, the EP sets up filters to keep unauthorized people out. These filters look at something that rides along on every packet. For example, a filter could check the IP and MAC addresses together, and drop any packet where a certain IP address doesn't come with its matching MAC address 🔐. Here are the possible threats:

T6.4.1: An attacker can spoof both the IP and MAC addresses of an authorized client to gain unauthorized access. This is so easy for them, honestly, they just sniff the wire to grab the IP and MAC addresses. Then they're using the network with zero authorization, getting a totally free service 💀.

T6.4.2: The PaC can leave the network without telling the PAA or EP (like if the Ethernet cable gets unplugged, or the system crashes). An attacker can then pretend to be the PaC and start using the network 🙈.

Service theft also opens the door to exploiting weaknesses in other authentication protocols that use IP addresses for authentication. It also lets someone intercept traffic meant for other nodes by spoofing the IP address 🫣.

If the link is not shared, T6.4.1 is absent, since there's only one client on the link. Ingress filtering can stop the attacker from using the authorized IP and MAC addresses on a different link. T6.4.2 still exists, though, because the attacker can use the IP or MAC address of the real PaC to get into the network 🦋.

If the link is shared, both threats are present. If layer 2 provides per-packet protection using pair-wise keys, both threats can be prevented ✨.

Requirement 7

PANA MUST securely bind the authenticated session to the device identifier of the client, to prevent service theft. PANA MUST be able to bootstrap a shared secret between the PaC and PAA that can be further used to set up a security association between the PaC and EP to provide cryptographic protection against service theft 🔥.

6.5. PAA-EP Communication 📡

After a successful authentication, the PAA needs to tell the EP about the PaC's access control information so the PaC can get onto the network 🚪. This information would contain at least the device identifier of the PaC. If strong security is needed, the PAA will share a secret that only the PaC and PAA know, which is used to set up a security association between the PaC and EP 🔑. Here are the possible threats:

T6.5.1: An attacker can eavesdrop to learn the information communicated between the PAA and EP. They can then use that info to spoof the real PaC and also to set up a security association to get into the network 👀. This threat is absent if the attacker can't eavesdrop on the link. For example, the PAA and EP might talk on a link that's separate from the one visiting PaCs use 🧚.

T6.5.2: An attacker can pretend to be a PAA and send false information to an EP to get into the network. With stronger security, the attacker has to send their own device identifier and also a shared secret, so the EP will let them in 😤.

If the communication between the PAA and EP is protected, these threats are absent 💖.

Requirement 8

The communication between the PAA and EP MUST be protected against eavesdropping and spoofing attacks 🛡️.

6.6. Miscellaneous Attacks 🌪️

T6.6.1: There are various forms of DoS attacks that can hit the PAA or AS. A few are listed below. Since some DoS attacks are really hard to defend against, the protocol should be designed carefully to reduce or prevent them 🥲.

• An attacker can bombard the PAA with tons of authentication requests. If the PAA and AS aren't co-located, the PAA might have to set aside resources to store some state about the PaC locally before it hears back from the back-end AS. That can drain memory on the PAA 🧠.
• With minimal effort, an attacker can force the PAA or AS to do computationally intensive operations, which can drain the CPU resources of the PAA or AS 🔥.

T6.6.2: A PaC gets an IP address using stateful or stateless mechanisms before PANA authentication begins [PANAREQ]. When IP addresses get assigned before client authentication, it opens the door to DoS attacks. Unauthenticated malicious nodes can deplete the IP address space by grabbing multiple IP addresses, or they can block others from getting one by answering every duplicate address detection (DAD) query 🚫.

Depleting a /64 IPv6 link-local address space or a /8 RFC1918 private address space takes a brute-force attack. That kind of attack belongs to a DoS class that can just as easily target link capacity or CPU cycles on the target system by bombarding it with arbitrary packets. So fixing only the IP address depletion attack won't really improve security. A more general solution is needed to handle the whole class of brute-force attacks 💅.

The DAD attack can be prevented by using secure address resolution that doesn't depend on client authentication, such as [SEND]. The attack may also be prevented if the EP sits between the PaCs and monitors the ND/ARP activity to detect DAD attacks (excessive NA/ARP replies) 👑. If none of these solutions work for a deployment, the PaCs can send arbitrary packets to each other without going through the EP. That enables a class of attacks based on interfering with the PANA messaging (see T6.1.1). Since there will always be a threat in this class (like insecure discovery), addressing DAD won't improve the overall security by itself 🥀.

---

7. Summary of Requirements 📝

1. PANA MUST not assume that the discovery process is protected.
2. PANA MUST be able to mutually authenticate the PaC and PAA. PANA MUST be able to establish keys between the PaC and PAA to protect the PANA messages.
3. When compound authentication methods are used in PANA, the methods MUST be cryptographically bound.
4. PANA MUST be able to protect itself against replay attacks.
5. PANA MUST be able to protect the device identifier against spoofing when it is exchanged between the PaC and PAA.
6. PANA MUST be able to protect disconnect and revocation messages. PANA MUST NOT depend on whether the PaC sends a disconnect message.
7. PANA MUST securely bind the authenticated session to the device identifier of the client, to prevent service theft. PANA MUST be able to bootstrap a shared secret between the PaC and PAA that can be further used to set up a security association between the PaC and EP to provide cryptographic protection against service theft.
8. The communication between the PAA and EP MUST be protected against eavesdropping and spoofing attacks.

8. Security Considerations 🔒

This document discusses various threats to an IP based network access authentication protocol. It looks at threats for shared and unshared links separately, but in practice it can be hard to tell them apart. For example, a dial-up link may be a point-to-point IP tunnel 🫠. So the link should be assumed to be a shared link for most of the threats in this document. Seriously, don't skip this part 😭.

9. Normative References 📚

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

10. Informative References 🔍

• [PANAREQ] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology", Work in Progress, August 2004.
• [EAP-KEY] Aboba, B., et al., "EAP keying framework", Work in Progress.
• [RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
• [TUN-EAP] Puthenkulam, J., et al., "The compound authentication binding problem", Work in Progress.
• [SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

11. Acknowledgements 🫶

The author would like to thank the following people (in no specific order) for providing valuable comments: Alper Yegin, Basavaraj Patil, Pekka Nikander, Bernard Aboba, Francis Dupont, Michael Thomas, Yoshihiro Ohba, Gabriel Montenegro, Tschofenig Hannes, Bill Sommerfeld, N. Asokan, Pete McCan, Derek Atkins, and Thomas Narten 💜.

Author's Address 🖋️

Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA-94303

EMail: mohanp@sbcglobal.net

Full Copyright Statement ©️

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 🌸.

Intellectual Property 🦄

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 💖

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