idnits 2.17.1 draft-ietf-sipping-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: ---------------------------------------------------------------------------- ** 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 13 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 507 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 (November 4, 2002) is 7844 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-01.txt 8 November 4, 2002 9 Expires: May 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 Scope of This Document .............................. 4 45 1.2 Terminology ......................................... 4 46 1.3 Requirements Language ............................... 5 47 2 Requirements ........................................ 5 48 2.1 Common Requirements ................................. 5 49 2.1.1 Communication within the same domain ................ 5 50 2.1.2 Communication between different domains ............. 5 51 2.1.3 Discovery ........................................... 5 52 2.1.4 Ability to Integrate Different Networks, Services 53 and Users ........................................... 6 54 2.1.5 Updating SIP Server Entries ......................... 6 55 2.1.6 Call Setup Times .................................... 6 56 2.1.7 Security ............................................ 6 57 2.2 Authentication Requirements ......................... 6 58 2.2.1 Authentication Based on SIP Requests ................ 6 59 2.2.2 Flexible Authentication of SIP requests ............. 6 60 2.3 Authorization Requirements .......................... 7 61 2.3.1 Ability to Authorize SIP Requests ................... 7 62 2.3.2 Information transfer ................................ 7 63 2.3.3 Distribution of Profiles ............................ 7 64 2.3.4 User De-authorization ............................... 7 65 2.4 Accounting Requirements ............................. 7 66 2.4.1 Separation of Accounting Information ................ 8 67 2.4.2 Accounting Information Related to Session 68 Progression ......................................... 8 69 2.4.3 Accounting Information Not Related to Session 70 Progression ......................................... 8 71 2.4.4 Support for One-Time and Session-based Accounting 72 Records ............................................. 8 73 2.4.5 SIP Session Changes ................................. 8 74 2.4.6 Support for Accounting on Different Media 75 Components .......................................... 8 76 2.4.7 Support for Stateful and Stateless Accounting ....... 8 77 2.4.8 Configuration of Accounting Generation Parameters ... 8 78 2.4.9 Support for Arbitrary Correlation IDs ............... 9 79 2.4.10 Support of Credit-based Charging .................... 9 80 2.4.11 Flexible Interface .................................. 9 81 3 Scenarios ........................................... 9 82 3.1 WLAN Roaming Using Third Party Service Providers .... 10 83 3.2 Simple 3GPP Example ................................. 11 84 4 Security Considerations ............................. 12 85 5 Acknowledgements .................................... 12 86 6 Authors' Addresses .................................. 12 87 7 Normative References ................................ 12 88 8 Informative References .............................. 13 90 1 Introduction 92 The AAA working group is chartered to work on authentication, 93 authorization and accounting solutions for the Internet, which 94 consists of a base protocol, applications, end-to-end security 95 application and a general architecture for providing these services 96 [3]. 98 The applicability of AAA-based solutions for a number of protocols 99 have been specified, for example the AAA requirements for Mobile IP 100 [4]. 102 SIP provides a signaling protocol for creating, modifying and 103 terminating different types sessions such as Internet phone calls, 104 multimedia distribution and multimedia conferences [1]. 106 1.1 Scope of This Document 108 SIP sessions have needs for session authentication, authorization and 109 accounting. In order to perform AAA, SIP entities need to access AAA 110 information (e.g., check if the password provided by a user is 111 correct or store accounting records related to a particular session). 112 Rather than collocating a database with AAA information with every 113 SIP entity in a network, it is desirable to have a common logical AAA 114 server accessible by all the SIP entities. SIP entities use a SIP-AAA 115 interface to access this AAA server. This document outlines some 116 requirements on this SIP-AAA interface between SIP entities and AAA 117 servers. This document is intended as a generic document for SIP AAA 118 requirements. It does not intend to develop a charging and/or billing 119 mechanism for SIP. 121 One possible use of this document would be to create a basic AAA 122 application for SIP needs. The protocol used in the SIP-AAA interface 123 could be any protocol that meets the requirements outlined by this 124 document. Possible candidates, among others, are Diameter and XML- 125 based protocols following the web-services model. 127 1.2 Terminology 129 AAA: Authentication, Authorization and Accounting 131 Accounting: In this draft, accounting is meant in a broad sense, 132 not simply charging or billing. 134 Home AAA Server: Server where user with which the user maintains 135 an account relationship. 137 Online Accounting: Downloading some kind of credit into the 138 access device, and deducting from that credit as usage 139 accumulates. 141 Offline Accounting: Transferring records to a home accounting 142 server, for later billing and settlement, without doing any 143 accounting-related control or feedback for the services 144 rendered. 146 SIP: Session Initiation Protocol 148 UAC: User Agent Client 150 UAS: User Agent Server 152 Proxies: Proxies are nodes which forward requests and responses 153 as well as make policy decisions. 155 1.3 Requirements Language 157 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 158 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 159 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]. 161 2 Requirements 163 In this section, we list the requirements. It is assumed that 164 different situations, deployment scenarios will affect which 165 requirements are needed. It is not intended that all requirements 166 need to be supported. Section 2.1 lists general requirements, section 167 2.2 lists requirements related to authentication, section 2.3 lists 168 requirements related to authorization and section 2.4 lists 169 requirements related to accounting. 171 2.1 Common Requirements 173 This section outlines general requirements on the SIP-AAA interface. 175 2.1.1 Communication within the same domain 177 The SIP-AAA interface MUST support communications between a SIP 178 entity and a AAA server that belong to the same domain. 180 2.1.2 Communication between different domains 182 The SIP-AAA interface MUST support communications between a SIP 183 entity in one domain and a AAA server in another domain. 185 2.1.3 Discovery 186 With the information contained in the SIP messages, the SIP-AAA 187 interface MUST be able to deduct the particular AAA server that has 188 to be queried. 190 2.1.4 Ability to Integrate Different Networks, Services and Users 192 The basic AAA architecture MUST be access independent. Service 193 providers have to be able to provide AAA services for SIP, 194 irrespective of access method or technology. 196 2.1.5 Updating SIP Server Entries 198 When required, the SIP-AAA interface MUST allow the AAA server to 199 update the information about a user that a SIP entity has. 201 2.1.6 Call Setup Times 203 AAA SHOULD not unduly burden call setup times where appropriate. It 204 may be reasonable to support some delay during registration, but 205 delay during sessions (especially real-time) are problematic. 207 2.1.7 Security 209 AAA data MUST be able to be securely transported. The endpoints MUST 210 be authenticated before data is sent. The endpoints MAY be authorized 211 to access certain types of AAA data. 213 2.2 Authentication Requirements 215 This section outlines requirements on the SIP-AAA interface related 216 to authentication. 218 2.2.1 Authentication Based on SIP Requests 220 The home AAA server MUST be able to authenticate a user based on any 221 SIP request, except CANCEL. 223 CANCEL is a hop-by-hop request that can be generated by 224 proxies that do not have the user's credentials. 226 2.2.2 Flexible Authentication of SIP requests 228 The scheme supported for the authentication between the SIP servers 229 and the AAA infrastructure MUST be flexible enough to accommodate a 230 variety of authentication mechanisms. In particular, the SIP-AAA 231 interface MUST be able to accommodate all the authentication 232 mechanisms mandated by the SIP specs. 234 2.3 Authorization Requirements 236 This section outlines requirements on the SIP-AAA interface related 237 to authorization. 239 2.3.1 Ability to Authorize SIP Requests 241 The SIP-AAA interface MUST allow AAA servers to authorize any SIP 242 request, except CANCEL. 244 CANCEL is a hop-by-hop request that can be generated by 245 proxies. SIP servers receiving a CANCEL do not challenge 246 it, as they would do with an end-to-end request. Instead, 247 they check that the entity sending the CANCEL is the same 248 as the one that generated the request being canceled. 250 2.3.2 Information transfer 252 The SIP-AAA interface MUST allow transfering a wide range or set of 253 information to be used to make an authorization decision. 255 2.3.3 Distribution of Profiles 257 The SIP-AAA interface MUST allow a AAA server that is making an 258 authorization decision to deliver the user profile to the SIP entity. 259 Note that the user profile may provide further information about the 260 authorization decision to the SIP entity. For instance, a SIP proxy 261 receives an INVITE from user A addressed to user B. The SIP proxy 262 queries a AAA server and gets the following answer: user A is 263 authorized to call user B as long as the requests are routed through 264 a particular SIP proxy server C. In this case, the SIP proxy needs to 265 use SIP loose routing techniques to forward the INVITE so that it 266 traverses SIP proxy C before reaching user B. 268 2.3.4 User De-authorization 270 The SIP-AAA interface MUST allow the AAA server to inform a SIP 271 entity when a particular user is no longer authorized to perform a 272 particular task, even if it is an ongoing task. 274 2.4 Accounting Requirements 276 This section outlines requirements on the SIP-AAA interface related 277 to accounting. Accounting is more than simple charging. Accounting 278 may be a simple list of services accessed, servers accessed, duration 279 of session, etc. Charging for SIP sessions can be extremely complex 280 and requires some additional study. It is not the intent of this 281 section to focus on charging. 283 2.4.1 Separation of Accounting Information 285 AAA accounting messages MUST be able to separate "session duration" 286 information from other information generated via additional services 287 (e.g., 3-way calling, etc.) 289 2.4.2 Accounting Information Related to Session Progression 291 There MUST be support in the SIP-AAA interface for accounting 292 transfers where the information contained in the accounting data has 293 a direct bearing on the establishment, progression and termination of 294 a session. 296 2.4.3 Accounting Information Not Related to Session Progression 298 There MUST be support in the SIP-AAA interface for accounting 299 transfers where the information contained in the accounting data does 300 NOT have a direct bearing on the establishment, progression and 301 termination of a session. 303 2.4.4 Support for One-Time and Session-based Accounting Records 305 The SIP-AAA interface MUST allow SIP servers to provide relevant 306 accounting information for billing and inter-network settlement 307 purpose to the AAA servers. Both one-time event accounting records 308 and session based (START, INTERIM, STOP records) accounting MUST be 309 supported. 311 2.4.5 SIP Session Changes 313 Accounting messages MUST be able to reflect changes in the SIP 314 session that affects the charging of SIP session. 316 2.4.6 Support for Accounting on Different Media Components 318 The SIP-AAA interface MUST support accounting per media component 319 (e.g., voice and video). The SIP-AAA interface MUST enable different 320 parties to be charged per media component. 322 2.4.7 Support for Stateful and Stateless Accounting 324 Stateful and stateless accounting MUST be supported by the SIP-AAA 325 interface. 327 2.4.8 Configuration of Accounting Generation Parameters 328 The SIP-AAA interface MUST allow AAA servers to communicate 329 parameters for accounting generation. 331 2.4.9 Support for Arbitrary Correlation IDs 333 Some networks need to be able to relate the accounting to some aspect 334 of the session. Therefore, the SIP-AAA interface MUST support 335 arbitrary correlation IDs. 337 2.4.10 Support of Credit-based Charging 339 The SIP-AAA interface MUST support credit-based charging. The 340 accounting application has to be able to check the end user's account 341 for coverage for the requested service event charge prior to 342 execution of that service event. All the chargeable events related to 343 a specific account need to be prevented from the end user when the 344 credit of that account is exhausted or expired. 346 2.4.11 Flexible Interface 348 The scheme supported for the accounting between the SIP servers and 349 the AAA infrastructure MUST be flexible enough to accommodate a 350 variety of accounting mechanisms. 352 3 Scenarios 354 This section outlines some possible scenarios for SIP and AAA 355 interaction. These are purely illustrative examples, and do not 356 impose any requirements. 358 Figure 1 shows the typical call flow between a SIP proxy that 359 communicates to a AAA server that performs authentication and 360 authorization. All the examples are based on this flow. 362 SIP SIP AAA 363 UAC Proxy Server 365 | | | 366 |---METHOD---->| | 367 | |--Is it OK?-->| 368 | | | 369 | |<-----OK------| 370 | | | 371 | | | 373 Figure 1: Call flow over the SIP-AAA interface 375 The SIP proxy receives a request with certain credentials. The SIP 376 UAC that generated the request may have included the credentials 377 after having been challenged by the proxy using a 407 (Proxy 378 Authentication Required) response. The SIP proxy sends a request to 379 the AAA server asking if it is OK to provide a particular service for 380 this request. The service may be simply routing forward the request 381 or may consist of a more complex service. The AAA server checks that 382 the credentials are correct (authentication), and checks the user 383 profile. The user profile indicates that it is OK to provide the 384 service, and responds to the SIP proxy. The SIP proxy provides the 385 service requested by the SIP UAC. 387 3.1 WLAN Roaming Using Third Party Service Providers 389 User A wants to establish a voice session over the Internet with user 390 B. User A wants its SIP signalling to be routed through SIP proxy C, 391 because it provides a call log service (i.e., SIP proxy C sends an 392 email to user A once a month with the duration of all the calls made 393 during the month.) 395 SIP AAA 396 User A Proxy C Server User B 398 | | | | 399 |----INVITE----->| | | 400 | | | | 401 |<-----407-------| | | 402 | | | | 403 |------ACK------>| | | 404 | | | | 405 |----INVITE----->| | | 406 | |---Is this OK?-->| | 407 | | | | 408 | |<------OK--------| | 409 | | | | 410 | |---------INVITE------------------>| 411 | | | | 412 | |-Accounting msg->| | 413 | | | | 415 Figure 2: WLAN roaming user 417 User A accesses the Internet using a WLAN access outside his home 418 domain. User A, user B, SIP proxy C and the home AAA server of user A 419 are all in different domains. 421 SIP proxy C challenges the initial INVITE from user A with a 407 422 (Proxy Authentication Required) response, and user A reissues the 423 INVITE including his credentials. SIP proxy C consults user's A home 424 AAA server, which confirms that the credentials belong to user A and 425 that SIP proxy C can go ahead and provide its service for that call. 426 SIP proxy C routes the INVITE forward towards user B and sends an 427 accounting message to the AAA server, which will be used later to 428 charge user A for the service provided by SIP proxy C. 430 3.2 Simple 3GPP Example 432 User A is not in his home domain, but it still uses SIP proxy C, 433 which is in user's A home domain, as the outbound proxy for an 434 INVITE. SIP proxy C consults the home AAA server, which indicates 435 that requests from user A have to be routed through SIP proxy D. SIP 436 proxy C uses SIP loose routing so that the INVITE traverses D before 437 reaching its destination. SIP proxy D will provide call log service 438 for user A. 440 SIP AAA SIP 441 User A Proxy C Server Proxy D 443 | | | | 444 |----INVITE----->| | | 445 | | | | 446 |<-----407-------| | | 447 | | | | 448 |------ACK------>| | | 449 | | | | 450 |----INVITE----->| | | 451 | |------Is this OK?---->| | 452 | | | | 453 | |<-OK if routed thru D-| | 454 | | | | 455 | |---------INVITE------------------>| 456 | | | | 458 Figure 3: 3GPP example 460 The example in figure 3 illustrates roughly how a SIP based 3GPP 461 network works. 463 4 Security Considerations 465 This document is informational in nature, so it does not directly 466 affect the security of the Internet. However, security is a basic 467 requirement of this work. 469 5 Acknowledgements 471 The authors would like to thank the participants of the SIP interim 472 meeting, May 2002 for their comments. The authors would also thank 473 Mary Barns, Pete McCann and Henry Sinnreich for their comments. 475 The authors would like to thank the authors of the "AAA Requirements 476 for IP Telephony/Multimedia" draft, which some of the information in 477 this document is based on. 479 6 Authors' Addresses 481 John Loughney 482 Nokia Research Center 483 It�merenkatu 11-13 484 00180 Helsinki 485 Finland 486 electronic mail: john.Loughney@nokia.com 488 Gonzalo Camarillo 489 Ericsson 490 Advanced Signalling Research Lab. 491 FIN-02420 Jorvas 492 Finland 493 electronic mail: Gonzalo.Camarillo@ericsson.com 495 7 Normative References 497 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 498 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 499 initiation protocol," RFC 3261, Internet Engineering Task Force, June 500 2002. 502 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 503 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 505 8 Informative References 507 [3] P. Calhoun et al. , "AAA problem statements," Internet Draft, 508 Internet Engineering Task Force, Nov. 2000. Work in progress. 510 [4] S. Glass, T. Hiller, S. Jacobs, and C. Perkins, "Mobile IP 511 authentication, authorization, and accounting requirements," RFC 512 2977, Internet Engineering Task Force, Oct. 2000. 514 Full Copyright Statement 516 Copyright (c) The Internet Society (2002). All Rights Reserved. 518 This document and translations of it may be copied and furnished to 519 others, and derivative works that comment on or otherwise explain it 520 or assist in its implementation may be prepared, copied, published 521 and distributed, in whole or in part, without restriction of any 522 kind, provided that the above copyright notice and this paragraph are 523 included on all such copies and derivative works. However, this 524 document itself may not be modified in any way, such as by removing 525 the copyright notice or references to the Internet Society or other 526 Internet organizations, except as needed for the purpose of 527 developing Internet standards in which case the procedures for 528 copyrights defined in the Internet Standards process must be 529 followed, or as required to translate it into languages other than 530 English. 532 The limited permissions granted above are perpetual and will not be 533 revoked by the Internet Society or its successors or assigns. 535 This document and the information contained herein is provided on an 536 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 537 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 538 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 539 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 540 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.