idnits 2.17.1 draft-ietf-sipping-aaa-req-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 499 has weird spacing: '...Calhoun et al...' == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- 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 (February 5, 2003) is 7751 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft J. Loughney 4 Nokia 5 G. Camarillo 6 Ericsson 7 draft-ietf-sipping-aaa-req-02.txt 8 February 5, 2003 9 Expires: August, 2003 11 Authentication, Authorization and Accounting Requirements 12 for the Session Initiation Protocol 14 STATUS OF THIS MEMO 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 To view the list Internet-Draft Shadow Directories, see 33 http://www.ietf.org/shadow.html. 35 Abstract 37 As SIP services are deployed on the Internet, there is a need for 38 authentication, authorization and accounting of SIP sessions. This 39 document sets out the basic requirements for this work. 41 Table of Contents 43 1 Introduction ........................................ 4 44 1.1 Terminology and Acronyms ............................ 4 45 1.2 Requirements Language ............................... 5 46 2 Requirements ........................................ 5 47 2.1 Common Requirements ................................. 5 48 2.1.1 Communication within the same domain ................ 5 49 2.1.2 Communication between different domains ............. 5 50 2.1.3 Discovery ........................................... 5 51 2.1.4 Ability to Integrate Different Networks, Services 52 and Users ........................................... 5 53 2.1.5 Updating SIP Server Entries ......................... 6 54 2.1.6 Call Setup Times .................................... 6 55 2.1.7 Security ............................................ 6 56 2.2 Authentication Requirements ......................... 6 57 2.2.1 Authentication Based on SIP Requests ................ 6 58 2.2.2 Flexible Authentication of SIP requests ............. 6 59 2.3 Authorization Requirements .......................... 6 60 2.3.1 Ability to Authorize SIP Requests ................... 6 61 2.3.2 Information transfer ................................ 7 62 2.3.3 Distribution of Profiles ............................ 7 63 2.3.4 User De-authorization ............................... 7 64 2.4 Accounting Requirements ............................. 7 65 2.4.1 Separation of Accounting Information ................ 7 66 2.4.2 Accounting Information Related to Session 67 Progression ......................................... 8 68 2.4.3 Accounting Information Not Related to Session 69 Progression ......................................... 8 70 2.4.4 Support for One-Time and Session-based Accounting 71 Records ............................................. 8 72 2.4.5 SIP Session Changes ................................. 8 73 2.4.6 Support for Accounting on Different Media 74 Components .......................................... 8 75 2.4.7 Support for Stateful and Stateless Accounting ....... 8 76 2.4.8 Configuration of Accounting Generation Parameters ... 8 77 2.4.9 Support for Arbitrary Correlation IDs ............... 8 78 2.4.10 Support for Real-time and Non-Realtime Accounting ... 9 79 2.4.11 Flexible Interface .................................. 9 80 3 Scenarios ........................................... 9 81 3.1 WLAN Roaming Using Third Party Service Providers .... 10 82 3.2 Simple 3GPP Example ................................. 11 83 4 Security Considerations ............................. 12 84 5 Acknowledgements .................................... 12 85 6 Authors' Addresses .................................. 12 86 7 Normative References ................................ 12 87 8 Informative References .............................. 12 89 1 Introduction 91 The AAA working group is chartered to work on authentication, 92 authorization and accounting solutions for the Internet. This work 93 consists of a base protocol, applications, end-to-end security 94 application and a general architecture for providing these services 95 [3]. The AAA working group has specified applicability of AAA-based 96 solutions for a number of protocols (e.g., AAA requirements for 97 Mobile IP [4]). 99 SIP is a signalling protocol for creating, modifying and terminating 100 different types sessions such as Internet phone calls, multimedia 101 distribution and multimedia conferences [1]. SIP sessions have needs 102 for session authentication, authorization and accounting. In order to 103 perform AAA, SIP entities need to access AAA information (e.g., check 104 if the password provided by a user is correct or store accounting 105 records related to a particular session). Rather than collocating a 106 database with AAA information with every SIP entity in a network, it 107 is desirable to have a common logical AAA server accessible by all 108 the SIP entities. SIP entities use a SIP-AAA interface to access this 109 AAA server. This document outlines some requirements on this SIP-AAA 110 interface between SIP entities and AAA servers. This document is 111 intended as a generic document for SIP AAA requirements. It does not 112 intend to develop a charging and/or billing mechanism for SIP. 114 One possible use of this document would be to create a basic AAA 115 application for SIP needs. The protocol used in the SIP-AAA interface 116 could be any protocol that meets the requirements outlined by this 117 document. Possible candidates, among others, are Diameter and XML- 118 based protocols following the web-services model. 120 1.1 Terminology and Acronyms 122 AAA: Authentication, Authorization and Accounting 124 Accounting: In this draft, accounting is meant in a broad sense, 125 not simply charging or billing. 127 Home AAA Server: Server where user with which the user maintains 128 an account relationship. 130 Online Accounting: Also known as real-time accounting. 131 Downloading some kind of credit into the access device, and 132 deducting from that credit as usage accumulates. 134 Offline Accounting: Also known as non-realtime accounting. 135 Transferring records to a home accounting server, for later 136 billing and settlement, without doing any accounting- 137 related control or feedback for the services rendered. 139 SIP: Session Initiation Protocol 141 UAC: User Agent Client 143 UAS: User Agent Server 145 Proxies: Proxies are nodes which forward requests and responses 146 as well as make policy decisions. 148 1.2 Requirements Language 150 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 151 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 152 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]. 154 2 Requirements 156 In this section, we list the requirements. It is assumed that 157 different situations, deployment scenarios will affect which 158 requirements are needed. It is not intended that all requirements 159 need to be supported. Section 2.1 lists general requirements, Section 160 2.2 lists requirements related to authentication, Section 2.3 lists 161 requirements related to authorization and Section 2.4 lists 162 requirements related to accounting. 164 2.1 Common Requirements 166 This section outlines general requirements on the SIP-AAA interface. 168 2.1.1 Communication within the same domain 170 The SIP-AAA interface MUST support communications between a SIP 171 entity and a AAA server that belong to the same domain. 173 2.1.2 Communication between different domains 175 The SIP-AAA interface MUST support communications between a SIP 176 entity in one domain and a AAA server in another domain. 178 2.1.3 Discovery 180 With the information contained in the SIP messages, the SIP-AAA 181 interface MUST be able to deduct the particular AAA server that has 182 to be queried. 184 2.1.4 Ability to Integrate Different Networks, Services and Users 185 The basic AAA architecture MUST be access independent. Service 186 providers have to be able to provide AAA services for SIP, 187 irrespective of access method or technology. 189 2.1.5 Updating SIP Server Entries 191 When required, the SIP-AAA interface MUST allow the AAA server to 192 update the information about a user that a SIP entity has. 194 2.1.6 Call Setup Times 196 AAA SHOULD not unduly burden call setup times where appropriate. It 197 may be reasonable to support some delay during registration, but 198 delay during sessions (especially real-time) are problematic. 200 2.1.7 Security 202 AAA data MUST be able to be securely transported. The endpoints MUST 203 be authenticated before data is sent. The endpoints MAY be authorized 204 to access certain types of AAA data. 206 2.2 Authentication Requirements 208 This section outlines requirements on the SIP-AAA interface related 209 to authentication. 211 2.2.1 Authentication Based on SIP Requests 213 The home AAA server MUST be able to authenticate a user based on any 214 SIP request, except CANCEL. 216 CANCEL is a hop-by-hop request that can be generated by 217 proxies that do not have the user's credentials. 219 2.2.2 Flexible Authentication of SIP requests 221 The scheme supported for the authentication between the SIP servers 222 and the AAA infrastructure MUST be flexible enough to accommodate a 223 variety of authentication mechanisms. In particular, the SIP-AAA 224 interface MUST be able to accommodate all the authentication 225 mechanisms mandated by the SIP specs. 227 2.3 Authorization Requirements 229 This section outlines requirements on the SIP-AAA interface related 230 to authorization. 232 2.3.1 Ability to Authorize SIP Requests 233 The SIP-AAA interface MUST allow AAA servers to authorize any SIP 234 request, except CANCEL. 236 CANCEL is a hop-by-hop request that can be generated by 237 proxies. SIP servers receiving a CANCEL do not challenge 238 it, as they would do with an end-to-end request. Instead, 239 they check that the entity sending the CANCEL is the same 240 as the one that generated the request being canceled. 242 2.3.2 Information transfer 244 The SIP-AAA interface MUST allow transfering a wide range or set of 245 information to be used to make an authorization decision. 247 2.3.3 Distribution of Profiles 249 The SIP-AAA interface MUST allow a AAA server that is making an 250 authorization decision to deliver the user profile to the SIP entity. 251 Note that the user profile may provide further information about the 252 authorization decision to the SIP entity. For instance, a SIP proxy 253 receives an INVITE from user A addressed to user B. The SIP proxy 254 queries a AAA server and gets the following answer: user A is 255 authorized to call user B as long as the requests are routed through 256 a particular SIP proxy server C. In this case, the SIP proxy needs to 257 use SIP loose routing techniques to forward the INVITE so that it 258 traverses SIP proxy C before reaching user B. 260 2.3.4 User De-authorization 262 The SIP-AAA interface MUST allow the AAA server to inform a SIP 263 entity when a particular user is no longer authorized to perform a 264 particular task, even if it is an ongoing task. 266 2.4 Accounting Requirements 268 This section outlines requirements on the SIP-AAA interface related 269 to accounting. Accounting is more than simple charging. Accounting 270 may be a simple list of services accessed, servers accessed, duration 271 of session, etc. Charging for SIP sessions can be extremely complex 272 and requires some additional study. It is not the intent of this 273 section to focus on charging. 275 2.4.1 Separation of Accounting Information 277 AAA accounting messages MUST be able to separate "session duration" 278 information from other information generated via additional services 279 (e.g., 3-way calling, etc.) Separating accounting information makes 280 it possible to charge different parties for different aspects of the 281 session. 283 2.4.2 Accounting Information Related to Session Progression 285 There MUST be support in the SIP-AAA interface for accounting 286 transfers where the information contained in the accounting data has 287 a direct bearing on the establishment, progression and termination of 288 a session. 290 2.4.3 Accounting Information Not Related to Session Progression 292 There MUST be support in the SIP-AAA interface for accounting 293 transfers where the information contained in the accounting data does 294 NOT have a direct bearing on the establishment, progression and 295 termination of a session. 297 2.4.4 Support for One-Time and Session-based Accounting Records 299 The SIP-AAA interface MUST allow SIP servers to provide relevant 300 accounting information for billing and inter-network settlement 301 purpose to the AAA servers. Both one-time event accounting records 302 and session based (START, INTERIM, STOP records) accounting MUST be 303 supported. 305 2.4.5 SIP Session Changes 307 Accounting messages MUST be able to reflect changes in the SIP 308 session that affects the charging of SIP session. 310 2.4.6 Support for Accounting on Different Media Components 312 The SIP-AAA interface MUST support accounting per media component 313 (e.g., voice and video). The SIP-AAA interface MUST enable different 314 parties to be charged per media component. 316 2.4.7 Support for Stateful and Stateless Accounting 318 Stateful and stateless accounting (also referred to as cumulative and 319 non-cumulative accounting) MUST be supported by the SIP-AAA 320 interface. 322 2.4.8 Configuration of Accounting Generation Parameters 324 The SIP-AAA interface MUST allow AAA servers to communicate 325 parameters for accounting generation. 327 2.4.9 Support for Arbitrary Correlation IDs 328 Some networks need to be able to relate the accounting to some aspect 329 of the session. Therefore, the SIP-AAA interface MUST support 330 arbitrary correlation IDs. 332 2.4.10 Support for Real-time and Non-Realtime Accounting 334 Real-time and Non-Realtime Accounting MUST be supported by the SIP- 335 AAA Interface. Real-time accounting allows implementing credit-based 336 charging, where an application checks the end user's account for 337 coverage for the requested service event charge prior to execution of 338 that service event (authorization). 340 2.4.11 Flexible Interface 342 The scheme supported for the accounting between the SIP servers and 343 the AAA infrastructure MUST be flexible enough to accommodate a 344 variety of accounting mechanisms. 346 3 Scenarios 348 This section outlines some possible scenarios for SIP and AAA 349 interaction. These are purely illustrative examples, and do not 350 impose any requirements. 352 Figure 1 shows the typical call flow between a SIP proxy that 353 communicates to a AAA server that performs authentication and 354 authorization. All the examples are based on this flow. 356 SIP SIP AAA 357 UAC Proxy Server 359 | | | 360 |---METHOD---->| | 361 | |--Is it OK?-->| 362 | | | 363 | |<-----OK------| 364 | | | 365 | | | 367 Figure 1: Call flow over the SIP-AAA interface 368 The SIP proxy receives a request with certain credentials. The SIP 369 UAC that generated the request may have included the credentials 370 after having been challenged by the proxy using a 407 (Proxy 371 Authentication Required) response. The SIP proxy sends a request to 372 the AAA server asking if it is OK to provide a particular service for 373 this request. The service may be simply routing forward the request 374 or may consist of a more complex service. The AAA server checks that 375 the credentials are correct (authentication), and checks the user 376 profile. The user profile indicates that it is OK to provide the 377 service, and responds to the SIP proxy. The SIP proxy provides the 378 service requested by the SIP UAC. 380 3.1 WLAN Roaming Using Third Party Service Providers 382 User A wants to establish a voice session over the Internet with user 383 B. User A wants its SIP signalling to be routed through SIP proxy C, 384 because it provides a call log service (i.e., SIP proxy C sends an 385 email to user A once a month with the duration of all the calls made 386 during the month.) 388 SIP AAA 389 User A Proxy C Server User B 391 | | | | 392 |----INVITE----->| | | 393 | | | | 394 |<-----407-------| | | 395 | | | | 396 |------ACK------>| | | 397 | | | | 398 |----INVITE----->| | | 399 | |---Is this OK?-->| | 400 | | | | 401 | |<------OK--------| | 402 | | | | 403 | |---------INVITE------------------>| 404 | | | | 405 | |-Accounting msg->| | 406 | | | | 408 Figure 2: WLAN roaming user 409 User A accesses the Internet using a WLAN access outside his home 410 domain. User A, user B, SIP proxy C and the home AAA server of user A 411 are all in different domains. 413 SIP proxy C challenges the initial INVITE from user A with a 407 414 (Proxy Authentication Required) response, and user A reissues the 415 INVITE including his credentials. SIP proxy C consults user's A home 416 AAA server, which confirms that the credentials belong to user A and 417 that SIP proxy C can go ahead and provide its service for that call. 418 SIP proxy C routes the INVITE forward towards user B and sends an 419 accounting message to the AAA server, which will be used later to 420 charge user A for the service provided by SIP proxy C. 422 3.2 Simple 3GPP Example 424 User A is not in his home domain, but it still uses SIP proxy C, 425 which is in user's A home domain, as the outbound proxy for an 426 INVITE. SIP proxy C consults the home AAA server, which indicates 427 that requests from user A have to be routed through SIP proxy D. SIP 428 proxy C uses SIP loose routing so that the INVITE traverses D before 429 reaching its destination. SIP proxy D will provide call log service 430 for user A. 432 SIP AAA SIP 433 User A Proxy C Server Proxy D 435 | | | | 436 |----INVITE----->| | | 437 | | | | 438 |<-----407-------| | | 439 | | | | 440 |------ACK------>| | | 441 | | | | 442 |----INVITE----->| | | 443 | |------Is this OK?---->| | 444 | | | | 445 | |<-OK if routed thru D-| | 446 | | | | 447 | |---------INVITE------------------>| 448 | | | | 450 Figure 3: 3GPP example 451 The example in figure 3 illustrates roughly how a SIP based 3GPP 452 network works. 454 4 Security Considerations 456 This document is informational in nature, so it does not directly 457 affect the security of the Internet. However, security is a basic 458 requirement of this work. 460 5 Acknowledgements 462 The authors would like to thank the participants of the SIP interim 463 meeting, May 2002 for their comments. The authors would also thank 464 Harri Hakala, Mary Barns, Pete McCann and Henry Sinnreich for their 465 comments. 467 The authors would like to thank the authors of the "AAA Requirements 468 for IP Telephony/Multimedia" draft, which some of the information in 469 this document is based on. 471 6 Authors' Addresses 473 John Loughney 474 Nokia Research Center 475 It�merenkatu 11-13 476 00180 Helsinki 477 Finland 478 electronic mail: john.Loughney@nokia.com 480 Gonzalo Camarillo 481 Ericsson 482 Advanced Signalling Research Lab. 483 FIN-02420 Jorvas 484 Finland 485 electronic mail: Gonzalo.Camarillo@ericsson.com 487 7 Normative References 489 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 490 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 491 initiation protocol," RFC 3261, Internet Engineering Task Force, June 492 2002. 494 [2] S. Bradner, "Key words for use in rfcs to indicate requirement 495 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 497 8 Informative References 499 [3] P. Calhoun et al. , "AAA problem statements," internet draft, 500 Internet Engineering Task Force, Nov. 2000. Work in progress. 502 [4] S. Glass, T. Hiller, S. Jacobs, and C. E. Perkins, "Mobile IP 503 authentication, authorization, and accounting requirements," RFC 504 2977, Internet Engineering Task Force, Oct. 2000. 506 The IETF takes no position regarding the validity or scope of any 507 intellectual property or other rights that might be claimed to 508 pertain to the implementation or use of the technology described in 509 this document or the extent to which any license under such rights 510 might or might not be available; neither does it represent that it 511 has made any effort to identify any such rights. Information on the 512 IETF's procedures with respect to rights in standards-track and 513 standards-related documentation can be found in BCP-11. Copies of 514 claims of rights made available for publication and any assurances of 515 licenses to be made available, or the result of an attempt made to 516 obtain a general license or permission for the use of such 517 proprietary rights by implementors or users of this specification can 518 be obtained from the IETF Secretariat. 520 The IETF invites any interested party to bring to its attention any 521 copyrights, patents or patent applications, or other proprietary 522 rights which may cover technology that may be required to practice 523 this standard. Please address the information to the IETF Executive 524 Director. 526 Full Copyright Statement 528 Copyright (c) The Internet Society (2003). All Rights Reserved. 530 This document and translations of it may be copied and furnished to 531 others, and derivative works that comment on or otherwise explain it 532 or assist in its implementation may be prepared, copied, published 533 and distributed, in whole or in part, without restriction of any 534 kind, provided that the above copyright notice and this paragraph are 535 included on all such copies and derivative works. However, this 536 document itself may not be modified in any way, such as by removing 537 the copyright notice or references to the Internet Society or other 538 Internet organizations, except as needed for the purpose of 539 developing Internet standards in which case the procedures for 540 copyrights defined in the Internet Standards process must be 541 followed, or as required to translate it into languages other than 542 English. 544 The limited permissions granted above are perpetual and will not be 545 revoked by the Internet Society or its successors or assigns. 547 This document and the information contained herein is provided on an 548 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 549 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 550 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 551 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 552 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.