From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3702.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc3702.txt (limited to 'doc/rfc/rfc3702.txt') diff --git a/doc/rfc/rfc3702.txt b/doc/rfc/rfc3702.txt new file mode 100644 index 0000000..2ece520 --- /dev/null +++ b/doc/rfc/rfc3702.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group J. Loughney +Request for Comments: 3702 Nokia +Category: Informational G. Camarillo + Ericsson + February 2004 + + + Authentication, Authorization, and Accounting + Requirements for the Session Initiation Protocol (SIP) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + As Session Initiation Protocol (SIP) services are deployed on the + Internet, there is a need for authentication, authorization, and + accounting of SIP sessions. This document sets out the basic + requirements for this work. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 4 + 1.3. Requirements Language. . . . . . . . . . . . . . . . . . 4 + 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Common Requirements. . . . . . . . . . . . . . . . . . . 5 + 2.1.1. Communication within the Same Domain . . . . . . 5 + 2.1.2. Communication between Different Domains. . . . . 5 + 2.1.3. Discovery. . . . . . . . . . . . . . . . . . . . 5 + 2.1.4. Ability to Integrate Different Networks, + Services and Users . . . . . . . . . . . . . . . 5 + 2.1.5. Updating SIP Server Entries. . . . . . . . . . . 5 + 2.1.6. SIP Session Changes. . . . . . . . . . . . . . . 5 + 2.1.7. Reliable Transfer of Protocol Messages . . . . . 5 + 2.1.8. Call Setup Times . . . . . . . . . . . . . . . . 6 + 2.1.9. Security . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Authentication Requirements. . . . . . . . . . . . . . . 6 + 2.2.1. Authentication Based on SIP Requests . . . . . . 6 + 2.2.2. Flexible Authentication of SIP Requests. . . . . 6 + + + +Loughney & Camarillo Informational [Page 1] + +RFC 3702 AAA Requirements for SIP February 2004 + + + 2.3. Authorization Requirements . . . . . . . . . . . . . . . 6 + 2.3.1. Ability to Authorize SIP Requests. . . . . . . . 7 + 2.3.2. Information Transfer . . . . . . . . . . . . . . 7 + 2.3.3. User De-authorization. . . . . . . . . . . . . . 7 + 2.3.4. User Re-authorization. . . . . . . . . . . . . . 7 + 2.3.5. Support for Credit Control . . . . . . . . . . . 7 + 2.4. Accounting Requirements. . . . . . . . . . . . . . . . . 8 + 2.4.1. Separation of Accounting Information . . . . . . 8 + 2.4.2. Accounting Information Related to Session + Progression. . . . . . . . . . . . . . . . . . . 8 + 2.4.3. Accounting Information Not Related to Session + Progression. . . . . . . . . . . . . . . . . . . 9 + 2.4.4. Support for One-Time and Session-based + Accounting Records . . . . . . . . . . . . . . . 9 + 2.4.5. Support for Accounting on Different Media + Components . . . . . . . . . . . . . . . . . . . 9 + 2.4.6. Configuration of Accounting Generation + Parameters. . . . . . . . . . . . . . . . . . . 9 + 2.4.7. Support for Arbitrary Correlations . . . . . . . 9 + 3. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. WLAN Roaming Using Third Party Service Providers . . . . 11 + 3.2. Conditional Authorization. . . . . . . . . . . . . . . . 12 + 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 6.2. Informative References . . . . . . . . . . . . . . . . . 13 + 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 + +1. Introduction + + The AAA working group is chartered to work on authentication, + authorization, and accounting solutions for the Internet. This work + consists of a base protocol, applications, end-to-end security + application, and a general architecture for providing these services + [3]. The AAA working group has specified applicability of AAA-based + solutions for a number of protocols (e.g., AAA requirements for + Mobile IP [4]). + + SIP is a signalling protocol for creating, modifying, and terminating + different types of sessions, such as Internet phone calls, multimedia + distribution, and multimedia conferences [1]. SIP sessions have + needs for session authentication, authorization, and accounting + (AAA). + + + + + + +Loughney & Camarillo Informational [Page 2] + +RFC 3702 AAA Requirements for SIP February 2004 + + + In order to authenticate and authorize users, it is typically more + convenient for SIP entities to communicate with an AAA sever than to + attempt to store user credentials and profiles locally. SIP entities + use the SIP-AAA interface to access the AAA server. + + This document provides requirements for the interface between SIP + entities and AAA servers. While accounting requirements are + discussed, this document does not cover SIP charging or billing + mechanisms. + + One possible use of this document would be to create an AAA + application for SIP. Any protocol meeting the requirements outlined + by this document could be used. Possible candidates, among others, + are Diameter [3] and XML-based protocols following the web-services + model. + +1.1. RADIUS + + The main purpose of this document is to provide input to designers + working on AAA applications using new protocols, such as Diameter and + XML-based protocols. Nevertheless, a few limited RADIUS [5] + extensions may meet some of the requirements in this document (for + instance, some of the authentication requirements). We expect that + while RADIUS with these limited extensions will meet particular + functional requirements, it will not meet other important + requirements. The following are some requirements that are not + expected to be met by RADIUS: + + 1. Section 2.1.3: RADIUS does not support a discovery feature. + + 2. Section 2.1.7: RADIUS does not support reliable message + delivery. + + The following list contains the requirements that can be met by + RADIUS or RADIUS extensions. + + 1. Section 2.1.2: Communication between domains does not scale + well in RADIUS. As a result, inter-domain communications are + typically handled using a proxy architecture [6]. + + 2. Section 2.1.5: RADIUS clients would need to support Dynamic + Authorization [7]. + + 3. Section 2.1.9: RADIUS clients would need to rely on a lower- + layer security protocol, such as IPSec, to perform mutual + authentication. + + + + + +Loughney & Camarillo Informational [Page 3] + +RFC 3702 AAA Requirements for SIP February 2004 + + + 4. Section 2.3.3: RADIUS clients would need to support Dynamic + Authorization [7]. + + 5. Section 2.3.4: RADIUS clients would need to support Dynamic + Authorization [7]. + +1.2. Terminology and Acronyms + + AAA: Authentication, Authorization, and Accounting + + Accounting: The collection of resource consumption data for the + purposes of capacity and trend analysis, cost allocation, + auditing, and billing. Accounting management requires that + resource consumption be measured, rated, assigned, and + communicated between appropriate parties [8]. + + Accounting with credit control: The application checks the end user's + account for coverage for the requested service event charge + prior to execution of that service event. + + Home AAA Server: Server where user with which the user maintains an + account relationship. + + SIP: Session Initiation Protocol + + SIP proxies: SIP proxies are nodes which forward SIP requests and + responses, as well as make policy decisions. + + UAC: User Agent Client + + UAS: User Agent Server + +1.3. Requirements Language + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 + [2]. + +2. Requirements + + In this section, we list the requirements. Protocol solutions are + not required to satisfy requirements for services that they do not + support. For example, a solution that provides authentication + services but not accounting services does not need to fulfill the + accounting requirements. It is expected that solutions will fulfill + the general requirements, plus the requirements for the specific + services they are providing. + + + +Loughney & Camarillo Informational [Page 4] + +RFC 3702 AAA Requirements for SIP February 2004 + + + Section 2.1 lists general requirements, Section 2.2 lists + requirements related to authentication, Section 2.3 lists + requirements related to authorization, and Section 2.4 lists + requirements related to accounting. + +2.1. Common Requirements + + This section outlines general requirements on the SIP-AAA interface. + +2.1.1. Communication within the Same Domain + + The SIP-AAA interface MUST support communications between a SIP + entity and an AAA server that belong to the same domain. + +2.1.2. Communication between Different Domains + + The SIP-AAA interface MUST support communications between a SIP + entity in one domain and an AAA server in another domain. This MAY + involve a proxy or a redirect server architecture between both + entities. + +2.1.3. Discovery + + With the information contained in the SIP messages, the SIP-AAA + interface SHOULD be able to deduce the particular AAA server that has + to be queried. + +2.1.4. Ability to Integrate Different Networks, Services and Users + + The basic AAA architecture MUST be access independent. Service + providers have to be able to provide AAA services for SIP, + irrespective of access method or technology. + +2.1.5. Updating SIP Server Entries + + When required, the SIP-AAA interface MUST allow the AAA server to + update the information that a SIP entity has about a user. + +2.1.6. SIP Session Changes + + The SIP-AAA interface MUST allow a SIP entity to inform the AAA + server about changes in the SIP session that may affect the + authorization, authentication, or accounting for that SIP session. + +2.1.7. Reliable Transfer of Protocol Messages + + The SIP-AAA interface SHOULD provide a reliable transfer of AAA + protocol messages between the SIP entity and the AAA server. + + + +Loughney & Camarillo Informational [Page 5] + +RFC 3702 AAA Requirements for SIP February 2004 + + +2.1.8. Call Setup Times + + AAA SHOULD NOT unduly burden call setup times where appropriate. It + may be reasonable to support some delay during registration, but + delay during on-going sessions (especially real-time) is problematic. + +2.1.9. Security + + The SIP-AAA interface is a potential target of an attack. An + eavesdropper may attempt to obtain confidential data by sniffing + messages. Additionally, an active attacker may attempt to modify, + insert, or replay messages between the SIP entity and the AAA server. + Attackers may also attempt to impersonate legitimate SIP entities or + AAA servers. + + To address these threats, the SIP-AAA interface MUST support + confidentiality, data origin authentication, integrity, and replay + protection. In addition to this, bi-directional authentication + between the SIP entity and the AAA server MUST be supported as well. + +2.2. Authentication Requirements + + This section outlines requirements on the SIP-AAA interface related + to authentication. + +2.2.1. Authentication Based on SIP Requests + + The home AAA server MUST be able to authenticate a user based on any + SIP request, except CANCELs and ACKs for non-2xx final responses. + + CANCELs and ACKs for non-2xx final responses are hop-by-hop + requests that can be generated by proxies that do not have the + user's credentials. + +2.2.2. Flexible Authentication of SIP Requests + + The SIP-AAA interface MUST be flexible enough to accommodate a + variety of authentication mechanisms used to authenticate SIP + requests. In particular, the SIP-AAA interface MUST be able to + accommodate all the authentication mechanisms mandated by the SIP + specifications (e.g., Digest authentication). + +2.3. Authorization Requirements + + This section outlines requirements on the SIP-AAA interface related + to authorization. + + + + + +Loughney & Camarillo Informational [Page 6] + +RFC 3702 AAA Requirements for SIP February 2004 + + +2.3.1. Ability to Authorize SIP Requests + + The SIP-AAA interface MUST allow AAA servers to authorize any SIP + request, except CANCELs and ACKs for non-2xx final responses. + + CANCELs and ACKs for non-2xx final responses are hop-by-hop + requests that can be generated by proxies. SIP servers receiving + a CANCEL or a ACK for a non-2xx final response do not challenge + them, as they would do with an end-to-end request. Instead, they + check at the transport or network layer that the entity sending + the CANCEL or the ACK is the same as the one that generated the + request being canceled or acked. + +2.3.2. Information Transfer + + The SIP-AAA interface MUST allow transferring a wide range or set of + information to be used to make an authorization decision. In + particular, the SIP-AAA interface MUST allow an AAA server that is + making an authorization decision to deliver the user profile to the + SIP entity. Such a user profile may provide further information + about the authorization decision to the SIP entity. + + For instance, a SIP proxy receives an INVITE from user A addressed to + user B. The SIP proxy queries an AAA server and gets the following + answer: user A is authorized to call user B, as long as the requests + are routed through a particular SIP proxy server C. In this case, + the SIP proxy needs to use SIP loose routing techniques to forward + the INVITE so that it traverses SIP proxy C before reaching user B. + +2.3.3. User De-authorization + + The SIP-AAA interface MUST allow the AAA server to inform a SIP + entity when a particular user is no longer authorized to perform a + particular task, even if it is an ongoing task. + +2.3.4. User Re-authorization + + The SIP-AAA interface MUST allow the AAA server to inform a SIP + entity that a particular authorization has been refreshed, and + therefore, the user is still authorized to perform a particular task. + +2.3.5. Support for Credit Control + + The SIP-AAA interface MUST support credit control. That is, the AAA + server has to be able to check the end user's account for coverage + for the requested service event charge before authorizing execution + of that service event. Note that this requirement is related to + accounting as well. + + + +Loughney & Camarillo Informational [Page 7] + +RFC 3702 AAA Requirements for SIP February 2004 + + + Credit control is useful to implement prepaid services where all + chargeable events related to a specific account are withheld from the + end user when the credit of that account is exhausted or expired. + +2.4. Accounting Requirements + + This section outlines requirements on the SIP-AAA interface related + to accounting. Accounting is more than simple charging. Accounting + may be a simple list of services accessed, servers accessed, duration + of session, etc. Charging for SIP sessions can be extremely complex + and requires some additional study. It is not the intent of this + section to focus on charging. + + The information available to be accounted is different at SIP + proxies and at SIP UAs. When end-to-end encryption is used, + proxies do not have access to some parts of the SIP messages, + while UAs have access to the whole messages. In addition to this, + UAs typically have information about the session itself (e.g., + number of audio packets exchanged during an audio session). + Therefore, even if the SIP-AAA interface provides a means to + transfer a wide range of data, some SIP nodes may not have access + to it. In order to design a network, it is important to analyze + which SIP nodes will be able to generate the desired account + records. + +2.4.1. Separation of Accounting Information + + AAA accounting messages MUST be able to provide granular information + based on different parameters. + + For example, it should be possible to separate "session duration" + information from other information generated via additional services + (e.g., 3-way calling). Separating accounting information makes it + possible to provide accounting information to different parties based + upon different aspects of the session. + +2.4.2. Accounting Information Related to Session Progression + + There MUST be support in the SIP-AAA interface for accounting + transfers where the information contained in the accounting data has + a direct bearing on the establishment, progression, and termination + of a session (e.g., reception of a BYE request). + + + + + + + + + +Loughney & Camarillo Informational [Page 8] + +RFC 3702 AAA Requirements for SIP February 2004 + + +2.4.3. Accounting Information Not Related to Session Progression + + There MUST be support in the SIP-AAA interface for accounting + transfers where the information contained in the accounting data does + NOT have a direct bearing on the establishment, progression, and + termination of a session (e.g., an instant MESSAGE that is not + related to any session). + +2.4.4. Support for One-Time and Session-based Accounting Records + + The SIP-AAA interface MUST allow SIP servers to provide relevant + accounting information for billing and inter-network settlement + purposes to the AAA servers. Both one-time event accounting records + and session based (START, INTERIM, STOP records) accounting MUST be + supported. + +2.4.5. Support for Accounting on Different Media Components + + The SIP-AAA interface MUST support accounting per media component + (e.g., voice and video). That is, the SIP-AAA interface MUST be able + to provide the AAA server with the types (e.g., voice and video) of + the media streams of a given session. + + Note, however, that some SIP entities do not have access to this + information, which is typically carried in session descriptions. An + example of a SIP entity with access to this information is a SIP UA + (e.g., a gateway towards the PSTN). + + The SIP-AAA interface MUST enable different parties to be charged per + media component. + +2.4.6. Configuration of Accounting Generation Parameters + + The SIP-AAA interface MUST allow AAA servers to communicate + parameters for accounting generation. + +2.4.7. Support for Arbitrary Correlations + + Some networks need to be able to relate accounting information to + some aspect of the SIP messages involved. So, the SIP-AAA interface + MUST allow the AAA server to correlate a particular AAA session with + any aspect of the SIP messages. For example, an AAA server that + receives accounting information about a SIP dialog may be interested + in knowing the Call-ID of the SIP dialog. + + + + + + + +Loughney & Camarillo Informational [Page 9] + +RFC 3702 AAA Requirements for SIP February 2004 + + +3. Scenarios + + This section outlines some possible scenarios for SIP and AAA + interaction. These are purely illustrative examples and do not + impose any requirements. + + Figure 1 shows the typical call flow between a SIP proxy that + communicates to an AAA server that performs authentication and + authorization. All the examples are based on this flow. + + SIP SIP AAA + UAC Proxy Server + + | | | + |---METHOD---->| | + | |--Is it OK?-->| + | | | + | |<-----OK------| + | | | + | | | + + Figure 1: Call flow over the SIP-AAA interface + + The SIP proxy receives a request with certain credentials. The SIP + UAC that generated the request may have included the credentials + after having been challenged by the proxy using a 407 (Proxy + Authentication Required) response. The SIP proxy sends a request to + the AAA server asking if it is OK to provide a particular service for + this request. The service may be simply routing forward the request + or may consist of a more complex service. The AAA server checks that + the credentials are correct (authentication), and checks the user + profile. The user profile indicates that it is OK to provide the + service, and responds to the SIP proxy. The SIP proxy provides the + service requested by the SIP UAC. + + + + + + + + + + + + + + + + + +Loughney & Camarillo Informational [Page 10] + +RFC 3702 AAA Requirements for SIP February 2004 + + +3.1. WLAN Roaming Using Third Party Service Providers + + User A wants to establish a voice session over the Internet with user + B. User A wants its SIP signalling to be routed through SIP proxy C, + because it provides a call log service (i.e., SIP proxy C sends an + email to user A once a month with the duration of all the calls made + during the month). + + SIP AAA + User A Proxy C Server User B + + | | | | + |----INVITE----->| | | + | | | | + |<-----407-------| | | + | | | | + |------ACK------>| | | + | | | | + |----INVITE----->| | | + | |---Is this OK?-->| | + | | | | + | |<------OK--------| | + | | | | + | |---------INVITE------------------>| + | | | | + | |-Accounting msg->| | + | | | | + + Figure 2: WLAN roaming user + + User A accesses the Internet using a WLAN access outside his home + domain. User A, user B, SIP proxy C, and the home AAA server of user + A are all in different domains. + + SIP proxy C challenges the initial INVITE from user A with a 407 + (Proxy Authentication Required) response, and user A reissues the + INVITE including his credentials. SIP proxy C consults user A's home + AAA server, which confirms that the credentials belong to user A and + that SIP proxy C can go ahead and provide its service for that call. + SIP proxy C routes the INVITE forward towards user B and sends an + accounting message to the AAA server, which will be used later to + charge user A for the service provided by SIP proxy C. + + + + + + + + + +Loughney & Camarillo Informational [Page 11] + +RFC 3702 AAA Requirements for SIP February 2004 + + +3.2. Conditional Authorization + + User A is not in his home domain, but he still uses SIP proxy C + (which is in user's A home domain) as the outbound proxy for an + INVITE. SIP proxy C consults the home AAA server, which indicates + that requests from user A have to be routed through SIP proxy D. SIP + proxy C uses SIP loose routing so that the INVITE traverses D before + reaching its destination. SIP proxy D will provide a call log + service for user A. + + SIP AAA SIP + User A Proxy C Server Proxy D + + | | | | + |----INVITE----->| | | + | | | | + |<-----407-------| | | + | | | | + |------ACK------>| | | + | | | | + |----INVITE----->| | | + | |------Is this OK?---->| | + | | | | + | |<-OK if routed thru D-| | + | | | | + | |---------INVITE------------------>| + | | | | + + Figure 3: Conditional Authorization + +4. Security Considerations + + Security is a critical requirement of the SIP-AAA Interface. Section + 2.1.9 describes the threats and security requirements. Sections 2.2 + and 2.3 elaborate on the authentication and authorization + requirements. + +5. Acknowledgements + + The authors would like to thank the participants of the SIP interim + meeting, May 2002 for their comments. The authors would also thank + Harri Hakala, Mary Barns, Pete McCann, Jari Arkko, Aki Niemi, Juha + Heinanen, Henry Sinnreich, Allison Mankin, and Bernard Aboba for + their comments. + + The authors would like to thank the authors of the "AAA Requirements + for IP Telephony/Multimedia" document, as it provided a basis for + some of the information contained in this document. + + + +Loughney & Camarillo Informational [Page 12] + +RFC 3702 AAA Requirements for SIP February 2004 + + +6. References + +6.1. Normative References + + [1] 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. + + [2] Bradner, S., "Key words for use in RFCs to indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +6.2. Informative References + + [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, + "Diameter Base Protocol", RFC 3588, September 2003. + + [4] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP + Authentication, Authorization, and Accounting Requirements", RFC + 2977, October 2000. + + [5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote + Authentication Dial in User Service (RADIUS)", RFC 2865, June + 2000. + + [6] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy + Implementation in Roaming", RFC 2607, June 1999. + + [7] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, + "Dynamic Authorization Extensions to Remote Authentication Dial + in User Service (RADIUS)", RFC 3576, July 2003. + + [8] Aboba, B., Arkko, J. and D. Harrington, "Introduction to + Accounting Management", RFC 2975, October 2000. + + + + + + + + + + + + + + + + + + +Loughney & Camarillo Informational [Page 13] + +RFC 3702 AAA Requirements for SIP February 2004 + + +7. Authors' Addresses + + John Loughney + Nokia + Itamerenkatu 11-13 + 00180 Helsinki + Finland + + EMail: John.Loughney@nokia.com + + + Gonzalo Camarillo + Ericsson + Advanced Signalling Research Lab. + FIN-02420 Jorvas + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney & Camarillo Informational [Page 14] + +RFC 3702 AAA Requirements for SIP February 2004 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (2004). 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. + + + + + + + + + +Loughney & Camarillo Informational [Page 15] + -- cgit v1.2.3