RFC 5027
Security Preconditions for Session Description Protocol (SDP) Media Streams
RFC 5027 📜✨
Security Preconditions for Session Description Protocol (SDP) Media Streams 🎀
Who wrote it: F. Andreasen and D. Wing, both from Cisco Systems 💅
When: October 2007 🦋
Category: Standards Track, so this is an official Internet standards-track protocol doc 🔥
Updates: RFC 3312 🌸. It doesn't obsolete anything.
Status of This Memo
okay so this part is the official "here's what this doc is" bit 💅. It's an Internet standards track protocol for the Internet community, and it asks everyone to talk about it and send in suggestions for making it better 🫶. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. And the good news is that distribution of this memo is unlimited 🌈.
Abstract
so basically this doc adds a brand-new security precondition to the SDP precondition framework from RFC 3312 and RFC 4032 ✨. What does a security precondition do? It can hold off session establishment or modification until security for a secure media stream has been negotiated successfully 🔒. Iconic behaviour, honestly 👑.
Table of Contents
1. Introduction ....................................................2
2. Notational Conventions ..........................................2
3. Security Precondition Definition ................................2
4. Examples ........................................................6
4.1. SDP Security Descriptions Example ..........................6
4.2. Key Management Extension for SDP Example ...................9
5. Security Considerations ........................................11
6. IANA Considerations ............................................13
7. Acknowledgements ...............................................13
8. Normative References ...........................................13
9. Informative References .........................................141. Introduction ✨
okay so the concept of an SDP precondition [RFC4566] is defined in [RFC3312] as updated by [RFC4032] 💖. A precondition is a condition that has to be satisfied for a given media stream before session establishment or modification can move forward 🧚. Think of it like a bouncer 💅: when a (mandatory) precondition isn't met, the session progress is delayed until the precondition is satisfied, or the session establishment just fails 💀. For example, RFC 3312 defines the Quality-of-Service precondition, which makes sure network resources are available before a call starts alerting 📞.
Now, media streams can either go in cleartext with no integrity protection, or they can get some kind of media security applied, like confidentiality and/or message integrity 🔐. The Audio/Video profile of the Real-Time Transfer Protocol (RTP) [RFC3551] is normally used with no security services at all, whereas the Secure Real-time Transport Protocol (SRTP) [SRTP] is always used with security services 🎀. When media stream security is being negotiated (like with the mechanism in SDP Security Descriptions [SDESC]), both the offerer and the answerer [RFC3264] need to know the cryptographic parameters for the media stream 🙈. The offerer might offer multiple choices for those parameters, or the answerer might pick parameters that are different from the offerer's (like using a different key in one direction than the other) 🔑. So to avoid media clipping, the offerer needs to receive the answer before it receives any media packets from the answerer ⏳. That's where a security precondition comes in 🦸♀️: it makes sure the media stream security parameters are successfully negotiated for a secure media stream before session establishment or modification happens 🫶.
2. Notational 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 [RFC2119] 📖✨.
3. Security Precondition Definition ✨
okay so the big idea here is that a security precondition is basically a "wait, are the crypto keys actually sorted yet?" check 🔐💅. The relevant cryptographic parameters (cipher, key, etc.) for a secure media stream need to be known to have been negotiated in the direction(s) required. If the precondition is used with a non-secure media stream, it's automatically satisfied, because there's nothing to be sorted 🌸. A secure media stream here just means a stream that uses some kind of security service (message integrity, confidentiality, or both), no matter how strong the mechanisms are 🦋.
As an extreme example of this, Secure RTP (SRTP) using the NULL encryption algorithm and no message integrity would be considered a secure media stream whereas use of plain RTP would not. Note though, that Section 9.5 of [SRTP] discourages the use of SRTP without message integrity. 🙈
Security preconditions do not guarantee that an established media stream will be secure 😭. They only guarantee that the recipient of the media stream packets will be able to do any relevant decryption and integrity checking on those packets. For more security considerations, see Section 5 🫶.
The security precondition type is defined by the string sec, so we modify the grammar found in RFC 3312 like this:
precondition-type = "sec" / "qos" / tokenRFC 3312 defines two kinds of status types, segmented and end-to-end. The security precondition-type defined here MUST be used with the end-to-end status type, and use of the segmented status type is undefined 🧚.
A security precondition can use the strength-tag mandatory, optional, or none 💜.
When a security precondition with a strength-tag of mandatory is received in an offer, session establishment or modification MUST be delayed until the security precondition has been met. That means the relevant cryptographic parameters (cipher, key, etc.) for a secure media stream are known to have been negotiated in the direction(s) required 🔥. When a mandatory security precondition is offered and the answerer can't satisfy it (for example, because the offer was for a secure media stream but didn't include the keying material needed to set up that secure stream), the offered media stream MUST be rejected as described in RFC 3312 💀.
The delay of session establishment defined here means that alerting of the called party MUST NOT occur, and media for which security is being negotiated MUST NOT be exchanged until the precondition has been satisfied 🛎️. When secure media and other non-media data are multiplexed on a media stream (for example, when Interactive Connectivity Establishment [ICE] is being used), the non-media data is allowed to be exchanged before the security precondition is satisfied ✨.
When a security precondition with a strength-tag of optional is received in an offer, the answerer MUST generate its answer SDP as soon as possible 🏃♀️. Since session progress isn't delayed in this case, the answerer doesn't know when the offerer is able to process secure media stream packets, so clipping may occur 😬. If the answerer wants to avoid clipping and delay session progress until it knows the offerer has received the answer, the answerer MUST increase the strength of the security precondition by using a strength-tag of mandatory in the answer 👑. Note that using a mandatory precondition in an offer requires the presence of a SIP Require header field containing the option tag precondition. Any SIP UA that doesn't support a mandatory precondition will reject such requests, and that has unintended ramifications for SIP forking, known as the Heterogeneous Error Response Forking Problem (see e.g., [HERFP]) 🍓. To get around this, an optional security precondition can be used together with the SIP Supported header field containing the option tag precondition instead 🎀.
When a security precondition with a strength-tag of none is received, processing continues as usual. The none strength-tag only tells you that the offerer supports the following security precondition. The answerer MAY upgrade the strength-tag in the answer, as described in [RFC3312] 🌈.
The direction tags defined in RFC 3312 work like this:
send: Media stream security negotiation is at a stage where it's possible to send media packets to the other party, and the other party will be able to process them correctly from a security point of view. That means they can decrypt and/or integrity check them as necessary 🔐. "Media packets" includes all packets that make up the media stream. With Secure RTP, for example, that includes SRTP as well as SRTCP. When media and non-media packets are multiplexed on a given media stream (for example, when ICE is being used), the requirement applies to the media packets only ✨.recv: Media stream security negotiation is at a stage where it's possible to receive and correctly process media stream packets sent by the other party, from a security point of view 🦋.
The precise criteria for deciding when the other party can correctly process media stream packets from a security point of view depend on the secure media stream protocol being used, as well as the mechanism used to negotiate the required cryptographic parameters 🧠.
Here are the details for SRTP negotiated through SDP security descriptions as defined in [SDESC] 🎀:
- When the offerer requests the
sendsecurity precondition, it needs to receive the answer before the security precondition is satisfied. There are two reasons for this. First, the offerer needs to know where to send the media. Second, if alternative cryptographic parameters were offered, the offerer needs to know which set was selected. The answerer doesn't know when the answer is actually received by the offerer (which is what satisfies the precondition), so the answerer needs to use the confirm-status attribute [RFC3312]. That makes the offerer generate a new offer showing the updated status of the precondition 📨. - When the offerer requests the
recvsecurity precondition, it also needs to receive the answer before the security precondition is satisfied. This one is pretty straightforward: the answer contains the cryptographic parameters the answerer will use to send media to the offerer. Without those parameters, the offerer can't authenticate or decrypt that media 🥹.
When security preconditions are used with the Key Management Extensions for the Session Description Protocol (SDP) [KMGMT], the details depend on the actual key management protocol being used 🗝️.
After an initial offer/answer exchange in which the security precondition is requested, any subsequent offer/answer sequence that updates the status of the precondition for a secure media stream SHOULD use the same key material as the initial offer/answer exchange 🔁. That means the key-mgmt attribute lines [KMGMT] or crypto attribute lines [SDESC] in SDP offers, which are sent in response to SDP answers containing a confirm-status field [RFC3312], SHOULD repeat the same data as was sent in the previous SDP offer. If it applies to the key management protocol or SDP security description, the SDP answers to these SDP offers SHOULD repeat the same data in the key-mgmt attribute lines [KMGMT] or crypto attribute lines [SDESC] as was sent in the previous SDP answer 🧁.
Of course, this duplication of key exchange during precondition establishment is not a replay attack 🙅♀️. This issue may be solved if, for example, the SDP implementation recognizes that the key management protocol data is identical in the second offer/answer exchange and avoids forwarding that information to the security layer for further processing 💡.
Offers with security preconditions in re-INVITEs or UPDATEs follow the rules given in Section 6 of RFC 3312, which say:
"Both user agents SHOULD continue using the old session parameters until all the mandatory preconditions are met. At that moment, the user agents can begin using the new session parameters."
At that moment, we also require that user agents MUST start using the new session parameters for media packets being sent 🚀. User agents SHOULD be prepared to process media packets received with either the old or the new session parameters for a short period of time, to accommodate media packets still in transit. Note that this may involve iterative security processing of the received media packets during that period 🌀. Section 8 in [RFC3264] lists several techniques to help figure out whether a received media packet was generated according to the old or the new offer/answer exchange 🕵️♀️.
4. Examples ✨
4.1. SDP Security Descriptions Example 🎀
okay so this example is giving "basic call setup, but make it secure" 💖 A and B are using SIP [SIP] with SDP security descriptions [SDESC] to protect the media stream (SRTP, in this case) ✨ The call flow in Figure 1 shows the handshake.
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
Figure 1: Security Preconditions with SDP Security
Descriptions ExampleThe SDP bodies in this example are shown below. We've left out the actual security description details and the SIP stuff so we can focus on the security precondition, bestie 🧚
SDP1: A puts a mandatory end-to-end security precondition for both the send and receive directions in the initial offer. A also includes a "crypto" attribute (see [SDESC]) with keying material that A can use to generate media packets 🔐 B doesn't know any security parameters yet, so the current status (see RFC 3312) is "none". A's local status table for the precondition looks like this:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | noand the offer SDP is:
m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1
a=curr:sec e2e none
a=des:sec mandatory e2e sendrecv
a=crypto:foo...SDP2: When B gets the offer and makes an answer, B knows the security parameters for both A and B 🫶 From a security standpoint, B can now receive media from A, so B's "recv" precondition is "yes". A doesn't know any of B's SDP info yet, though, so B's "send" precondition is still "no". B's local status table ends up like this:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | noB asks A to confirm once A knows the security parameters for the send and receive directions. (It would be enough for B to ask for confirmation of A's send direction only.) So the answer SDP becomes:
m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4
a=curr:sec e2e recv
a=des:sec mandatory e2e sendrecv
a=conf:sec e2e sendrecv
a=crypto:bar...SDP3: When A gets the answer, A updates its local status table following the rules in RFC 3312. A now knows the security parameters for both directions, so the table becomes:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yesB asked for confirmation of both the send and recv preconditions, and both are satisfied now, so A immediately sends an updated offer (3) to B showing that the preconditions are met 🎉
m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1
a=curr:sec e2e sendrecv
a=des:sec mandatory e2e sendrecv
a=crypto:foo...Note that we use PRACK [RFC3262] here instead of UPDATE [RFC3311] because the precondition is satisfied right away and the original offer/answer exchange is already complete 💅
SDP4: When B gets the updated offer, B updates its local status table following the rules in RFC 3312, which gives:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | noB replies with an answer (4) that shows the current status of the security precondition (i.e., sendrecv) from B's point of view:
m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4
a=curr:sec e2e sendrecv
a=des:sec mandatory e2e sendrecv
a=crypto:bar...B's local status table shows that all the mandatory preconditions are satisfied, so session establishment picks back up, and B sends a 180 (Ringing) response (5) to indicate alerting 🔔✨
4.2. Key Management Extension for SDP Example 🦋
This one is the same vibe, just with a different key management system. The call flow in Figure 2 shows a basic session setup using SIP [SIP] and Key Management Extensions for SDP [KMGMT] with security descriptions for the secure media stream (SRTP, in this case) 🌈
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
Figure 2: Security Preconditions with Key Management
Extensions for SDP ExampleThe SDP bodies are shown below. We use MIKEY [MIKEY] with the Key Management Extensions as an example, but we've left out the MIKEY parameter details and the SIP details so we can focus on the security precondition 🧁
SDP1: A puts a mandatory end-to-end security precondition for both the send and receive directions in the initial offer. A also includes a "key-mgmt" attribute (see [KMGMT]) with keying material that A can use to generate media packets. B doesn't know any security parameters yet, so the current status (see RFC 3312) is "none". A's local status table for the precondition looks like this:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | noand the offer SDP is:
m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1
a=curr:sec e2e none
a=des:sec mandatory e2e sendrecv
a=key-mgmt:mikey AQAFgM0X...SDP2: When B gets the offer and makes an answer, B knows the security parameters for both A and B. B generates keying material for sending media to A, but A doesn't know B's keying material yet, so B's "send" precondition is still "no". B does know A's SDP info, so B's "recv" precondition is "yes". B's local status table looks like this:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | noB asks A to confirm once A knows the security parameters for the send and receive directions, so the answer SDP becomes:
m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4
a=curr:sec e2e recv
a=des:sec mandatory e2e sendrecv
a=conf:sec e2e sendrecv
a=key-mgmt:mikey AQAFgM0X...Note that the actual MIKEY data in the answer is different from the offer's. We've only shown the initial and common part of the MIKEY value above 👀
SDP3: When A gets the answer, A updates its local status table following the rules in RFC 3312. A now knows all the security parameters for both directions, so the table becomes:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yesB asked for confirmation of the send and recv preconditions, and both are satisfied, so A immediately sends an updated offer (3) to B showing that the preconditions are met 💜
m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1
a=curr:sec e2e sendrecv
a=des:sec mandatory e2e sendrecv
a=key-mgmt:mikey AQAFgM0X...SDP4: When B gets the updated offer, B updates its local status table following the rules in RFC 3312, which gives:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | noB replies with an answer (4) that shows the current status of the security precondition (i.e., sendrecv) from B's point of view:
m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4
a=curr:sec e2e sendrecv
a=des:sec mandatory e2e sendrecv
a=key-mgmt:mikey AQAFgM0X...B's local status table shows that all the mandatory preconditions are satisfied, so session establishment resumes, and B sends a 180 (Ringing) response (5) to indicate alerting. That's a whole vibe 🥳✨
5. Security Considerations 🔐✨
okay bestie, this section is SERIOUS but also lowkey iconic, so buckle up 😭🫶. The general security stuff for preconditions is already covered in RFC 3312, so go read that too 📚. Then these extra issues need your attention, fr fr.
Security preconditions hold off session establishment until the crypto parameters needed to send and/or receive media for a media stream have been negotiated 🔒. Negotiation can totally fail for a bunch of reasons, like policy blocking certain crypto algorithms, keys, and other security parameters 🙅♀️. Now here's the tea: if an attacker can remove security preconditions or downgrade the strength-tag in an offer/answer exchange, they can make user alerting happen for a session that might have NO functioning media 💀. That's a whole mess for both the offerer and the answerer 😩. Preconditions can also stop clipping caused by race conditions between an offer/answer exchange and secure media stream packets based on that exchange 🎀. So if an attacker removes or downgrades the strength-tag of security preconditions, they can cause clipping in the associated secure media stream 🙈.
Conversely, an attacker might add security preconditions to offers that don't have them, or bump up their strength-tag 👀. That can lead to session failure (say, if the answerer doesn't support it), heterogeneous error response forking problems, or a delay in session establishment nobody wanted 😤.
Here's the fix, bestie: signaling integrity mechanisms can prevent ALL of the above 🛡️✨. If intermediaries on the signaling path (like SIP proxies) are trusted, hop-by-hop integrity protection of signaling (e.g., IPSec or TLS) is enough 🦋. In every other case, end-to-end integrity protection of signaling (e.g., S/MIME) MUST be used 💜. And the end-to-end protection MUST cover not only the message body (where the security preconditions live) but also the SIP "Supported" and "Require" headers, which may contain the "precondition" option tag 🎀. Why? If only the body is protected, removing the "precondition" option tag could cause clipping (when a security precondition was supposed to be used), while adding the option tag could cause session failure (if the other side doesn't support preconditions) 😭. Not me losing it over how sneaky this is 💅.
As Section 3 explains, security preconditions do NOT guarantee that the established media stream will be secure 🙅♀️. They only guarantee that the recipient of the media stream packets will be able to do any relevant decryption and integrity checking on those packets 🔐.
Current SDP [RFC4566] and its offer/answer procedures [RFC3264] only allow ONE type of transport protocol to be negotiated for a given media stream in an offer/answer exchange 🙃. Negotiating alternative transport protocols (like plain and secure RTP) isn't defined yet 🚫. So if the offered transport protocol (e.g., secure RTP) isn't supported, the offered media stream just gets rejected 💀. BUT there's work in progress to fix that ✨. For example, the SDP Capability Negotiation framework [SDPCN] defines a way to negotiate secure or non-secure transport protocols using SDP and the offer/answer model plus various extensions 🌈.
That mechanism brings its own security considerations in general, but using SDP Security Preconditions with it adds these precondition-specific ones 👑:
A basic premise of negotiating secure and non-secure media streams as alternatives is that the offerer's security policy ALLOWS non-secure media 🫠. If the offer includes secure and non-secure media streams as alternative offers, and media for either alternative may be received before the answer, then the offerer may not know whether the answerer accepted the secure alternative 😱. An active attacker could then inject malicious media stream packets until the answer (indicating the chosen secure alternative) arrives 👀. From a security standpoint, it's important to know that security preconditions (even with a mandatory strength-tag) would NOT fix this, because they only effectively apply to the secure alternatives 🙅♀️. If the answerer picked the non-secure alternative, the security precondition would be satisfied by definition, so the session could progress and (non-secure) media could be received before the answer arrives 💔.
6. IANA Considerations 📋
IANA has registered an RFC 3312 precondition type called "sec" with the name "Security precondition" 🎀. The reference for this precondition type is the current document 💖.
7. Acknowledgements 🙏
The security precondition was defined in earlier versions of RFC 3312 🌸. RFC 3312 has a huge list of people who worked on those earlier versions, and they're acknowledged here too 🫶. The authors also want to thank David Black, Mark Baugher, Gonzalo Camarillo, Paul Kyzivat, and Thomas Stach for their comments on this document 💜✨.
8. Normative References 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
- [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
- [SIP] 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.
- [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
9. Informative References 🧠
- [SDESC] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
- [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
- [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", Work in Progress, September 2007.
- [KMGMT] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
- [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
- [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
- [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
- [HERFP] Mahy, R., "A Solution to the Heterogeneous Error Response Forking Problem (HERFP) in the Session Initiation Protocol (SIP)", Work in Progress, March 2006.
- [SDPCN] Andreasen, F., "SDP Capability Negotiation", Work in Progress, July 2007.
Authors' Addresses 📮
- Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA EMail: fandreas@cisco.com
- Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: dwing@cisco.com
Full Copyright Statement ⚖️
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
📦 where this page comes from
- ietf: rfc5027 2007-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms