idnits 2.17.1 draft-ietf-sipping-aaa-req-03.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. == 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 541 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 on-going 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 (May 26, 2003) is 7641 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 (~~), 5 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-03.txt 8 May 26, 2003 9 Expires: November, 2003 11 Authentication, Authorization and Accounting 12 Requirements 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 ........................................... 6 53 2.1.5 Updating SIP Server Entries ......................... 6 54 2.1.6 SIP Session Changes ................................. 6 55 2.1.7 Reliable Transfer of Protocol Messages .............. 6 56 2.1.8 Call Setup Times .................................... 6 57 2.1.9 Security ............................................ 6 58 2.2 Authentication Requirements ......................... 6 59 2.2.1 Authentication Based on SIP Requests ................ 6 60 2.2.2 Flexible Authentication of SIP Requests ............. 7 61 2.2.3 Authentication between SIP Entities and AAA 62 Servers ............................................. 7 63 2.3 Authorization Requirements .......................... 7 64 2.3.1 Ability to Authorize SIP Requests ................... 7 65 2.3.2 Information Transfer ................................ 7 66 2.3.3 User De-authorization ............................... 8 67 2.3.4 User Re-authorization ............................... 8 68 2.4 Accounting Requirements ............................. 8 69 2.4.1 Separation of Accounting Information ................ 8 70 2.4.2 Accounting Information Related to Session 71 Progression ......................................... 9 72 2.4.3 Accounting Information Not Related to Session 73 Progression ......................................... 9 74 2.4.4 Support for One-Time and Session-based Accounting 75 Records ............................................. 9 76 2.4.5 Support for Accounting on Different Media 77 Components .......................................... 9 78 2.4.6 Configuration of Accounting Generation Parameters ... 9 79 2.4.7 Support for Arbitrary Correlation IDs ............... 9 80 2.4.8 Support of Accounting with Credit Control ........... 9 81 2.4.9 Flexible Interface .................................. 10 82 3 Scenarios ........................................... 10 83 3.1 WLAN Roaming Using Third Party Service Providers .... 11 84 3.2 Conditional Authorization ........................... 12 85 4 Security Considerations ............................. 12 86 5 Acknowledgements .................................... 12 87 6 Authors' Addresses .................................. 13 88 7 Normative References ................................ 13 89 8 Informative References .............................. 13 91 1 Introduction 93 The AAA working group is chartered to work on authentication, 94 authorization and accounting solutions for the Internet. This work 95 consists of a base protocol, applications, end-to-end security 96 application and a general architecture for providing these services 97 [3]. The AAA working group has specified applicability of AAA-based 98 solutions for a number of protocols (e.g., AAA requirements for 99 Mobile IP [4]). 101 SIP is a signalling protocol for creating, modifying and terminating 102 different types sessions such as Internet phone calls, multimedia 103 distribution and multimedia conferences [1]. SIP sessions have needs 104 for session authentication, authorization and accounting. In order to 105 perform AAA, SIP entities need to access AAA information (e.g., check 106 if the password provided by a user is correct or store accounting 107 records related to a particular session). Rather than collocating a 108 database with AAA information with every SIP entity in a network, it 109 is desirable to have a common logical AAA server accessible by all 110 the SIP entities. SIP entities use a SIP-AAA interface to access this 111 AAA server. This document outlines some requirements on this SIP-AAA 112 interface between SIP entities and AAA servers. This document is 113 intended as a generic document for SIP AAA requirements. It does not 114 intend to develop a charging and/or billing mechanism for SIP. 116 One possible use of this document would be to create a basic AAA 117 application for SIP needs. The protocol used in the SIP-AAA interface 118 could be any protocol that meets the requirements outlined by this 119 document. Possible candidates, among others, are Diameter and XML- 120 based protocols following the web-services model. 122 1.1 Terminology and Acronyms 124 AAA: Authentication, Authorization and Accounting 126 Accounting: The collection of resource consumption data for the 127 purposes of capacity and trend analysis, cost allocation, 128 auditing, and billing. Accounting management requires that 129 resource consumption be measured, rated, assigned, and 130 communicated between appropriate parties [5]. 132 Accounting with credit control: The application checks the end 133 user's account for coverage for the requested service event 134 charge prior to execution of that service event. 136 Home AAA Server: Server where user with which the user maintains 137 an account relationship. 139 SIP: Session Initiation Protocol 141 SIP proxies: SIP proxies are nodes which forward SIP requests 142 and responses as well as make policy decisions. 144 UAC: User Agent Client 146 UAS: User Agent Server 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. Protocol solutions are not 157 required to fulfill requirements for services that they do not 158 support. For example, a solution that provides authentication 159 services but not accounting services does not need to fulfill the 160 accounting requirements. It is expected that solutions do fulfill the 161 general requirements plus the requirements for the specific services 162 they are providing. 164 Section 2.1 lists general requirements, Section 2.2 lists 165 requirements related to authentication, Section 2.3 lists 166 requirements related to authorization and Section 2.4 lists 167 requirements related to accounting. 169 2.1 Common Requirements 171 This section outlines general requirements on the SIP-AAA interface. 173 2.1.1 Communication within the Same Domain 175 The SIP-AAA interface MUST support communications between a SIP 176 entity and a AAA server that belong to the same domain. 178 2.1.2 Communication between Different Domains 180 The SIP-AAA interface MUST support communications between a SIP 181 entity in one domain and a AAA server in another domain. 183 2.1.3 Discovery 185 With the information contained in the SIP messages, the SIP-AAA 186 interface MUST be able to deduce the particular AAA server that has 187 to be queried. 189 2.1.4 Ability to Integrate Different Networks, Services and Users 191 The basic AAA architecture MUST be access independent. Service 192 providers have to be able to provide AAA services for SIP, 193 irrespective of access method or technology. 195 2.1.5 Updating SIP Server Entries 197 When required, the SIP-AAA interface MUST allow the AAA server to 198 update the information that a SIP entity has about a user. 200 2.1.6 SIP Session Changes 202 The SIP-AAA interface MUST allow a SIP entity to inform the AAA 203 server about changes in the SIP session that may affect the 204 authorization, authentication or accounting for that SIP session. 206 2.1.7 Reliable Transfer of Protocol Messages 208 The SIP-AAA interface MUST provide a reliable transfer of AAA 209 protocol messages between the SIP entity and the AAA server. 211 2.1.8 Call Setup Times 213 AAA SHOULD not unduly burden call setup times where appropriate. It 214 may be reasonable to support some delay during registration, but 215 delay during on-going sessions (especially real-time) are 216 problematic. 218 2.1.9 Security 220 AAA data MUST be able to be securely transported. The endpoints MUST 221 be authenticated before data is sent. The endpoints MAY be authorized 222 to access certain types of AAA data. 224 2.2 Authentication Requirements 226 This section outlines requirements on the SIP-AAA interface related 227 to authentication. 229 2.2.1 Authentication Based on SIP Requests 231 The home AAA server MUST be able to authenticate a user based on any 232 SIP request, except CANCELs and ACKs for non-2xx final responses. 234 CANCELs and ACKs for non-2xx final response are hop-by-hop 235 requests that can be generated by proxies that do not have 236 the user's credentials. 238 2.2.2 Flexible Authentication of SIP Requests 240 The SIP-AAA interface MUST be flexible enough to accommodate a 241 variety of authentication mechanisms used to authenticate SIP 242 requests. In particular, the SIP-AAA interface MUST be able to 243 accommodate all the authentication mechanisms mandated by the SIP 244 specs. 246 2.2.3 Authentication between SIP Entities and AAA Servers 248 The scheme supported for the authentication between the SIP servers 249 and the AAA infrastructure MUST be flexible enough to accommodate a 250 variety of authentication mechanisms. 252 2.3 Authorization Requirements 254 This section outlines requirements on the SIP-AAA interface related 255 to authorization. 257 2.3.1 Ability to Authorize SIP Requests 259 The SIP-AAA interface MUST allow AAA servers to authorize any SIP 260 request, except CANCELs and ACKs for non-2xx final responses. 262 CANCELs and ACKs for non-2xx final responses are hop-by-hop 263 requests that can be generated by proxies. SIP servers 264 receiving a CANCEL or a ACK for a non-2xx final response do 265 not challenge them, as they would do with an end-to-end 266 request. Instead, they check at the transport or network 267 layer that the entity sending the CANCEL or the ACK is the 268 same as the one that generated the request being canceled 269 or acked. 271 2.3.2 Information Transfer 273 The SIP-AAA interface MUST allow transfering a wide range or set of 274 information to be used to make an authorization decision. In 275 particular, the SIP-AAA interface MUST allow a AAA server that is 276 making an authorization decision to deliver the user profile to the 277 SIP entity. Such a user profile may provide further information about 278 the authorization decision to the SIP entity. 280 For instance, a SIP proxy receives an INVITE from user A addressed to 281 user B. The SIP proxy queries a AAA server and gets the following 282 answer: user A is authorized to call user B as long as the requests 283 are routed through a particular SIP proxy server C. In this case, the 284 SIP proxy needs to use SIP loose routing techniques to forward the 285 INVITE so that it traverses SIP proxy C before reaching user B. 287 2.3.3 User De-authorization 289 The SIP-AAA interface MUST allow the AAA server to inform a SIP 290 entity when a particular user is no longer authorized to perform a 291 particular task, even if it is an ongoing task. 293 2.3.4 User Re-authorization 295 The SIP-AAA interface MUST allow the AAA server to inform a SIP 296 entity that a particular authorization has been refreshed, and 297 therefore, the user is still authorized to perform a particular task. 299 2.4 Accounting Requirements 301 This section outlines requirements on the SIP-AAA interface related 302 to accounting. Accounting is more than simple charging. Accounting 303 may be a simple list of services accessed, servers accessed, duration 304 of session, etc. Charging for SIP sessions can be extremely complex 305 and requires some additional study. It is not the intent of this 306 section to focus on charging. 308 The information available to be accounted is different at 309 SIP proxies and at SIP UAs. When end-to-end encryption is 310 used, proxies do not have access to some parts of the SIP 311 messages while UAs have access to the whole messages. In 312 addition to this, UAs typically have information about the 313 session itself (e.g., number of audio packets exchanged 314 during an audio session). Therefore, even if the SIP-AAA 315 interface provides a means to transfer a wide range of 316 data, some SIP nodes may not have access to it. In order to 317 design a network, it is important to analyze which SIP 318 nodes will be able to generate the desired account records. 320 2.4.1 Separation of Accounting Information 322 AAA accounting messages MUST be able to provide granular information 323 based on different parameters. 325 For example, it should be possible to separate "session duration" 326 information from other information generated via additional services 327 (e.g., 3-way calling). Separating accounting information makes it 328 possible to provide accounting information to different parties based 329 upon different aspects of the session. 331 2.4.2 Accounting Information Related to Session Progression 333 There MUST be support in the SIP-AAA interface for accounting 334 transfers where the information contained in the accounting data has 335 a direct bearing on the establishment, progression and termination of 336 a session (e.g., reception of a BYE request). 338 2.4.3 Accounting Information Not Related to Session Progression 340 There MUST be support in the SIP-AAA interface for accounting 341 transfers where the information contained in the accounting data does 342 NOT have a direct bearing on the establishment, progression and 343 termination of a session (e.g., an instant MESSAGE that is not 344 related to any session). 346 2.4.4 Support for One-Time and Session-based Accounting Records 348 The SIP-AAA interface MUST allow SIP servers to provide relevant 349 accounting information for billing and inter-network settlement 350 purpose to the AAA servers. Both one-time event accounting records 351 and session based (START, INTERIM, STOP records) accounting MUST be 352 supported. 354 2.4.5 Support for Accounting on Different Media Components 356 The SIP-AAA interface MUST support accounting per media component 357 (e.g., voice and video). The SIP-AAA interface MUST enable different 358 parties to be charged per media component. 360 2.4.6 Configuration of Accounting Generation Parameters 362 The SIP-AAA interface MUST allow AAA servers to communicate 363 parameters for accounting generation. 365 2.4.7 Support for Arbitrary Correlation IDs 367 Some networks need to be able to relate the accounting to some aspect 368 of the session. Therefore, the SIP-AAA interface MUST support 369 arbitrary correlation IDs. 371 2.4.8 Support of Accounting with Credit Control 373 The SIP-AAA interface MUST support accounting with credit control. 374 The accounting application has to be able to check the end user's 375 account for coverage for the requested service event charge prior to 376 execution of that service event. 378 Accounting with credit control is useful to implement prepaid 379 services where all chargeable events related to a specific account 380 are prevented from the end user when the credit of that account is 381 exhausted or expired. 383 2.4.9 Flexible Interface 385 The scheme supported for the accounting between the SIP servers and 386 the AAA infrastructure MUST be flexible enough to accommodate a 387 variety of accounting mechanisms. 389 3 Scenarios 391 This section outlines some possible scenarios for SIP and AAA 392 interaction. These are purely illustrative examples, and do not 393 impose any requirements. 395 Figure 1 shows the typical call flow between a SIP proxy that 396 communicates to a AAA server that performs authentication and 397 authorization. All the examples are based on this flow. 399 SIP SIP AAA 400 UAC Proxy Server 402 | | | 403 |---METHOD---->| | 404 | |--Is it OK?-->| 405 | | | 406 | |<-----OK------| 407 | | | 408 | | | 410 Figure 1: Call flow over the SIP-AAA interface 412 The SIP proxy receives a request with certain credentials. The SIP 413 UAC that generated the request may have included the credentials 414 after having been challenged by the proxy using a 407 (Proxy 415 Authentication Required) response. The SIP proxy sends a request to 416 the AAA server asking if it is OK to provide a particular service for 417 this request. The service may be simply routing forward the request 418 or may consist of a more complex service. The AAA server checks that 419 the credentials are correct (authentication), and checks the user 420 profile. The user profile indicates that it is OK to provide the 421 service, and responds to the SIP proxy. The SIP proxy provides the 422 service requested by the SIP UAC. 424 3.1 WLAN Roaming Using Third Party Service Providers 426 User A wants to establish a voice session over the Internet with user 427 B. User A wants its SIP signalling to be routed through SIP proxy C, 428 because it provides a call log service (i.e., SIP proxy C sends an 429 email to user A once a month with the duration of all the calls made 430 during the month.) 432 SIP AAA 433 User A Proxy C Server User B 435 | | | | 436 |----INVITE----->| | | 437 | | | | 438 |<-----407-------| | | 439 | | | | 440 |------ACK------>| | | 441 | | | | 442 |----INVITE----->| | | 443 | |---Is this OK?-->| | 444 | | | | 445 | |<------OK--------| | 446 | | | | 447 | |---------INVITE------------------>| 448 | | | | 449 | |-Accounting msg->| | 450 | | | | 452 Figure 2: WLAN roaming user 454 User A accesses the Internet using a WLAN access outside his home 455 domain. User A, user B, SIP proxy C and the home AAA server of user A 456 are all in different domains. 458 SIP proxy C challenges the initial INVITE from user A with a 407 459 (Proxy Authentication Required) response, and user A reissues the 460 INVITE including his credentials. SIP proxy C consults user's A home 461 AAA server, which confirms that the credentials belong to user A and 462 that SIP proxy C can go ahead and provide its service for that call. 463 SIP proxy C routes the INVITE forward towards user B and sends an 464 accounting message to the AAA server, which will be used later to 465 charge user A for the service provided by SIP proxy C. 467 3.2 Conditional Authorization 469 User A is not in his home domain, but he still uses SIP proxy C 470 (which is in user's A home domain) as the outbound proxy for an 471 INVITE. SIP proxy C consults the home AAA server, which indicates 472 that requests from user A have to be routed through SIP proxy D. SIP 473 proxy C uses SIP loose routing so that the INVITE traverses D before 474 reaching its destination. SIP proxy D will provide call log service 475 for user A. 477 SIP AAA SIP 478 User A Proxy C Server Proxy D 480 | | | | 481 |----INVITE----->| | | 482 | | | | 483 |<-----407-------| | | 484 | | | | 485 |------ACK------>| | | 486 | | | | 487 |----INVITE----->| | | 488 | |------Is this OK?---->| | 489 | | | | 490 | |<-OK if routed thru D-| | 491 | | | | 492 | |---------INVITE------------------>| 493 | | | | 495 Figure 3: Conditional Authorization 497 4 Security Considerations 499 This document is informational in nature, so it does not directly 500 affect the security of the Internet. However, security is a basic 501 requirement of this work. 503 5 Acknowledgements 504 The authors would like to thank the participants of the SIP interim 505 meeting, May 2002 for their comments. The authors would also thank 506 Harri Hakala, Mary Barns, Pete McCann, Jari Arkko, Aki Niemi, Juha 507 Heinanen and Henry Sinnreich for their comments. 509 The authors would like to thank the authors of the "AAA Requirements 510 for IP Telephony/Multimedia" draft, which some of the information in 511 this document is based on. 513 6 Authors' Addresses 515 John Loughney 516 Nokia 517 Itamerenkatu 11-13 518 00180 Helsinki 519 Finland 520 electronic mail: John.Loughney@nokia.com 522 Gonzalo Camarillo 523 Ericsson 524 Advanced Signalling Research Lab. 525 FIN-02420 Jorvas 526 Finland 527 electronic mail: Gonzalo.Camarillo@ericsson.com 529 7 Normative References 531 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 532 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 533 initiation protocol," RFC 3261, Internet Engineering Task Force, June 534 2002. 536 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 537 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 539 8 Informative References 541 [3] P. Calhoun et al. , "AAA problem statements," internet draft, 542 Internet Engineering Task Force, Nov. 2000. Work in progress. 544 [4] S. Glass, T. Hiller, S. Jacobs, and C. E. Perkins, "Mobile IP 545 authentication, authorization, and accounting requirements," RFC 546 2977, Internet Engineering Task Force, Oct. 2000. 548 [5] B. Aboba, J. Arkko, and D. Harrington, "Introduction to 549 accounting management," RFC 2975, Internet Engineering Task Force, 550 Oct. 2000. 552 The IETF takes no position regarding the validity or scope of any 553 intellectual property or other rights that might be claimed to 554 pertain to the implementation or use of the technology described in 555 this document or the extent to which any license under such rights 556 might or might not be available; neither does it represent that it 557 has made any effort to identify any such rights. Information on the 558 IETF's procedures with respect to rights in standards-track and 559 standards-related documentation can be found in BCP-11. Copies of 560 claims of rights made available for publication and any assurances of 561 licenses to be made available, or the result of an attempt made to 562 obtain a general license or permission for the use of such 563 proprietary rights by implementors or users of this specification can 564 be obtained from the IETF Secretariat. 566 The IETF invites any interested party to bring to its attention any 567 copyrights, patents or patent applications, or other proprietary 568 rights which may cover technology that may be required to practice 569 this standard. Please address the information to the IETF Executive 570 Director. 572 Full Copyright Statement 574 Copyright (c) The Internet Society (2003). All Rights Reserved. 576 This document and translations of it may be copied and furnished to 577 others, and derivative works that comment on or otherwise explain it 578 or assist in its implementation may be prepared, copied, published 579 and distributed, in whole or in part, without restriction of any 580 kind, provided that the above copyright notice and this paragraph are 581 included on all such copies and derivative works. However, this 582 document itself may not be modified in any way, such as by removing 583 the copyright notice or references to the Internet Society or other 584 Internet organizations, except as needed for the purpose of 585 developing Internet standards in which case the procedures for 586 copyrights defined in the Internet Standards process must be 587 followed, or as required to translate it into languages other than 588 English. 590 The limited permissions granted above are perpetual and will not be 591 revoked by the Internet Society or its successors or assigns. 593 This document and the information contained herein is provided on an 594 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 595 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 596 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 597 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 598 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.