summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3702.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3702.txt')
-rw-r--r--doc/rfc/rfc3702.txt843
1 files changed, 843 insertions, 0 deletions
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]
+