SIPPING Working Group John Loughney Internet-Draft Nokia Gonzalo Camarillo Ericsson June 30, 2002 SIP-AAA Requirements < draft-loughney-sip-aaa-req-01.txt > Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Copyright (C) The Internet Society 2002. All Rights Reserved. Abstract As 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. Loughney, Camarillo expires December 30, 2002 [Page 1] Internet-Draft June 30, 2002 Table of Contents 1 Introduction 1.1 Scope of This Document 1.2 Terminology 1.3 Requirements Language 2 Requirements 2.1 Common Requirements 2.2 Authentication Requirements 2.3 Authorization Requirements 2.4 Accounting Requirements 3 Scenarios 3.1 WLAN Roaming Using Third Party Service Providers 3.2 Simple 3GPP Example 4 Security Considerations 5 Acknowledgements 6 References 6.1 Normative 6.2 Non-Normative 7 Authors' Addresses 8 Full Copyright Statement Loughney, Camarillo expires December 30, 2002 [Page 2] Internet-Draft June 30, 2002 1 Introduction The AAA working group is chartered to work on authentication, authorization and accounting solutions for the Internet, which consists of a base protocol, applications, end-to-end security application and a general architecture for providing these services [AAA-PROB]. The applicability of AAA-based solutions for a number of protocols have been specified, for example the AAA requirements for Mobile IP [MIP-AAA]. SIP provides a signaling protocol for creating, modifying and terminating different types sessions such as Internet phone calls, multimedia distribution and multimedia conferences [SIP, SIP-BIS]. 1.1 Scope of This Document SIP sessions have needs for session authentication, authorization and accounting. This document outlines some of the requirements that SIP has for AAA. This document is intended as a generic document for SIP AAA requirements. This document does not intend to develop a charging and/or billing mechanism for SIP. One possible use of this document would be to create a basic AAA application for SIP needs. This could be a Diameter application, possibly where with Diameter running in Radius-compatibility mode. There may also be needs for a mechanism for tying this into a Web- services model. 1.2 Terminology AAA Authentication, Authorization and Accounting Accounting In this draft, accounting is meant in a broad sense, not simply charging or billing. Home AAA Server Server where user with which the user maintains an account relationship. Online Accounting Downloading some kind of credit into the access device, and deducting from that credit as usage accumulates. Offline Accounting Transferring records to a home accounting server, for later billing and settlement, Loughney, Camarillo expires December 30, 2002 [Page 3] Internet-Draft June 30, 2002 without doing any accounting-related control or feedback for the services rendered. SIP Session Initiation Protocol UAC User Agent Client UAS User Agent Server Proxies Proxies are nodes which forward requests and responses as well as make policy decisions. 1.3 Requirements Language In this document, the key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [KEYWORDS]. 2 Requirements In this section, we list the requirements. It is assumed that different situations, deployment scenarios will affect which requirements are needed. It is not intended that all requirements are needed to be supported. 2.1 Common Requirements 2.1.1 Ability to Integrate Different Networks, Services and Users The basic AAA architecture allows for the support of different access methods and technologies. Service providers MUST be able to provide AAA services for SIP irrespective of access method or technology. 2.1.2 Updating SIP Server Entries The home AAA server MUST be able to update the entry of the assigned SIP server for the user when required. 2.1.3 Indication of Assigned Server The home AAA server MUST be able to provide the assigned server of the user to the SIP entities requesting it. 2.1.4 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 sessions (especially real-time) are problematic. 2.1.5 SIP Server Allocation Loughney, Camarillo expires December 30, 2002 [Page 4] Internet-Draft June 30, 2002 The AAA infrastructure or the UAS MUST be able to allocate a SIP server for a subscriber when required, based on policies, load distribution etc. 2.1.6 Ability to Provide Session Information to the Parties Involved Ability for SIP Servers to provide the duration of a session, the parties involved, and other relevant information to the visited and home AAA servers as accounting information. 2.1.7 Security AAA data MUST be able to be securely transported. The endpoints MUST be authenticated before data is sent. The endpoints MAY be authorized to access certain types of AAA data. 2.1.5 User De-authorization The home AAA server MUST be able to inform a SIP server when a particular user is no longer authorized to perform a particular task, even if it is an ongoing task. 2.2 Authentication Requirements 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 CANCEL. 2.2.2 Flexible Authentication of SIP requests The scheme supported for the authentication between the SIP servers and the AAA infrastructure MUST be flexible enough to accommodate a variety of authentication mechanisms. 2.3 Authorization Requirements 2.3.1 Ability to Authorize SIP Registration It MUST be possible for the Home AAA server to authorize any SIP request, except CANCEL. 2.3.2 Information transfer It MUST be possible to transfer a wide range or set of information needed to make an authorization decision. 2.3.3 Distribution of Profiles Loughney, Camarillo expires December 30, 2002 [Page 5] Internet-Draft June 30, 2002 A SIP entity performing authentication, authorization or accounting MUST be able to access the information needed to perform its task (e.g., user profile) in the AAA server. 2.3.4 Authorization Based on Policy The home AAA server MAY authorize a session (the end result of a successful SIP INVITE method); implementing whatever policy it wishes, such as based upon time of day, distance, etc. 2.4 Accounting Requirements 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. 2.4.1 Separation of Accounting Information AAA accounting messages MUST be able separate "session duration" information from other information generated via additional services (e.g. 3-way calling, etc.) 2.4.2 Accounting Information Related to Session Progression There MUST be support for accounting transfers where the information contained in the accounting data has a direct bearing on the establishment, progression and termination of a session. 2.4.3 Accounting Information Not Related to Session Progression There MUST be support 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. 2.4.4 Support for One-Time and Session-based Accounting Records SIP servers MUST be able to provide relevant accounting information for billing and inter-network settlement purpose to home and visited AAA servers. Both one-time event accounting records and session based (START, INTERIM, STOP records) accounting MUST be supported. 2.4.5 SIP Session Changes Accounting messages MUST be able to reflect changes in the SIP session that affects the charging of SIP session. Loughney, Camarillo expires December 30, 2002 [Page 6] Internet-Draft June 30, 2002 2.4.6 Support for Accounting on Different Media Components The AAA accounting protocol MUST support accounting per media component (e.g. voice, video). The AAA accounting Protocol MUST enable different parties to be charged per media component. 2.4.7 Support for Stateful and Stateless Accounting Stateful and stateless accounting MUST be possible. 2.4.8 Configuration of Accounting Generation Parameters Parameters for accounting generation must be either configurable in the SIP servers or communicated by the AAA servers. 2.4.9 Support for Arbitrary Correlation IDs Some networks need to be able to relate the accounting to some aspect of the session. Therefore, there is a need to support arbitrary correlation IDs. 2.4.10 Support for Accounting Autoconfiguration The ability support for autoconfiguration (automatic discovery process of accounting servers, for example) to the SIP node MUST be supported. 2.4.11 Support of Credit-based Charging Support for credit-based charging is needed. The accounting application must be able to check the end user's account for coverage for the requested service event charge prior to execution of that service event. All the chargeable events related to a specific account must be prevented from the end user when the credit of that account is exhausted or expired. 2.4.11 The scheme supported for the accounting between the SIP servers and the AAA infrastructure MUST be flexible enough to accommodate a variety of accounting mechanisms. 3 Scenarios This section outlines some possible scenarios for SIP and AAA interaction. These are purely illustrative examples, and do not impose any requirements. Loughney, Camarillo expires December 30, 2002 [Page 7] Internet-Draft June 30, 2002 3.1 WLAN Roaming Using Third Party Service Providers To be added. 3.2 Simple 3GPP Example To be added. 4 Security Considerations This document is informational in nature, so it does not directly affect the security of the Internet. However, security is a basic requirement of this work. 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 Mary Barns, Pete McCann for their comments. The authors would like to thank the authors of the "AAA Requirements for IP Telephony/Multimedia" draft, which some of the information in this document is based on. 6 References 6.1 Normative [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol". RFC 2543, March 1999. [SIP-BIS] J. Rosenberg, et. al, "SIP: Session Initiation Protocol". Work in Progress. 6.2 Non-Normative [AAA-PROB] P. Calhoun, et. al, "AAA Problem Statements". Work in Pro- gress. [MIP-AAA] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Loughney, Camarillo expires December 30, 2002 [Page 8] Internet-Draft June 30, 2002 Authorization, and Accounting Requirements". RFC 2977, October 2000. 7 Authors' Addresses Questions about this memo can be directed to: John Loughney Nokia Research Center It„merenkatu 11-13 00180 Helsinki Finland Phone: +358 50 483 6242 E-mail: john.Loughney@nokia.com Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland Phone: +358 9 299 3371 Fax: +358 9 299 3052 Email: Gonzalo.Camarillo@ericsson.com 8 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The lim- ited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE Loughney, Camarillo expires December 30, 2002 [Page 9] Internet-Draft June 30, 2002 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIM- ITED 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. Loughney, Camarillo expires December 30, 2002 [Page 10]