idnits 2.17.1 draft-loughney-sip-aaa-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 4) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2002) is 7970 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AAA-PROB' is mentioned on line 353, but not defined == Missing Reference: 'MIP-AAA' is mentioned on line 356, but not defined ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIP-BIS' Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group John Loughney 3 Internet-Draft Nokia 4 Gonzalo Camarillo 5 Ericsson 7 June 30, 2002 9 SIP-AAA Requirements 10 < draft-loughney-sip-aaa-req-01.txt > 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Distribution of this memo is unlimited. 35 Copyright (C) The Internet Society 2002. All Rights Reserved. 37 Abstract 39 As SIP services are deployed on the Internet, there is a need for 40 authentication, authorization and accounting of SIP sessions. This 41 document sets out the basic requirements for this work. 43 Table of Contents 45 1 Introduction 46 1.1 Scope of This Document 47 1.2 Terminology 48 1.3 Requirements Language 50 2 Requirements 51 2.1 Common Requirements 52 2.2 Authentication Requirements 53 2.3 Authorization Requirements 54 2.4 Accounting Requirements 56 3 Scenarios 57 3.1 WLAN Roaming Using Third Party Service Providers 58 3.2 Simple 3GPP Example 60 4 Security Considerations 62 5 Acknowledgements 64 6 References 65 6.1 Normative 66 6.2 Non-Normative 68 7 Authors' Addresses 70 8 Full Copyright Statement 72 1 Introduction 74 The AAA working group is chartered to work on authentication, 75 authorization and accounting solutions for the Internet, which 76 consists of a base protocol, applications, end-to-end security 77 application and a general architecture for providing these services 78 [AAA-PROB]. 80 The applicability of AAA-based solutions for a number of protocols 81 have been specified, for example the AAA requirements for Mobile IP 82 [MIP-AAA]. 84 SIP provides a signaling protocol for creating, modifying and 85 terminating different types sessions such as Internet phone calls, 86 multimedia distribution and multimedia conferences [SIP, SIP-BIS]. 88 1.1 Scope of This Document 90 SIP sessions have needs for session authentication, authorization and 91 accounting. This document outlines some of the requirements that SIP 92 has for AAA. This document is intended as a generic document for SIP 93 AAA requirements. 95 This document does not intend to develop a charging and/or billing 96 mechanism for SIP. 98 One possible use of this document would be to create a basic AAA 99 application for SIP needs. This could be a Diameter application, 100 possibly where with Diameter running in Radius-compatibility mode. 101 There may also be needs for a mechanism for tying this into a Web- 102 services model. 104 1.2 Terminology 106 AAA Authentication, Authorization and Accounting 108 Accounting In this draft, accounting is meant in a broad 109 sense, not simply charging or billing. 111 Home AAA Server Server where user with which the user maintains 112 an account relationship. 114 Online Accounting Downloading some kind of credit into the 115 access device, and deducting from that credit 116 as usage accumulates. 118 Offline Accounting Transferring records to a home accounting 119 server, for later billing and settlement, 120 without doing any accounting-related control 121 or feedback for the services rendered. 122 SIP Session Initiation Protocol 124 UAC User Agent Client 126 UAS User Agent Server 128 Proxies Proxies are nodes which forward requests 129 and responses as well as make policy decisions. 131 1.3 Requirements Language 133 In this document, the key words "MAY", "MUST", "MUST NOT", 134 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 135 interpreted as described in [KEYWORDS]. 137 2 Requirements 139 In this section, we list the requirements. It is assumed that 140 different situations, deployment scenarios will affect which 141 requirements are needed. It is not intended that all requirements 142 are needed to be supported. 144 2.1 Common Requirements 146 2.1.1 Ability to Integrate Different Networks, Services and Users 148 The basic AAA architecture allows for the support of different access 149 methods and technologies. Service providers MUST be able to provide 150 AAA services for SIP irrespective of access method or technology. 152 2.1.2 Updating SIP Server Entries 154 The home AAA server MUST be able to update the entry of the assigned 155 SIP server for the user when required. 157 2.1.3 Indication of Assigned Server 159 The home AAA server MUST be able to provide the assigned server of 160 the user to the SIP entities requesting it. 162 2.1.4 Call Setup Times 164 AAA should not unduly burden call setup times where appropriate. 166 It may be reasonable to support some delay during registration, but 167 delay during sessions (especially real-time) are problematic. 169 2.1.5 SIP Server Allocation 170 The AAA infrastructure or the UAS MUST be able to allocate a SIP 171 server for a subscriber when required, based on policies, load 172 distribution etc. 174 2.1.6 Ability to Provide Session Information to the Parties Involved 176 Ability for SIP Servers to provide the duration of a session, the 177 parties involved, and other relevant information to the visited and 178 home AAA servers as accounting information. 180 2.1.7 Security 182 AAA data MUST be able to be securely transported. The endpoints MUST 183 be authenticated before data is sent. The endpoints MAY be authorized 184 to access certain types of AAA data. 186 2.1.5 User De-authorization 188 The home AAA server MUST be able to inform a SIP server when a 189 particular user is no longer authorized to perform a particular task, 190 even if it is an ongoing task. 192 2.2 Authentication Requirements 194 2.2.1 Authentication Based on SIP Requests 196 The home AAA server MUST be able to authenticate a user based on any 197 SIP request, except CANCEL. 199 2.2.2 Flexible Authentication of SIP requests 201 The scheme supported for the authentication between the SIP servers 202 and the AAA infrastructure MUST be flexible enough to accommodate a 203 variety of authentication mechanisms. 205 2.3 Authorization Requirements 207 2.3.1 Ability to Authorize SIP Registration 209 It MUST be possible for the Home AAA server to authorize any SIP 210 request, except CANCEL. 212 2.3.2 Information transfer 214 It MUST be possible to transfer a wide range or set of information 215 needed to make an authorization decision. 217 2.3.3 Distribution of Profiles 218 A SIP entity performing authentication, authorization or accounting 219 MUST be able to access the information needed to perform its task 220 (e.g., user profile) in the AAA server. 222 2.3.4 Authorization Based on Policy 224 The home AAA server MAY authorize a session (the end result of a 225 successful SIP INVITE method); implementing whatever policy it 226 wishes, such as based upon time of day, distance, etc. 228 2.4 Accounting Requirements 230 Accounting is more than simple charging. Accounting may be a simple 231 list of services accessed, servers accessed, duration of session, 232 etc. Charging for SIP sessions can be extremely complex and requires 233 some additional study. It is not the intent of this section to focus 234 on charging. 236 2.4.1 Separation of Accounting Information 238 AAA accounting messages MUST be able separate "session duration" 239 information from other information generated via additional services 240 (e.g. 3-way calling, etc.) 242 2.4.2 Accounting Information Related to Session Progression 244 There MUST be support for accounting transfers where the information 245 contained in the accounting data has a direct bearing on the 246 establishment, progression and termination of a session. 248 2.4.3 Accounting Information Not Related to Session Progression 250 There MUST be support for accounting transfers where the information 251 contained in the accounting data does NOT have a direct bearing on 252 the establishment, progression and termination of a session. 254 2.4.4 Support for One-Time and Session-based Accounting Records 256 SIP servers MUST be able to provide relevant accounting information 257 for billing and inter-network settlement purpose to home and visited 258 AAA servers. Both one-time event accounting records and session based 259 (START, INTERIM, STOP records) accounting MUST be supported. 261 2.4.5 SIP Session Changes 263 Accounting messages MUST be able to reflect changes in the SIP 264 session that affects the charging of SIP session. 266 2.4.6 Support for Accounting on Different Media Components 268 The AAA accounting protocol MUST support accounting per media 269 component (e.g. voice, video). The AAA accounting Protocol MUST 270 enable different parties to be charged per media component. 272 2.4.7 Support for Stateful and Stateless Accounting 274 Stateful and stateless accounting MUST be possible. 276 2.4.8 Configuration of Accounting Generation Parameters 278 Parameters for accounting generation must be either configurable in 279 the SIP servers or communicated by the AAA servers. 281 2.4.9 Support for Arbitrary Correlation IDs 283 Some networks need to be able to relate the accounting to some aspect 284 of the session. Therefore, there is a need to support arbitrary 285 correlation IDs. 287 2.4.10 Support for Accounting Autoconfiguration 289 The ability support for autoconfiguration (automatic discovery 290 process of accounting servers, for example) to the SIP node MUST be 291 supported. 293 2.4.11 Support of Credit-based Charging 295 Support for credit-based charging is needed. The accounting 296 application must be able to check the end user's account for coverage 297 for the requested service event charge prior to execution of that 298 service event. All the chargeable events related to a specific 299 account must be prevented from the end user when the credit of that 300 account is exhausted or expired. 302 2.4.11 304 The scheme supported for the accounting between the SIP servers and 305 the AAA infrastructure MUST be flexible enough to accommodate a 306 variety of accounting mechanisms. 308 3 Scenarios 310 This section outlines some possible scenarios for SIP and AAA 311 interaction. These are purely illustrative examples, and do not 312 impose any requirements. 314 3.1 WLAN Roaming Using Third Party Service Providers 316 To be added. 318 3.2 Simple 3GPP Example 320 To be added. 322 4 Security Considerations 324 This document is informational in nature, so it does not directly 325 affect the security of the Internet. However, security is a basic 326 requirement of this work. 328 5 Acknowledgements 330 The authors would like to thank the participants of the SIP interim 331 meeting, May 2002 for their comments. The authors would also thank 332 Mary Barns, Pete McCann for their comments. 334 The authors would like to thank the authors of the "AAA Requirements 335 for IP Telephony/Multimedia" draft, which some of the information in 336 this document is based on. 338 6 References 340 6.1 Normative 342 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, 346 "SIP: Session Initiation Protocol". RFC 2543, March 1999. 348 [SIP-BIS] J. Rosenberg, et. al, "SIP: Session Initiation Protocol". 349 Work in Progress. 351 6.2 Non-Normative 353 [AAA-PROB] P. Calhoun, et. al, "AAA Problem Statements". Work in Pro- 354 gress. 356 [MIP-AAA] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 357 Authorization, and Accounting Requirements". RFC 2977, 358 October 2000. 360 7 Authors' Addresses 362 Questions about this memo can be directed to: 364 John Loughney 365 Nokia Research Center 366 It�merenkatu 11-13 367 00180 Helsinki 368 Finland 370 Phone: +358 50 483 6242 371 E-mail: john.Loughney@nokia.com 373 Gonzalo Camarillo 374 Ericsson 375 Advanced Signalling Research Lab. 376 FIN-02420 Jorvas 377 Finland 379 Phone: +358 9 299 3371 380 Fax: +358 9 299 3052 381 Email: Gonzalo.Camarillo@ericsson.com 383 8 Full Copyright Statement 385 Copyright (C) The Internet Society (2002). All Rights Reserved. 387 This document and translations of it may be copied and furnished to 388 others, and derivative works that comment on or otherwise explain it 389 or assist in its implementation may be prepared, copied, published 390 and distributed, in whole or in part, without restriction of any 391 kind, provided that the above copyright notice and this paragraph are 392 included on all such copies and derivative works. However, this docu- 393 ment itself may not be modified in any way, such as by removing the 394 copyright notice or references to the Internet Society or other 395 Internet organizations, except as needed for the purpose of develop- 396 ing Internet standards in which case the procedures for copyrights 397 defined in the Internet Standards process must be followed, or as 398 required to translate it into languages other than English. The lim- 399 ited permissions granted above are perpetual and will not be revoked 400 by the Internet Society or its successors or assigns. This document 401 and the information contained herein is provided on an "AS IS" basis 402 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 403 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIM- 404 ITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 405 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 406 FITNESS FOR A PARTICULAR PURPOSE.