idnits 2.17.1 draft-ietf-aaa-diameter-sip-app-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3626. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 79 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' introduction of a new Diameter Subscriber Locator role.' ) 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). == 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: o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA, or ADMINISTRATIVE_DEREGISTRATION the Diameter server MUST clear the SIP server address associated with all SIP AORs indicated in each of the SIP-AOR AVP values included in the Diameter SAR message. The Diameter server considers all of these SIP AORs as not registered. The Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or USER_DEREGISTRATION_STORE_SERVER_NAME, the Diameter server MAY keep the SIP server address associated with the SIP AORs included in the SIP-AOR AVP values of the Diameter SAR message, even though the SIP AORs becomes unregistered. This feature allows a SIP server to request that the Diameter server remain an assigned SIP server for those SIP AORs (SIP-AOR AVP values) allocated to the same user name, and avoid SIP server assignment. The Diameter server MUST consider all these SIP AORs as not registered. If the Diameter server honors the request of the Diameter client (SIP server) to remain as an allocated SIP server, then the Diameter server MUST keep the SIP server assigned to those SIP AORs allocated to the username and MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. Otherwise, when the Diameter server does not honor the request of the Diameter client (SIP server) to remain as an allocated SIP server, the Diameter server MUST clear the SIP server name assigned to those SIP AORs and it MUST set the Result-Code AVP value to DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED in the Diameter SAA message. o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to NO_ASSIGNMENT, the Diameter server SHOULD first verify that the SIP-Server-URI AVP value in the Diameter SAR message is the same URI as the one assigned to the SIP-AOR AVP value. If they differ, then the Diameter server MUST set the Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY in the Diameter SAA message. Otherwise, if the SIP-User-Data-Already-Available AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include the user profile data with the SIP or SIPS URI (SIP-AOR AVP) and all other SIP identities associated with that AVP in the SIP-User-Data AVP value of the Diameter SAA message. On selecting the type of user data, the Diameter server SHOULD take into account the supported formats at the SIP server (SIP-Supported-User-Data-Type AVP in the SAR message) and the local policy. o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there is exactly one SIP-AOR AVP in the Diameter SAR message. If the number of occurrences of the SIP-AOR AVP is not exactly one, the Diameter server MUST set the Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message, and SHOULD not take further actions. If there is exactly one SIP-AOR AVP in the Diameter SAR message, the Diameter server MUST clear the address of the SIP server assigned to the SIP AOR allocated to the user name, and the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. The Diameter server MUST consider the SIP AOR as not registered. -- 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 (April 28, 2006) is 6572 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: 'RFC YYYY' is mentioned on line 3053, but not defined ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 3310 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-09) exists of draft-ietf-radext-digest-auth-08 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group M. Garcia-Martin, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track M. Belinchon 5 Expires: October 30, 2006 M. Pallares-Lopez 6 C. Canales 7 Ericsson 8 K. Tammi 9 Nokia 10 April 28, 2006 12 Diameter Session Initiation Protocol (SIP) Application 13 draft-ietf-aaa-diameter-sip-app-12 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on October 30, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document specifies the Diameter Session Initiation Protocol 47 (SIP) Application. This is a Diameter application that allows a 48 Diameter client to request authentication and authorization 49 information. This application is designed to be used in conjunction 50 with the Session Initiation Protocol (SIP), and provides a Diameter 51 client co-located with a SIP server, with the ability to request the 52 authentication of users and authorization of SIP resources usage from 53 a Diameter server. 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 62 6. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 63 6.1. General Architecture . . . . . . . . . . . . . . . . . . 8 64 6.2. Diameter Server Authenticates the User . . . . . . . . . 10 65 6.3. Delegating Final Authentication Check to the SIP 66 Server . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 6.4. SIP Server Requests Authentication and Authorization . . 16 68 6.5. Locating the Recipient of the SIP Request . . . . . . . . 17 69 6.6. Update of the User Profile . . . . . . . . . . . . . . . 18 70 6.7. SIP Soft State Termination . . . . . . . . . . . . . . . 19 71 6.8. Diameter Server Discovery . . . . . . . . . . . . . . . . 20 72 7. Advertising Application Support . . . . . . . . . . . . . . . 22 73 8. Diameter SIP Application Command Codes . . . . . . . . . . . . 22 74 8.1. User-Authorization-Request (UAR) Command . . . . . . . . 23 75 8.2. User-Authorization-Answer (UAA) Command . . . . . . . . . 24 76 8.3. Server-Assignment-Request (SAR) Command . . . . . . . . . 27 77 8.4. Server-Assignment-Answer (SAA) Command . . . . . . . . . 29 78 8.5. Location-Info-Request (LIR) Command . . . . . . . . . . . 33 79 8.6. Location-Info-Answer (LIA) Command . . . . . . . . . . . 34 80 8.7. Multimedia-Auth-Request (MAR) Command . . . . . . . . . . 36 81 8.8. Multimedia-Auth-Answer (MAA) Command . . . . . . . . . . 37 82 8.9. Registration-Termination-Request (RTR) Command . . . . . 40 83 8.10. Registration-Termination-Answer (RTA) Command . . . . . . 41 84 8.11. Push-Profile-Request (PPR) Command . . . . . . . . . . . 43 85 8.12. Push-Profile-Answer (PPA) Command . . . . . . . . . . . . 44 86 9. Diameter SIP Application AVPs . . . . . . . . . . . . . . . . 46 87 9.1. SIP-Accounting-Information AVP . . . . . . . . . . . . . 48 88 9.1.1. SIP-Accounting-Server-URI AVP . . . . . . . . . . . . 48 89 9.1.2. SIP-Credit-Control-Server-URI AVP . . . . . . . . . . 48 90 9.2. SIP-Server-URI AVP . . . . . . . . . . . . . . . . . . . 48 91 9.3. SIP-Server-Capabilities AVP . . . . . . . . . . . . . . . 48 92 9.3.1. SIP-Mandatory-Capability AVP . . . . . . . . . . . . . 50 93 9.3.2. SIP-Optional-Capability AVP . . . . . . . . . . . . . 50 94 9.4. SIP-Server-Assignment-Type AVP . . . . . . . . . . . . . 50 95 9.5. SIP-Auth-Data-Item AVP . . . . . . . . . . . . . . . . . 51 96 9.5.1. SIP-Authentication-Scheme AVP . . . . . . . . . . . . 52 97 9.5.2. SIP-Item-Number AVP . . . . . . . . . . . . . . . . . 53 98 9.5.3. SIP-Authenticate AVP . . . . . . . . . . . . . . . . . 53 99 9.5.4. SIP-Authorization AVP . . . . . . . . . . . . . . . . 53 100 9.5.5. SIP-Authentication-Info AVP . . . . . . . . . . . . . 54 101 9.5.6. Digest AVPs . . . . . . . . . . . . . . . . . . . . . 55 102 9.6. SIP-Number-Auth-Items AVP . . . . . . . . . . . . . . . . 57 103 9.7. SIP-Deregistration-Reason AVP . . . . . . . . . . . . . . 57 104 9.7.1. SIP-Reason-Code AVP . . . . . . . . . . . . . . . . . 57 105 9.7.2. SIP-Reason-Info AVP . . . . . . . . . . . . . . . . . 58 106 9.8. SIP-AOR AVP . . . . . . . . . . . . . . . . . . . . . . . 58 107 9.9. SIP-Visited-Network-Id AVP . . . . . . . . . . . . . . . 58 108 9.10. SIP-User-Authorization-Type AVP . . . . . . . . . . . . . 58 109 9.11. SIP-Supported-User-Data-Type AVP . . . . . . . . . . . . 59 110 9.12. SIP-User-Data AVP . . . . . . . . . . . . . . . . . . . . 59 111 9.12.1. SIP-User-Data-Type AVP . . . . . . . . . . . . . . . . 60 112 9.12.2. SIP-User-Data-Contents AVP . . . . . . . . . . . . . . 60 113 9.13. SIP-User-Data-Already-Available AVP . . . . . . . . . . . 60 114 9.14. SIP-Method AVP . . . . . . . . . . . . . . . . . . . . . 61 115 10. New Values for Existing AVPs . . . . . . . . . . . . . . . . . 61 116 10.1. Extension to the Result-Code AVP Values . . . . . . . . . 61 117 10.1.1. Success Result-Code AVP Values . . . . . . . . . . . . 61 118 10.1.2. Transient Failures Result-Code AVP Values . . . . . . 62 119 10.1.3. Permanent Failures Result-Code AVP Values . . . . . . 62 120 11. Authentication Details . . . . . . . . . . . . . . . . . . . . 63 121 12. Migration from RADIUS . . . . . . . . . . . . . . . . . . . . 65 122 12.1. Gateway from RADIUS Client to Diameter Server . . . . . . 65 123 12.2. Gateway from Diameter Client to RADIUS Server . . . . . . 66 124 12.3. Known Limitations . . . . . . . . . . . . . . . . . . . . 66 125 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 126 13.1. Application Identifier . . . . . . . . . . . . . . . . . 67 127 13.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 67 128 13.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 67 129 13.4. Additional Values for the Result-Code AVP Value . . . . . 67 130 13.5. Creation of the SIP-Server-Assignment-Type section in 131 the AAA registry . . . . . . . . . . . . . . . . . . . . 68 132 13.6. Creation of the SIP-Authentication-Scheme section in 133 the AAA registry . . . . . . . . . . . . . . . . . . . . 68 134 13.7. Creation of the SIP-Reason-Code section in the AAA 135 registry . . . . . . . . . . . . . . . . . . . . . . . . 68 136 13.8. Creation of the SIP-User-Authorization-Type section 137 in the AAA registry . . . . . . . . . . . . . . . . . . . 68 138 13.9. Creation of the SIP-User-Data-Already-Available 139 section in the AAA registry . . . . . . . . . . . . . . . 69 140 14. Security Considerations . . . . . . . . . . . . . . . . . . . 69 141 14.1. Final Authentication Check in the Diameter Client/SIP 142 server . . . . . . . . . . . . . . . . . . . . . . . . . 69 143 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 70 144 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 70 145 17. Changes With Respect Previous Versions . . . . . . . . . . . . 70 146 17.1. Changes in draft-ietf-aaa-diameter-sip-app-10.txt 147 from -00.txt . . . . . . . . . . . . . . . . . . . . . . 70 148 17.2. Changes in draft-ietf-aaa-diameter-sip-app-09.txt 149 from -08.txt . . . . . . . . . . . . . . . . . . . . . . 71 150 17.3. Changes in draft-ietf-aaa-diameter-sip-app-08.txt 151 from -07.txt . . . . . . . . . . . . . . . . . . . . . . 71 152 17.4. Changes in draft-ietf-aaa-diameter-sip-app-07.txt 153 from -06.txt . . . . . . . . . . . . . . . . . . . . . . 71 154 17.5. Changes in draft-ietf-aaa-diameter-sip-app-06.txt 155 from -05.txt . . . . . . . . . . . . . . . . . . . . . . 72 156 17.6. Changes in draft-ietf-aaa-diameter-sip-app-05.txt 157 from -04.txt . . . . . . . . . . . . . . . . . . . . . . 72 158 17.7. Changes in draft-ietf-aaa-diameter-sip-app-04.txt 159 from -03.txt . . . . . . . . . . . . . . . . . . . . . . 73 160 17.8. Changes in draft-ietf-aaa-diameter-sip-app-03.txt 161 from -02.txt . . . . . . . . . . . . . . . . . . . . . . 74 162 17.9. Changes in draft-ietf-aaa-diameter-sip-app-02.txt 163 from -01.txt . . . . . . . . . . . . . . . . . . . . . . 74 164 17.10. Changes in draft-ietf-aaa-diameter-sip-app-01.txt 165 from -00.txt . . . . . . . . . . . . . . . . . . . . . . 74 166 17.11. Changes in draft-ietf-aaa-diameter-sip-app-00.txt 167 from draft-belinchon-aaa-diameter-mm-app-01.txt . . . . . 75 168 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 169 18.1. Normative References . . . . . . . . . . . . . . . . . . 76 170 18.2. Informative References . . . . . . . . . . . . . . . . . 76 171 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 172 Intellectual Property and Copyright Statements . . . . . . . . . . 79 174 1. Terminology 176 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 177 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 178 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 179 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 180 levels for compliant implementations. 182 2. Definitions 184 For the purpose of this document, the following terms and definitions 185 apply: 187 Node: an addressable device attached to a computer network that 188 implements SIP functionality, Diameter functionality or a 189 combination of both. 191 For the purpose of this document, the following terms and definitions 192 given in RFC 3261 [RFC3261] Section 6, apply: 194 o Address-of-Record (AOR) 195 o Outbound proxy 196 o Proxy 197 o Server (SIP server) 198 o User Agent (UA) 199 o User Agent Client (UAC) 200 o User Agent Server (UAS) 202 For the purpose of this document, the following terms and definitions 203 given in RFC 3588 [RFC3588] Section 1.3, apply: 205 o Authorization 206 o Authentication 207 o AVP 208 o Diameter Client 209 o Diameter Server 210 o Home Realm 211 o Redirect Agent 212 o User 214 3. Acronyms 215 AKA: Authentication and Key Agreement 216 LIR: Location-Info-Request 217 LIA: Location-Info-Answer 218 MAR: Multimedia-Auth-Request 219 MAA: Multimedia-Auth-Answer 220 PPR: Push-Profile-Request 221 PPA: Push-Profile-Answer 222 RTR: Registration-Termination-Request 223 RTA: Registration-Termination-Answer 224 SAR: Server-Assignment-Request 225 SAA: Server-Assignment-Answer 226 SL: Subscriber Locator 227 UAR: User-Authorization-Request 228 UAA: User-Authorization-Answer 230 4. Introduction 232 This document specifies the Diameter Session Initiation Protocol 233 (SIP) Application. This is a Diameter application that allows a 234 Diameter client to request authentication and authorization 235 information to a Diameter server for SIP-based IP multimedia services 236 (see [RFC3261] about SIP). Further more, this Diameter SIP 237 Application provides the Diameter client with functions that goes 238 beyond the typical authorization and authentication, such as the 239 ability to download or received update user profiles, or rudimentary 240 routing functions that can assist a SIP server in finding another SIP 241 server allocated to the user. 243 We assume that the SIP server (such as SIP proxy server, registrar, 244 redirect server, or alike) and the Diameter client are co-located in 245 the same node, so that the SIP server is able to receive and process 246 SIP requests and responses. In turn, the SIP server relies on the 247 AAA infrastructure for authenticating the SIP request and authorizing 248 the usage of particular SIP services. 250 This document provides Diameter procedures to implement certain 251 required functionality when SIP is the protocol chosen to initiate 252 and tear down multimedia sessions or when SIP is used for other non- 253 session-related applications. However, this document does not 254 mandate any particular mapping of SIP procedures to Diameter SIP 255 application procedures, nor does it mandate any particular sequence 256 of events between SIP and Diameter. This document provides useful 257 examples to show the interaction between SIP and the Diameter SIP 258 application in order to achieve the desired functionality. 260 This application does not require and is not related to other 261 authentication services provided by the Diameter Mobile IPv4 263 [RFC4004] or the Diameter Network Access Server [RFC4005] 264 applications. 266 This Diameter SIP application is loosely related to the Diameter 267 Credit Control Application [RFC4006]. Although both applications are 268 independent, the Diameter SIP application is able to supply the 269 addresses of credit control servers that will be implementing the 270 Diameter Credit Control Application [RFC4006]. 272 Section 5 discusses assumptions and configurations assumed by this 273 document. 275 Section 6 provides the reader with informative descriptions of the 276 Diameter SIP application commands and responses and with some 277 guidance about their linkage with SIP procedures. 279 Advertisement of this application is specified in Section 7. 281 Section 8 provides a normative description of all the new Diameter 282 commands defined by this specification. 284 This application extends the Result-Code Attribute-Value-Pair (AVP) 285 with some new values. Further information is described in 286 Section 10. 288 This application defines some new AVPs. All these AVPs are described 289 in Section 9. 291 Some extra information about authentication is provided in 292 Section 11. 294 5. Applicability Statement 296 This document assumes a general architecture where a Home Realm is 297 composed of one or more nodes implementing Diameter or SIP functions. 298 Users are issuing SIP requests to access SIP resources. For each 299 particular user, the Home Realm needs to authenticate and authorize 300 the usage of those resources and/or the route to the appropriate 301 node. We assume that the database containing the user-related data 302 is located outside the SIP node that requires authorization. Data 303 belonging to different users may be stored in different nodes in the 304 Home Realm, but we assume that all the data related to a particular 305 user is stored in a single node. 307 Central to the architecture is the fact that the user data is 308 stored in a single point in the network. This restriction does 309 not mandate a particular implementation, e.g., it is possible to 310 implement clusters of databases operating in mirror mode to 311 provide redundancy. The property required by this specification 312 is that the user data the Diameter Server has access to is stored 313 safely in what is seen, from the external point of view, as a 314 single user database. 316 This document allows several configurations of the Home Realm. In 317 one configuration, a SIP server (proxy, registrar, etc.) is allocated 318 to a user for the purpose of triggering and executing services. The 319 allocation of the SIP server may be done dynamically, e.g., at the 320 time the user registers in the network. This configuration requires 321 a SIP server, typically located at the edge of the network, that is 322 able to allocate another SIP server for the user and that also 323 supports routing of SIP requests and responses towards that allocated 324 SIP server. Both SIP server nodes implement a Diameter Client. 326 In another configuration, the address of a SIP outbound proxy is 327 configured (by means outside the scope of this specification) into 328 the SIP User Agent. The outbound Diameter Client in the SIP outbound 329 proxy node authenticates the user, requests authorization for SIP 330 requests, and performs accounting activities. 332 6. Overview of Operation 334 This section provides an informative description of how the Diameter 335 SIP application can be used together with SIP. This section is not 336 intended to mandate any specific usage of the Diameter SIP 337 application nor does it mandate a specific mapping between SIP and 338 Diameter messages. We provide a collection of examples that show how 339 the required AAA functionality can be achieved in conjunction with 340 SIP. 342 6.1. General Architecture 344 The Diameter SIP application can be used in a SIP environment where 345 an interface to a AAA infrastructure is required to authenticate and 346 authorize the usage of SIP resources. This application provides 347 support for SIP User Agents and proxies that implement and use HTTP 348 Digest authentication [RFC2617], which is the authentication 349 mechanism mandated by SIP [RFC3261]. The application is extensible 350 and, if need arises, it can be extended to provide support for other 351 authentication mechanisms or extensions to HTTP Digest authentication 352 when they occur. 354 This application provides limited support for accounting services as 355 follows: the Diameter server is able to provide the addresses of 356 accounting severs to the Diameter client. Figure 1, below, shows a 357 general overview of the integration of the SIP architecture with the 358 AAA architecture. 360 According to Figure 1, there are one or more SIP User Agents (UA) 361 that initiate or terminate SIP traffic through one or more SIP 362 servers. Both SIP servers implement a Diameter client that supports 363 the Diameter application described in this specification. 365 +--------+ 366 UAR/UAA +--->|Diameter|<----+ PPR/PPA 367 LIR/LIA | | server | | MAR/MAA 368 | +--------+ | SAR/SAA 369 | | RTR/RTA 370 | | 371 v v 372 +------+ SIP +--------+ SIP +--------+ SIP +------+ 373 | SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP | 374 | UA | |server 1| |server 2| | UA | 375 +------+ +--------+ +--------+ +------+ 376 ^ ^ 377 UAR/UAA | | 378 LIR/LIA | | MAR/MAA 379 | +--------+ | SAR/SAA 380 +--->|Diameter|<----+ 381 | SL | 382 +--------+ 384 Figure 1: Architecture of the Diameter application for SIP 386 In Figure 1, it can be seen that SIP server 1 sends different 387 Diameter commands and receives different responses than those sent 388 and received by SIP server 2. This is because SIP server 1 in 389 Figure 1 is located at the edge of a network, and its main task is to 390 locate SIP server 2. SIP server 2 is requesting and receiving 391 authentication and authorization data from the Diameter server and is 392 not located at the edge of the network. 394 This Diameter application assumes that all the data pertaining to a 395 given user is stored in a single Diameter server. For redundancy 396 purposes, several Diameter servers can be configured in a redundancy 397 fashion, in which case all of them keep the data synchronized and 398 operate externally as a single Diameter server. 400 With respect SIP server 1 in Figure 1, the Diameter SIP application 401 provides support for the existence of a farm of these servers, 402 typically configured through one or more DNS records that point to 403 several hosts (this is a typical configuration in common SIP 404 deployments). There is no requirement for these types of servers to 405 keep state related to the Diameter SIP application. 407 The Diameter SIP application provides support for a feature that 408 allows an administrative domain to provide a collection of SIP 409 servers 2 (as per Figure 1). Once the user registers for the first 410 time, one of these SIP servers is selected and all the SIP requests 411 related to the user are processed by the same SIP server. 413 The Diameter Subscriber Locator (SL) serves the purpose of locating 414 the Diameter server that contains the user-related data. Its 415 functionality is based on the Diameter redirect mechanism and is 416 further described in Section 6.8. 418 It should be noted that this document does not mandate any particular 419 SIP/AAA architecture. However, the Diameter SIP application provides 420 the functionality needed to accommodate all the different 421 architectures where SIP and Diameter are used. 423 The following subsections provide an informative overview of the 424 Diameter SIP application, its commands, and a possible interaction 425 with SIP signaling. 427 6.2. Diameter Server Authenticates the User 429 This is the generic mechanism to authenticate users. In this 430 approach, we show an example of an administrative network where the 431 Diameter server is authenticating SIP user requests. This could be 432 the case of a medium size network where the Diameter server is 433 keeping user records and authenticating SIP requests to perform a 434 certain transaction. We have chosen to show a SIP REGISTER request 435 in the example, but the SIP server could request authentication of 436 any other SIP request. 438 +--------+ +--------+ +--------+ 439 | SIP | |Diameter| | SIP | 440 |server 1| | server | |server 2| 441 +--------+ +--------+ +--------+ 442 | | | 443 1. SIP REGISTER | | | 444 -------------------->| 2. UAR | | 445 |------------------>| | 446 | 3. UAA | | 447 |<------------------| | 448 | 4. SIP REGISTER | 449 |-------------------------------------->| 450 | | 5. MAR | 451 | |<------------------| 452 | | 6. MAA | 453 | |------------------>| 454 | 7. SIP 401 (Unauthorized) | 455 8. SIP 401 (Unauth.) |<--------------------------------------| 456 <--------------------| | | 457 9. SIP REGISTER | | | 458 -------------------->| 10. UAR | | 459 |------------------>| | 460 | 11. UAA | | 461 |<------------------| | 462 | 12. SIP REGISTER | 463 |-------------------------------------->| 464 | | 13. MAR | 465 | |<------------------| 466 | | 14. MAA | 467 | |------------------>| 468 | 15. SIP 200 (OK) | 469 16. SIP 200 (OK) |<--------------------------------------| 470 <--------------------| | | 471 | | 17. SAR | 472 | |<------------------| 473 | | 18. SAA | 474 | |------------------>| 475 | | | 477 Figure 2: Authentication performed in the Diameter server 479 According to Figure 2, a SIP User Agent Client (UAC) sends a SIP 480 REGISTER request (step 1) to SIP server 1, which receives the SIP 481 request. In Figure 2, we assume that this SIP server is located at 482 the edge of the administrative home domain. The Diameter client in 483 SIP server 1 contacts its Diameter server by sending a Diameter User- 484 Authorization-Request (UAR) message (step 2) to determine if this 485 user is allowed to receive service, and if so, request the address of 486 a local SIP server capable of handling this user. The Diameter 487 server answers with a Diameter User-Authorization-Answer (UAA) 488 message (step 3), which indicates a list of capabilities that SIP 489 server 1 may use to select an appropriate SIP server (SIP server 2) 490 and/or a SIP or SIPS URI pointing to SIP server 2. 492 SIP server 1 forwards the SIP REGISTER request (step 4) to an 493 appropriate SIP server (SIP server 2). Then the Diameter client in 494 SIP server 2 requests user authentication from the Diameter server by 495 sending a Diameter Multimedia-Auth-Request (MAR) message (step 5). 496 This request also serves to make the Diameter server aware of the SIP 497 or SIPS URI of SIP server 2, so as to return subsequent requests for 498 the same user to the same SIP server 2. The Diameter server responds 499 with a Diameter Multimedia-Auth-Answer (MAA) message (step 6) with 500 Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH. The 501 Diameter server also generates a nonce and includes a challenge in 502 the MAA message. SIP server 2 uses that challenge to map into the 503 WWW-Authenticate header in the SIP 401 (Unauthorized) response (step 504 7), which is sent back to SIP server 1 and then to the SIP UAC (step 505 8). 507 SIP server 1 receives a next SIP REGISTER request containing the user 508 credentials (step 9). Note that SIP server 1 does not need to keep a 509 state, and even more, there is no guarantee that the SIP request 510 arrives at the same SIP server 1; there could be a farm of SIP 511 servers 1 operating in redundant configuration. The Diameter client 512 in SIP server 1 contacts the Diameter server by sending a Diameter 513 UAR message (step 10) to determine the SIP server allocated to the 514 user. The Diameter server sends the SIP or SIPS URI of SIP server 2 515 in a Diameter UAA message (step 11). 517 Then SIP server 1 forwards the SIP REGISTER request to SIP server 2 518 (step 12). SIP server 2 extracts the credentials from the SIP 519 REGISTER request. The Diameter client in SIP server 2 sends those 520 credentials in a Diameter MAR message (step 13) to the Diameter 521 server. At this point, the Diameter server is able to authenticate 522 the user, and upon success, returns a Diameter MAA message (step 14) 523 with the AVP Result-Code set to the value DIAMETER_SUCCESS. 525 Then SIP server 2 generates a SIP 200 (OK) response (step 15), which 526 is forwarded to SIP server 1 and eventually to the SIP UAC (step 16). 528 If the Diameter client in SIP server 2 is interested in downloading 529 the user profile information or is required to store the address of 530 the SIP server in the Diameter server, then the Diameter client sends 531 a Diameter SAR message (step 17) to the Diameter server. The 532 Diameter server replies with a Diameter SAA message (step 18) that 533 contains the requested user profile information and the 534 acknowledgement of the SIP server address storage. These actions are 535 needed when the SIP server has to retrieve a user profile used to 536 provide services to the served user, or when the SIP server keeps a 537 state for the user, so the Diameter server needs to store the SIP 538 server's address. 540 6.3. Delegating Final Authentication Check to the SIP Server 542 An operator with a large base of installed SIP servers may wish to 543 minimize the number of round-trips between the Diameter client and 544 the Diameter server. We provide support for a mechanism where the 545 Diameter server delegates the final authentication check to the SIP 546 server, thereby saving a round-trip. Section 14.1 discusses the 547 security considerations of this scenario. 549 It must noted that this scenario is not applicable when the Diameter 550 server is configured to use a session MD5 (MD5-sess) algorithm, 551 because the Diameter server requires the client nonce to compute the 552 H(A1) before sending it to the Diameter client. However, the client 553 nonce might not be available at that time. 555 +--------+ +--------+ +--------+ 556 | SIP | |Diameter| | SIP | 557 |server 1| | server | |server 2| 558 +--------+ +--------+ +--------+ 559 | | | 560 1. SIP REGISTER | | | 561 -------------------->| 2. UAR | | 562 |------------------>| | 563 | 3. UAA | | 564 |<------------------| | 565 | 4. SIP REGISTER | 566 |-------------------------------------->| 567 | | 5. MAR | 568 | |<------------------| 569 | | 6. MAA | 570 | |------------------>| 571 | 7. SIP 401 (Unauthorized) | 572 8. SIP 401 (Unauth.) |<--------------------------------------| 573 <--------------------| | | 574 9. SIP REGISTER | | | 575 -------------------->| 10. UAR | | 576 |------------------>| | 577 | 11. UAA | | 578 |<------------------| | 579 | 12. SIP REGISTER | 580 |-------------------------------------->| 581 | | 13. SAR | 582 | |<------------------| 583 | | 14. SAA | 584 | |------------------>| 585 | 15. SIP 200 (OK) | 586 16. SIP 200 (OK) |<--------------------------------------| 587 <--------------------| | | 588 | | | 590 Figure 3: Delegation of authentication to the SIP server 592 Figure 3 shows an example where a SIP server is dynamically allocated 593 to serve a SIP User Agent with the support of the Diameter server. 594 This may be the case of certain architectures, such as that of the 595 3rd Generation Partnership Project (3GPP) IP Core Network Multimedia 596 Subsystem (IMS). 598 A first SIP server receives a SIP REGISTER request (step 1) whose 599 target is the home network domain. In Figure 3, we assume that this 600 SIP server is located at the edge of the administrative home domain. 601 The Diameter client in this SIP server requests authorization from 602 the Diameter server to proceed with the registration, by sending a 603 Diameter User-Authorization-Request (UAR) message (step 2). The 604 message includes, among other Attribute-Value-Pairs (AVPs), the SIP 605 Address-Of-Record (AOR) that is included in the SIP REGISTER request. 606 The Diameter server verifies the SIP AOR and, if it is a valid 607 defined user in the home network, authorizes the registration to 608 proceed. The Diameter server responds with a Diameter User- 609 Authorization-Answer (UAA) message (step 3), which informs the 610 Diameter client/SIP server about the result of the user 611 authorization. In case of a successful authorization, the Diameter 612 UAA message indicates the address of a local SIP server (SIP server 2 613 in Figure 3) and/or a list of capabilities that SIP server 1 may use 614 to select an appropriate SIP server 2. 616 When the authorization is successful, SIP server 1 forwards the SIP 617 REGISTER request (step 4) to the appropriate SIP server (SIP server 618 2). The Diameter client in SIP server 2 requests authentication 619 parameters by sending a Diameter Multimedia-Auth-Request (MAR) 620 message (step 5) to the Diameter server. This request also makes the 621 Diameter server aware of the SIP or SIPS URI of SIP server 2, so as 622 to return subsequent requests of the same user to the same SIP server 623 2. The Diameter server responds with a Diameter Multimedia-Auth- 624 Answer (MAA) message (step 6), which includes a nonce and all the 625 rest of the parameters necessary for the designated authentication 626 algorithm associated with the user. Among others, the MAA message 627 includes a Digest-HA1 AVP that contains H(A1) (as defined in RFC 2617 628 [RFC2617]), and that allows the Diameter client to calculate the 629 expected response. Then the Diameter client can compare this 630 expected response to with the response to the challenge sent from the 631 SIP UA. The absence of the Digest-HA1 AVP in MAA indicates that 632 authentication and authorization takes place in the Diameter server, 633 as per the scenario described in Section 6.2. 635 SIP server 2 creates a SIP 401 (Unauthorized) SIP response (step 7) 636 based on the challenge included in the MAA message, including the 637 authentication material needed by the SIP User Agent Client (UAC) to 638 include the appropriate credentials. SIP server 1 forwards the SIP 639 response to the SIP UAC (step 8). 641 The SIP server 1 receives the next SIP REGISTER request containing 642 the user credentials (step 9). Because SIP server 1 does not need to 643 keep a state (and there is no guarantee that the SIP request arrives 644 to the same SIP server 1), the Diameter client in SIP server 1 645 contacts the Diameter server again by sending a Diameter UAR message 646 (step 10) to determine the SIP server allocated to the user. The 647 Diameter server sends the SIP or SIPS URI of SIP server 2 in a 648 Diameter UAA message (step 11). 650 SIP server 1 forwards the SIP REGISTER request to SIP server 2 (step 651 12). SIP server 2 validates the credentials by comparing the 652 response supplied by the SIP UA with the expected response calculated 653 by the SIP server 2 (based on the H(A1) received from the Diameter 654 server). 656 If the credentials are valid, SIP server 2 sends a Diameter Server- 657 Assignment-Request (SAR) message (step 13) requesting the Diameter 658 server to confirm the completion of the authentication procedure and 659 to confirm the SIP or SIPS URI of the SIP server that is currently 660 serving the user. The Diameter SAR message also serves the purpose 661 of requesting that the Diameter server send the user profile to the 662 SIP server. The Diameter server responds with a Diameter Server- 663 Assignment-Answer (SAA) message (step 14). If the Result-Code AVP 664 value does not inform SIP Server 2 of an error, the SAA message can 665 include zero or more SIP-User-Data AVPs containing the information 666 that SIP server 2 needs in order to provide a service to the user. 668 SIP server 2 generates a SIP 200 (OK) response (step 15), which is 669 forwarded to SIP server 1 and eventually to the SIP UAC (step 16). 671 6.4. SIP Server Requests Authentication and Authorization 673 Figure 4 depicts a typical scenario where a stateless SIP proxy 674 requests authentication information and authorization to a Diameter 675 server, for the purpose of providing SIP routing services to a SIP 676 User Agent. The SIP proxy server may be configured as an outbound 677 SIP proxy, so that all the requests initiated by the SIP UA traverse 678 the SIP proxy. 680 According to Figure 4, a SIP User Agent sends a SIP request to its 681 outbound SIP proxy server. In this case, the message is a SIP INVITE 682 request (see step 1), but it could be any other SIP request. We 683 assume that this SIP request does not contain any credentials at this 684 time. The outbound SIP proxy server needs to authenticate and 685 authorize the proxy services offered to the user. The Diameter 686 client in the SIP server sends a Multimedia-Auth-Request (MAR) 687 message (step 2). The Diameter server generates a nonce and sends a 688 Multimedia-Auth-Answer (MAA) message (step 3) that includes the nonce 689 and the rest of the data necessary for the SIP server to challenge 690 the user, typically with HTTP Digest Authentication indicated in the 691 MAA message. This data enables the SIP server to create a SIP 407 692 (Proxy Authentication Required) response (step 4) that contains a 693 challenge. The SIP UA creates a new INVITE request (step 5) that 694 contains the credentials. The Diameter client in the SIP server 695 sends the credentials to the Diameter server in a new Diameter MAR 696 message (step 6). The Diameter server validates the credentials and 697 authorize the SIP transaction in a Diameter MAA message (step 7). 698 The SIP server forwards the SIP INVITE request to its destination 699 (step 8) as per regular SIP procedures. Eventually, the session 700 setup is confirmed with a SIP 200 (OK) response (step 9) that is 701 forwarded to the SIP UA (step 10). The session setup is complete. 703 +--------+ +--------+ 704 |Diameter| | SIP | 705 | server | | server | 706 +--------+ +--------+ 707 | | 708 | | 709 1. SIP INVITE | 710 ----------------------------------->| 711 | 2. MAR | 712 |<------------------| 713 | 3. MAA | 714 |------------------>| 715 | | 716 4. SIP 407 (Proxy | 717 Authentication Required) | 718 <-----------------------------------| 719 | | 720 5. SIP INVITE | 721 ----------------------------------->| 722 | 6. MAR | 723 |<------------------| 724 | 7. MAA | 725 |------------------>| 8. SIP INVITE 726 | |----------------> 727 | | 9. SIP 200 (OK) 728 10. SIP 200 (OK) |<---------------- 729 <-----------------------------------| 730 | | 732 Figure 4: SIP server requests authorization 734 6.5. Locating the Recipient of the SIP Request 736 Figure 5 shows the scenario where SIP server 1 may be configured as a 737 SIP edge proxy server, processing SIP traffic at the edge of a 738 network. SIP server 1 receives a SIP INVITE request (step 1). SIP 739 server 1 needs to find the address of SIP server 2, which is serving 740 the recipient of the SIP request. The Diameter client in SIP server 741 1 sends a Diameter Location-Info-Request (LIR) message (step 2) to 742 the Diameter server. The Diameter server responds with a Diameter 743 Location-Info-Answer (LIA) message (step 3) that contains the SIP or 744 SIPS URI of SIP server 2. SIP server 1 then forwards the SIP INVITE 745 to SIP server 2 (step 4). SIP server 2 eventually forwards the SIP 746 INVITE to the appropriate UAS (step 5). 748 +--------+ +--------+ +--------+ 749 | SIP | |Diameter| | SIP | 750 |server 1| | server | |server 2| 751 +--------+ +--------+ +--------+ 752 | | | 753 1. SIP INVITE | | | 754 -------------->| 2. LIR | | 755 |---------------->| | 756 | 3. LIA | | 757 |<----------------| | 758 | 4. SIP INVITE | 759 |--------------------------------->| 760 | | | 5. SIP INVITE 761 | | |--------------> 762 | | | 763 | | | 765 Figure 5: Locating the SIP server of the recipient 767 Although the example shows the connection between a SIP INVITE 768 request and the Diameter LIR message, any SIP request other than 769 REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same 770 Diameter message. (A SIP REGISTER request will trigger a Diameter 771 UAR message, as indicated in Figure 2 and Figure 3.) 773 The scenario described in this section is also applicable in case an 774 outbound SIP server is not interested in authenticating the user, but 775 is required to locate a further SIP server to route the outbound SIP 776 requests. In this case, the outbound SIP server is mapped to SIP 777 server 1 as shown in Figure 5. 779 6.6. Update of the User Profile 781 The Diameter SIP application provides a mechanism for a Diameter 782 server to asynchronously download a user profile to a SIP server 783 whenever there is an update of such user profile. It must be noted 784 that the Diameter server also attaches the user profile to the 785 Diameter Server-Assignment-Answer (SAA) message. This is valid for 786 most of the daily situations; however, the administrator may decide 787 to update or modify the user profile for a particular user, due to, 788 e.g., new services made available to the user. This may involve 789 mechanisms outside the scope of this specification, such as human 790 intervention, in the Diameter server. In this situation, the 791 Diameter server is able to push the new user profile into the SIP 792 server allocated to the user. 794 The scenario is illustrated in Figure 6. When the user profile 795 changes, the Diameter server sends a Diameter Push-Profile-Request 796 (PPR) message (step 1) to the Diameter client in the SIP server 797 allocated to that user (SIP server 2 in the examples). The Diameter 798 PPR message contains one or more SIP-User-Data AVPs, a User-Name AVP 799 and zero or more SIP-AOR AVPs. The Diameter client in SIP server 2 800 acknowledges the Diameter PPR message by sending a Diameter Push- 801 Profile-Answer (PPA) message (step 2) to the Diameter server. 803 +--------+ +--------+ 804 |Diameter| | SIP | 805 | server | |server 2| 806 +--------+ +--------+ 807 | | 808 | 1. PPR | 809 |------------------>| 810 | | 811 | 2. PPA | 812 |<------------------| 813 | | 815 Figure 6: Diameter server pushes an update of the user profile 817 6.7. SIP Soft State Termination 819 SIP can create soft states in SIP nodes based on events such as SIP 820 registrations or SIP event subscriptions. These states are 821 periodically refreshed, and cease to exist if they are not refreshed. 822 Additionally, an administrative action can be taken to terminate a 823 SIP soft state, or the SIP UA can explicitly terminate a SIP soft 824 state. 826 The Diameter base protocol offers a mechanism to create and delete 827 states in Diameter nodes. These states are called Diameter user 828 sessions. The Diameter server decides whether to use a Diameter user 829 session as a mechanism to map to a SIP soft state. If the Diameter 830 server decides to use Diameter user sessions, the termination of a 831 Diameter user session implies the termination of the corresponding 832 SIP soft state (e.g., registration, event subscription), and vice 833 versa. If the Diameter server does not use Diameter user sessions, 834 this Diameter SIP application offers specific commands to manage the 835 SIP soft states. Implementations compliant with this specification 836 MUST support both mechanisms of session management. 838 We provide support for both Diameter client- and Diameter server- 839 initiated session termination. 841 Depending on whether Diameter sessions are used, termination of a SIP 842 soft state can be achieved by one of the following methods: 844 o When the Diameter client (SIP proxy) wants to terminate the SIP 845 soft state and Diameter user sessions are not maintained (i.e., 846 the Auth-Session-State AVP has been previously set to 847 NO_STATE_MAINTAINED), the Diameter client MUST send a Server- 848 Assignment-Request (SAR) message with the SIP-Server-Assignment- 849 Type AVP (Section 9.4) set to any of the deregistration values: 850 TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, 851 TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME, 852 USER_DEREGISTRATION_STORE_SERVER_NAME, 853 ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA. 854 o When the Diameter client (SIP proxy) wants to terminate the SIP 855 soft state and Diameter user sessions are maintained (i.e., the 856 Auth-Session-State AVP has been previously set to 857 STATE_MAINTAINED), the Diameter client MUST send a Session- 858 Termination-Request (STR) message as per regular procedures 859 according to RFC 3588 [RFC3588]. 860 o When the Diameter server wants to terminate the SIP soft state and 861 Diameter user sessions are not maintained (i.e., the Auth-Session- 862 State AVP has been previously set to NO_STATE_MAINTAINED), the 863 Diameter server MUST send a Registration-Termination-Request (RTR) 864 message (see Section 8.9). 865 o When the Diameter server wants to terminate the SIP soft state and 866 Diameter user sessions are maintained (i.e., the Auth-Session- 867 State AVP has been previously set to STATE_MAINTAINED), the 868 Diameter server MUST send an Abort-Session-Request (ASR) message 869 as per regular procedures according to RFC 3588 [RFC3588]. 871 6.8. Diameter Server Discovery 873 The basic architecture assumption of this document is that all the 874 data related to a user is stored in a unique Diameter server. 875 Contrary to general opinion, this does not create a single point of 876 failure. It is assumed that Diameter servers is configured in a 877 redundant fashion in an attempt to mitigate the single point of 878 failure problem. 880 In large networks, where the number of users may be significantly 881 high, there might be a need to scale the number of Diameter servers. 882 All the data associated with a user is still stored in one Diameter 883 server (typically operating in a redundant configuration), but the 884 data associated with different users may reside in different Diameter 885 servers. 887 Although this configuration scales well, it introduces a new problem, 888 namely: given the user's SIP AOR as an input, how to determine which 889 of various Diameter servers is storing the data for that particular 890 SIP AOR. We solve this problem with inspiration from the Diameter 891 redirection mechanism specified in RFC 3588 [RFC3588]. We include in 892 the architecture a new Diameter node that, for the purpose of this 893 document, is known as Diameter Subscriber Locator (SL). The Diameter 894 SL contains a database or routing tables that map SIP AORs to 895 Diameter server URIs. A particular Diameter server URI points to the 896 actual Diameter server that stores all the data related to a 897 particular SIP AOR, and in consequence, to the user who owns the SIP 898 AOR. The Diameter SL acts in a similar way to a Diameter Redirect 899 Agent, dispatching Diameter requests (e.g., providing the redirection 900 URI in the answer). The Diameter SL can redirect all the request 901 pertaining to a user by setting the Redirect-Host-Usage AVP with a 902 value ALL_USER, as specified in RFC 3588 [RFC3588]. 904 The Diameter SL can be replicated in different nodes along the 905 network, for the purpose of building scalability and redundancy. The 906 database or routing tables have to be consistent across all these 907 different Diameter SLs, so that equal Diameter requests will produce 908 equal Diameter answers, no matter which Diameter SL processes the 909 request. 911 +--------+ +--------+ +--------+ +--------+ 912 | SIP | |Diameter| |Diameter| | SIP | 913 |server 1| |SL red. | |server 1| |server 2| 914 +--------+ +--------+ +--------+ +--------+ 915 | | | | 916 1. SIP INVITE| | | | 917 ------------>| 2. LIR | | | 918 |---------->| | | 919 | 3. LIA | | | 920 |<----------| | | 921 | 4. LIR | | 922 |---------------------->| | 923 | 5. LIA | | 924 |<----------------------| | 925 | 6. SIP INVITE | | 926 |----------------------------------->| 7. SIP INVITE 927 | | | | -------------> 928 | | | | 930 Figure 7: Locating a Diameter server. SL redirecting requests 932 Figure 7 shows an example of operation of a Diameter SL acting in 933 redirect mode. SIP server 1 receives an INVITE request (step 1) 934 addressed (in the SIP Request-URI) to a user for which the Diameter 935 client in SIP server 1 does not posses routing information. In other 936 words, the Diameter client in SIP server 1 does not know the URI of 937 Diameter server 1. The Diameter client sends a Diameter LIR message 938 (step 2) to any of the Diameter SLs configured in the network. The 939 address of those SLs is assumed to be pre-provisioned in the Diameter 940 client. The Diameter SL, based on the contents of the SIP-AOR AVP 941 and its own routing tables, determines the Diameter server that 942 stores the information allocated to such user. Then it builds a 943 Diameter LIA message (step 3) that includes a Result-Code AVP set to 944 DIAMETER_REDIRECT_INDICATION and one Redirect-Host AVP, whose value 945 is set to the URI of Diameter server that stores the information 946 related to such user. Then the Diameter client in SIP server 1 947 builds a new LIR message (step 4) addressed to the Diameter server 948 received in the Redirect-Host AVP. The rest of the procedure is 949 completed as described in previous sections. 951 7. Advertising Application Support 953 Diameter implementations conforming to this specification MUST 954 advertise its support by including an Auth-Application-Id AVP in the 955 Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer 956 (CEA) commands, according to the Diameter base protocol, RFC 3588 957 [RFC3588]. This Auth-Application-Id AVP MUST be set to the value of 958 this Diameter SIP application (Section 13.1 indicates the actual 959 value allocated by IANA). 961 8. Diameter SIP Application Command Codes 963 All the Diameter implementations conforming to this specification 964 MUST implement and support the list of Diameter commands listed in 965 Table 1. 967 +-------------------------------------+-------+------+--------------+ 968 | Command Name | Abbr. | Code | Reference | 969 +-------------------------------------+-------+------+--------------+ 970 | User-Authorization-Request | UAR | aaa | Section 8.1 | 971 | User-Authorization-Answer | UAA | aaa | Section 8.2 | 972 | Server-Assignment-Request | SAR | bbb | Section 8.3 | 973 | Server-Assignment-Answer | SAA | bbb | Section 8.4 | 974 | Location-Info-Request | LIR | ccc | Section 8.5 | 975 | Location-Info-Answer | LIA | ccc | Section 8.6 | 976 | Multimedia-Auth-Request | MAR | ddd | Section 8.7 | 977 | Multimedia-Auth-Answer | MAA | ddd | Section 8.8 | 978 | Registration-Termination-Request | RTR | eee | Section 8.9 | 979 | Registration-Termination-Answer | RTA | eee | Section 8.10 | 980 | Push-Profile-Request | PPR | fff | Section 8.11 | 981 | Push-Profile-Answer | PPA | fff | Section 8.12 | 982 +-------------------------------------+-------+------+--------------+ 984 Table 1: Defined command codes 986 [Note to IANA and the RFC editor: replace aaa, bbb, ccc, and so on 987 with the actual values allocated to these commands.] 989 Sections defining commands contain the Message Format for that 990 particular command. The Message Formats included in this document 991 are defined as per Section 3.2 of RFC 3588 [RFC3588]. 993 8.1. User-Authorization-Request (UAR) Command 995 The User-Authorization-Request (UAR) is indicated by the Command-Code 996 set to aaa [Note to IANA and the RFC editor: replace aaa with the 997 actual value allocated to this command] and the Command Flags' 'R' 998 bit set. The Diameter client in a SIP server sends this command to 999 the Diameter server to request authorization for the SIP User Agent 1000 to route a SIP REGISTER request. Because the SIP REGISTER request 1001 implicitly carries a permission to bind an AOR to a contact address, 1002 the Diameter client uses the Diameter UAR as a first authorization 1003 request towards the Diameter server to authorize the registration. 1004 For instance, the Diameter server can verify that the AOR is a 1005 legitimate user of the realm. 1007 The Diameter client in the SIP server requests authorization for one 1008 of the possible values defined in the SIP-User-Authorization-Type AVP 1009 (Section 9.10). 1011 The user name used for authentication of the user is conveyed in a 1012 User-Name AVP (defined in the Diameter base protocol, RFC 3588 1013 [RFC3588]). The location of the authentication user name in the SIP 1014 REGISTER request varies depending on the authentication mechanism. 1015 When the authentication mechanism is HTTP Digest as defined in RFC 1016 2617 [RFC2617], the authentication user name is found in the 1017 "username" directive of the SIP Authorization header field value. 1018 This Diameter SIP application only provides support for HTTP Digest 1019 authentication in SIP; other authentication mechanisms are not 1020 currently supported. 1022 The SIP or SIPS URI to be registered is conveyed in the SIP-AOR AVP 1023 (Section 9.8). Typically this SIP or SIPS URI is found in the To 1024 header field value of the SIP REGISTER request that triggered the 1025 Diameter UAR message. 1027 The SIP-Visited-Network-Id AVP indicates the network that is 1028 providing SIP services (e.g., SIP proxy functionality or any other 1029 kind of services) to the SIP User Agent. 1031 The Message Format of the UAR command is as follows: 1033 ::= < Diameter Header: aaa, REQ, PXY > 1034 < Session-Id > 1035 { Auth-Application-Id } 1036 { Auth-Session-State } 1037 { Origin-Host } 1038 { Origin-Realm } 1039 { Destination-Realm } 1040 { SIP-AOR } 1041 [ Destination-Host ] 1042 [ User-Name ] 1043 [ SIP-Visited-Network-Id ] 1044 [ SIP-User-Authorization-Type ] 1045 * [ Proxy-Info ] 1046 * [ Route-Record ] 1047 * [ AVP ] 1049 [Note to IANA and the RFC editor: replace aaa with the actual value 1050 allocated to this command] 1052 8.2. User-Authorization-Answer (UAA) Command 1054 The User-Authorization-Answer (UAA) is indicated by the Command-Code 1055 set to aaa [Note to IANA and the RFC editor: replace aaa with the 1056 actual value allocated to this command] and the Command Flags' 'R' 1057 bit cleared. The Diameter server sends this command in response to a 1058 previously received Diameter User-Authorization-Request (UAR) 1059 command. The Diameter server indicates the result of the requested 1060 registration authorization. Additionally, the Diameter server may 1061 indicate a collection of SIP capabilities that assists the Diameter 1062 client to select a SIP proxy to the AOR under registration. 1064 In addition to the values already defined in RFC 3588 [RFC3588], the 1065 Result-Code AVP may contain one of the values defined in 1066 Section 10.1. 1068 Whenever the Diameter server fails to process the Diameter UAR 1069 message, it MUST stop processing and return the relevant error in the 1070 Diameter UAA message. When there is success in the process, the 1071 Diameter server MUST set the code to DIAMETER_SUCCESS in the Diameter 1072 UAA message. 1074 If the Diameter server requires a User-Name AVP value to process the 1075 Diameter UAR request, but the Diameter UAR message did not contain a 1076 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1077 value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return 1078 it in a Diameter UAA message. Upon reception of this Diameter UAA 1079 message with the Result-Code AVP value set to 1080 DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests 1081 authentication by sending a SIP 401 (Unauthorized) or SIP 407 (Proxy 1082 Authentication Required) response back to the originator. 1084 When the authorization procedure succeeds, the Diameter server 1085 constructs a User-Authorization-Answer (UAA) message that MUST 1086 include (1) the address of the SIP server already assigned to the 1087 user name, (2) the capabilities needed by the SIP server (Diameter 1088 client) to select another SIP server for the user, or (3) a 1089 combination of the previous two options. 1091 If the Diameter server is already aware of a SIP server allocated to 1092 the user, the Diameter UAA message contains the address of that SIP 1093 server. 1095 The Diameter UAA message contains the capabilities required by a SIP 1096 server to trigger and execute services. It is required that these 1097 capabilities are present in the Diameter UAA message due to the 1098 possibility that the Diameter client (in the SIP server) allocates a 1099 different SIP server to trigger and execute services for that 1100 particular user. 1102 If a User-Name AVP is present in the Diameter UAR message, then the 1103 Diameter server MUST verify the existence of the user in the realm, 1104 i.e., the User-Name AVP value is a valid user within that realm. If 1105 the Diameter server does not recognize the user name received in the 1106 User-Name AVP, the Diameter server MUST build a Diameter User- 1107 Authorization-Answer (UAA) message and MUST set the Result-Code AVP 1108 to DIAMETER_ERROR_USER_UNKNOWN. 1110 If a User-Name AVP is present in the Diameter UAR message, then the 1111 Diameter server MUST authorize that User-Name AVP value is able to 1112 register the SIP or SIPS URI included in the SIP-AOR AVP. If this 1113 authorization fails, the Diameter server must set the Result-Code AVP 1114 to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter 1115 User-Authorization-Answer (UAA) message. 1117 Correlation between User-Name and SIP-AOR AVP values is required 1118 in order to avoid registration of a SIP-AOR allocated to another 1119 user. 1121 If there is a SIP-Visited-Network-Id AVP in the Diameter UAR message, 1122 and the SIP-User-Authorization-Type AVP value received in the 1123 Diameter UAR message is set to REGISTRATION or REGISTRATION& 1124 CAPABILITIES then the Diameter server SHOULD verify whether the user 1125 is allowed to roam into the network specified in the SIP-Visited- 1126 Network-Id AVP in the Diameter UAR message. If the user is not 1127 allowed to roam into that network, the Diameter AAA server MUST set 1128 the Result-Code AVP value in the Diameter UAA message to 1129 DIAMETER_ERROR_ROAMING_NOT_ALLOWED. 1131 If the SIP-User-Authorization-Type AVP value received in the Diameter 1132 UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES, then 1133 the Diameter server SHOULD verify whether the SIP-AOR AVP value is 1134 authorized to register in the home realm. Where the SIP AOR is not 1135 authorized to register in the home realm, the Diameter server MUST 1136 set the Result-Code AVP to DIAMETER_AUTHORIZATION_REJECTED and send 1137 it in a Diameter UAA message. 1139 When the SIP-User-Authorization-Type AVP is not present in the 1140 Diameter UAR message, or when it is present and its value is set to 1141 REGISTRATION, then: 1143 o If the Diameter server is not aware of any previous registration 1144 of the user name (including registrations of other SIP AORs 1145 allocated to the same user name), then the Diameter server does 1146 not know of any SIP server allocated to the user. In this case 1147 the Diameter server MUST set the Result-Code AVP value to 1148 DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and the 1149 Diameter server SHOULD include the required SIP server 1150 capabilities in the SIP-Server-Capabilities AVP value in the 1151 Diameter UAA message. The SIP-Server-Capabilities AVP assists the 1152 Diameter client (SIP server) to select an appropriate SIP server 1153 for the user, according to the required capabilities. 1154 o In some cases, the Diameter server is aware of a previously 1155 assigned SIP server for the same or different SIP AORs allocated 1156 to the same user name. In these cases, re-assignment of a new SIP 1157 server may or may not be needed, depending on the capabilities of 1158 the SIP server. The Diameter server MUST always include the 1159 allocated SIP server URI in the SIP-Server-URI AVP of the UAA 1160 message. If the Diameter server does not return the SIP 1161 capabilities, the Diameter server MUST set the Result-Code AVP in 1162 the Diameter UAA message to DIAMETER_SUBSEQUENT_REGISTRATION. 1163 Otherwise (i.e., if the Diameter server includes a SIP-Server- 1164 Capabilities AVP), then the Diameter server MUST set the Result- 1165 Code AVP in the Diameter UAA message to DIAMETER_SERVER_SELECTION. 1166 Then the Diameter client determines, based on the received 1167 information, whether it needs to select a new SIP server. 1169 When the SIP-User-Authorization-Type AVP value received in the 1170 Diameter UAR message is set to REGISTRATION&CAPABILITIES, then 1171 Diameter Server MUST return the list of capabilities in the SIP- 1172 Server-Capabilities AVP value of the Diameter UAA message, it MUST 1173 set the Result-Code to DIAMETER_SUCCESS, and it MUST NOT return a 1174 SIP-Server-URI AVP. The SIP-Server-Capabilities AVP enables the SIP 1175 server (Diameter Client) to select another appropriate SIP server for 1176 invoking and executing services for the user, depending on the 1177 required capabilities. The Diameter server MAY leave the list of 1178 capabilities empty to indicate that any SIP server can be selected. 1180 When the SIP-User-Authorization-Type AVP value received in the 1181 Diameter UAR message is set to DEREGISTRATION, then: 1183 o If the Diameter server is aware of a SIP server assigned to the 1184 SIP AOR under deregistration, the Diameter server MUST set the 1185 Result-Code AVP to DIAMETER_SUCCESS and MUST set the SIP-Server- 1186 URI AVP value to the known SIP server, and return them in the 1187 Diameter UAA message. 1188 o If the Diameter server is not aware of a SIP server assigned to 1189 the SIP AOR under deregistration, then the Diameter server MUST 1190 set the Result-Code AVP in the Diameter UAA message to 1191 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED. 1193 The Message Format of the UAA command is as follows: 1195 ::= < Diameter Header: aaa, PXY > 1196 < Session-Id > 1197 { Auth-Application-Id } 1198 { Auth-Session-State } 1199 { Result-Code } 1200 { Origin-Host } 1201 { Origin-Realm } 1202 [ SIP-Server-URI ] 1203 [ SIP-Server-Capabilities ] 1204 [ Authorization-Lifetime ] 1205 [ Auth-Grace-Period ] 1206 [ Redirect-Host ] 1207 [ Redirect-Host-Usage ] 1208 [ Redirect-Max-Cache-Time ] 1209 * [ Proxy-Info ] 1210 * [ Route-Record ] 1211 * [ AVP ] 1213 [Note to IANA and the RFC editor: replace aaa with the actual value 1214 allocated to this command] 1216 8.3. Server-Assignment-Request (SAR) Command 1218 The Server-Assignment-Request (SAR) command is indicated by the 1219 Command-Code set to bbb [Note to IANA and the RFC editor: replace bbb 1220 with the actual value allocated to this command] and the Command 1221 Flags' 'R' bit set. The Diameter client in a SIP server sends this 1222 command to the Diameter server to indicate the completion of the 1223 authentication process and to request that the Diameter server store 1224 the URI of the SIP server that is currently serving the user. The 1225 main functions of the Diameter SAR command are to inform the Diameter 1226 server of the URI of the SIP server allocated to the user, and to 1227 store or clear it from the Diameter server. Additionally, the 1228 Diameter client can request to download the user profile or part of 1229 it. 1231 During the registration procedure, a SIP server becomes assigned to 1232 the user. The Diameter client in the assigned SIP server MUST 1233 include its own URI in the SIP-Server-URI AVP of the Server- 1234 Assignment-Request (SAR) Diameter message and send it to the Diameter 1235 server. The Diameter server then becomes aware of the allocation of 1236 the SIP server to the user name and the server's URI. 1238 The Diameter client in the SIP server MAY send a Diameter SAR message 1239 because of other reasons. These reasons are identified in the SIP- 1240 Server-Assignment-Type AVP (Section 9.4) value. For instance, a 1241 Diameter client in a SIP server may contact the Diameter server to 1242 request deregistration of a user, to inform the Diameter server of an 1243 authentication failure, or just to download the user profile. For a 1244 complete description of all the SIP-Server-Assignment-Type AVP values 1245 see Section 9.4. 1247 Typically the reception of a SIP REGISTER request in a SIP server 1248 will trigger the Diameter client in the SIP server to send the 1249 Diameter SAR message. However, if a SIP server is receiving other 1250 SIP request, such as INVITE, and the SIP server does not have the 1251 user profile, the Diameter client in the SIP server may send the 1252 Diameter SAR message to the Diameter server in order to download the 1253 user profile and make the Diameter server aware of the SIP server 1254 assigned to the user. 1256 The user profile is an important piece of information that dictates 1257 the behavior of the SIP server when triggering or providing services 1258 for the user. Typically the user profile is divided into: 1260 o Services to be rendered to the user when the user is registered 1261 and initiates a SIP request. 1262 o Services to be rendered to the user when the user is registered 1263 and a SIP request destined to that user arrives to the SIP proxy. 1264 o Services to be rendered to the user when the user is not 1265 registered and a SIP request destined to that user arrives to the 1266 SIP proxy. 1268 The SIP-Server-Assignment-Type AVP indicates the reason why the 1269 Diameter client (SIP server) contacted the Diameter server. If the 1270 Diameter client sets the SIP-Server-Assignment-Type AVP value to 1271 REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT, 1272 AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter client 1273 MUST include exactly one SIP-AOR AVP in the Diameter SAR message. 1275 The SAR message MAY contain zero or more SIP-Supported-User-Data-Type 1276 AVPs. Each of them contains a type of user data understood by the 1277 SIP server. This allows the Diameter client to provide an indication 1278 to the Diameter server of the different format of user data 1279 understood by the SIP server. The Diameter server uses this 1280 information to select one or more SIP-User-Data AVPs that will be 1281 included in the SAA message. 1283 The Message Format of the SAR command is as follows: 1285 ::= < Diameter Header: bbb, REQ, PXY > 1286 < Session-Id > 1287 { Auth-Application-Id } 1288 { Auth-Session-State } 1289 { Origin-Host } 1290 { Origin-Realm } 1291 { Destination-Realm } 1292 { SIP-Server-Assignment-Type } 1293 { SIP-User-Data-Already-Available } 1294 [ Destination-Host ] 1295 [ User-Name ] 1296 [ SIP-Server-URI ] 1297 * [ SIP-Supported-User-Data-Type ] 1298 * [ SIP-AOR ] 1299 * [ Proxy-Info ] 1300 * [ Route-Record ] 1301 * [ AVP ] 1303 [Note to IANA and the RFC editor: replace bbb with the actual value 1304 allocated to this command] 1306 8.4. Server-Assignment-Answer (SAA) Command 1308 The Server-Assignment-Answer (SAA) is indicated by the Command-Code 1309 set to bbb [Note to IANA and the RFC editor: replace bbb with the 1310 actual value allocated to this command] and the Command Flags' 'R' 1311 bit cleared. The Diameter server sends this command in response to a 1312 previously received Diameter Server-Assignment-Request (SAR) command. 1313 The response may include the user profile or part of it, if 1314 requested. 1316 In addition to the values already defined in RFC 3588 [RFC3588], the 1317 Result-Code AVP may contain one of the values defined in 1318 Section 10.1. 1320 The Result-Code AVP value in the Diameter SAA message may indicate a 1321 success or an error in the execution of the Diameter SAR command. If 1322 Result-Code AVP value in the Diameter SAA message does not contain an 1323 error code, the SAA message MAY include one or more SIP-User-Data 1324 AVPs that typically contain the profile of the user, indicating 1325 services that the SIP server can provide to that user. 1327 The Diameter server MAY include one or more SIP-Supported-User-Data- 1328 Type AVPs, each one identifying a type of user data format supported 1329 in the Diameter server. If there is not a common supported user data 1330 type between the Diameter client and the Diameter server, the 1331 Diameter server SHOULD declare its list of supported user data types 1332 by including one or more SIP-Supported-User-Data-Type AVPs in a 1333 Diameter SAA message. This indication is merely for debugging 1334 reasons, since there is not a fallback mechanism that allows the 1335 Diameter client to retrieve the profile in a supported format. 1337 If the Diameter server requires a User-Name AVP value to process the 1338 Diameter SAR request, but the Diameter SAR message did not contain a 1339 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1340 value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return 1341 it in a Diameter SAA message. Upon reception of this Diameter SAA 1342 message with the Result-Code AVP value set to 1343 DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests 1344 authentication by generating a SIP 401 (Unauthorized) or SIP 407 1345 (Proxy Authentication Required) response back to the originator. 1347 If the User-Name AVP is included in the Diameter SAR message, upon 1348 reception of the Diameter SAR message, the Diameter server MUST 1349 verify the existence of the user in the realm, i.e., the User-Name 1350 AVP value is a valid user within that realm. If the Diameter server 1351 does not recognize the user name received in the User-Name AVP, the 1352 Diameter server MUST build a Diameter Server-Assignment-Answer (SAA) 1353 message and MUST set the Result-Code AVP to 1354 DIAMETER_ERROR_USER_UNKNOWN. 1356 Then the Diameter server MUST authorize that User-Name AVP value is a 1357 valid authentication name for the SIP or SIPS URI included in the 1358 SIP-AOR AVP of the Diameter SAR message. If this authorization 1359 fails, the Diameter server must set the Result-Code AVP to 1360 DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter 1361 Server-Assignment-Answer (SAA) message. 1363 After a successful executaion of Diameter SAR command, the Diameter 1364 server MUST clear the "authentication pending" flag. 1366 The actions of the Diameter server upon reception of the Diameter SAR 1367 message depend on the value of the SIP-Server-Assignment-Type: 1369 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1370 message is set to REGISTRATION or RE_REGISTRATION, the Diameter 1371 server SHOULD verify that there is only one SIP-AOR AVP. 1372 Otherwise, the Diameter server MUST answer with a Diameter SAA 1373 message with the Result-Code AVP value set to 1374 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any SIP- 1375 User-Data AVP. If there is only one SIP-AOR AVP and if the SIP- 1376 User-Data-Already-Available AVP value is set to 1377 USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include 1378 one or more user profile data with the SIP or SIPS URI (SIP-AOR 1379 AVP) and all other SIP identities associated with that AVP in the 1380 SIP-User-Data AVP value of the Diameter SAA message. On selecting 1381 the type of user data, the Diameter server SHOULD take into 1382 account the supported formats at the SIP server (SIP-Supported- 1383 User-Data-Type AVP in the SAR message) and the local policy. 1384 Additionally, the Diameter server MUST set the Result-Code AVP 1385 value to DIAMETER_SUCCESS in the Diameter SAA message. The 1386 Diameter server considers the SIP AOR authenticated and 1387 registered. 1388 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1389 message is set to UNREGISTERED_USER then the Diameter server MUST 1390 store the SIP server address included in the SIP-Server-URI AVP 1391 value. The Diameter server will return the SIP server address in 1392 Diameter Location-Info-Answer (LIA) messages. If the SIP-User- 1393 Data-Already-Available AVP value is set to 1394 USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include 1395 one or more user profile data associated with the SIP or SIPS URI 1396 (SIP-AOR AVP) and associated identities in the SIP-User-Data AVP 1397 value of the Diameter SAA message. On selecting the type of user 1398 data, the Diameter server SHOULD take into account the supported 1399 formats at the SIP server (SIP-Supported-User-Data-Type AVP in the 1400 SAR message) and the local policy. The Diameter server MUST set 1401 the Result-Code AVP value to DIAMETER_SUCCESS. The Diameter 1402 server considers the SIP AOR UNREGISTERED, but with a SIP server 1403 allocated to trigger and provide services for unregistered users. 1404 Note that in case of UNREGISTERED_USER (SIP-Server-Assignment-Type 1405 AVP), the Diameter server MUST verify that there is only one SIP- 1406 AOR AVP. Otherwise, the Diameter server MUST answer the Diameter 1407 SAR message with a Diameter SAA message, and it MUST set the 1408 Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and 1409 MUST NOT include any SIP-User-Data AVP. 1410 If the User-Name AVP was not present in the Diameter SAR message 1411 and the SIP-AOR is not known for the Diameter server, the Diameter 1412 server MUST NOT include a User-Name AVP in the Diameter SAA 1413 message and MUST set the Result-Code AVP value to 1414 DIAMETER_ERROR_USER_UNKNOWN. 1416 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1417 message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, 1418 DEREGISTRATION_TOO_MUCH_DATA, or ADMINISTRATIVE_DEREGISTRATION the 1419 Diameter server MUST clear the SIP server address associated with 1420 all SIP AORs indicated in each of the SIP-AOR AVP values included 1421 in the Diameter SAR message. The Diameter server considers all of 1422 these SIP AORs as not registered. The Diameter server MUST set 1423 the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA 1424 message. 1425 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1426 message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or 1427 USER_DEREGISTRATION_STORE_SERVER_NAME, the Diameter server MAY 1428 keep the SIP server address associated with the SIP AORs included 1429 in the SIP-AOR AVP values of the Diameter SAR message, even though 1430 the SIP AORs becomes unregistered. This feature allows a SIP 1431 server to request that the Diameter server remain an assigned SIP 1432 server for those SIP AORs (SIP-AOR AVP values) allocated to the 1433 same user name, and avoid SIP server assignment. The Diameter 1434 server MUST consider all these SIP AORs as not registered. If the 1435 Diameter server honors the request of the Diameter client (SIP 1436 server) to remain as an allocated SIP server, then the Diameter 1437 server MUST keep the SIP server assigned to those SIP AORs 1438 allocated to the username and MUST set the Result-Code AVP value 1439 to DIAMETER_SUCCESS in the Diameter SAA message. Otherwise, when 1440 the Diameter server does not honor the request of the Diameter 1441 client (SIP server) to remain as an allocated SIP server, the 1442 Diameter server MUST clear the SIP server name assigned to those 1443 SIP AORs and it MUST set the Result-Code AVP value to 1444 DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED in the Diameter SAA 1445 message. 1446 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1447 message is set to NO_ASSIGNMENT, the Diameter server SHOULD first 1448 verify that the SIP-Server-URI AVP value in the Diameter SAR 1449 message is the same URI as the one assigned to the SIP-AOR AVP 1450 value. If they differ, then the Diameter server MUST set the 1451 Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY in the Diameter 1452 SAA message. Otherwise, if the SIP-User-Data-Already-Available 1453 AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter 1454 server SHOULD include the user profile data with the SIP or SIPS 1455 URI (SIP-AOR AVP) and all other SIP identities associated with 1456 that AVP in the SIP-User-Data AVP value of the Diameter SAA 1457 message. On selecting the type of user data, the Diameter server 1458 SHOULD take into account the supported formats at the SIP server 1459 (SIP-Supported-User-Data-Type AVP in the SAR message) and the 1460 local policy. 1461 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1462 message is set to AUTHENTICATION_FAILURE or 1463 AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there 1464 is exactly one SIP-AOR AVP in the Diameter SAR message. If the 1465 number of occurrences of the SIP-AOR AVP is not exactly one, the 1466 Diameter server MUST set the Result-Code AVP value to 1467 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message, 1468 and SHOULD not take further actions. If there is exactly one SIP- 1469 AOR AVP in the Diameter SAR message, the Diameter server MUST 1470 clear the address of the SIP server assigned to the SIP AOR 1471 allocated to the user name, and the Diameter server MUST set the 1472 Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA 1473 message. The Diameter server MUST consider the SIP AOR as not 1474 registered. 1476 The Message Format of the SAA command is as follows: 1478 ::= < Diameter Header: bbb, PXY > 1479 < Session-Id > 1480 { Auth-Application-Id } 1481 { Result-Code } 1482 { Auth-Session-State } 1483 { Origin-Host } 1484 { Origin-Realm } 1485 * [ SIP-User-Data ] 1486 [ SIP-Accounting-Information ] 1487 * [ SIP-Supported-User-Data-Type ] 1488 [ User-Name ] 1489 [ Auth-Grace-Period ] 1490 [ Authorization-Lifetime ] 1491 [ Redirect-Host ] 1492 [ Redirect-Host-Usage ] 1493 [ Redirect-Max-Cache-Time ] 1494 * [ Proxy-Info ] 1495 * [ Route-Record ] 1496 * [ AVP ] 1498 [Note to IANA and the RFC editor: replace bbb with the actual value 1499 allocated to this command] 1501 8.5. Location-Info-Request (LIR) Command 1503 The Location-Info-Request (LIR) is indicated by the Command-Code set 1504 to ccc [Note to IANA and the RFC editor: replace ccc with the actual 1505 value allocated to this command] and the Command Flags' 'R' bit set. 1506 The Diameter client in a SIP server sends this command to the 1507 Diameter server to request routing information, e.g., the URI of the 1508 SIP server assigned to the SIP-AOR AVP value allocated to the users. 1510 The Message Format of the LIR command is as follows: 1512 ::= < Diameter Header: ccc, REQ, PXY > 1513 < Session-Id > 1514 { Auth-Application-Id } 1515 { Auth-Session-State } 1516 { Origin-Host } 1517 { Origin-Realm } 1518 { Destination-Realm } 1519 { SIP-AOR } 1520 [ Destination-Host ] 1521 * [ Proxy-Info ] 1522 * [ Route-Record ] 1523 * [ AVP ] 1525 [Note to IANA and the RFC editor: replace ccc with the actual value 1526 allocated to this command] 1528 8.6. Location-Info-Answer (LIA) Command 1530 The Location-Info-Answer (LIA) is indicated by the Command-Code set 1531 to ccc [Note to IANA and the RFC editor: replace ccc with the actual 1532 value allocated to this command] and the Command Flags' 'R' bit 1533 cleared. The Diameter server sends this command in response to a 1534 previously received Diameter Location-Info-Request (LIR) command. 1536 In addition to the values already defined in RFC 3588 [RFC3588], the 1537 Result-Code AVP may contain one of the values defined in 1538 Section 10.1. When the Diameter server finds an error in processing 1539 the Diameter LIR message, the Diameter server MUST stop the process 1540 of the message and answer with a Diameter LIA message that includes 1541 the appropriate error code in the Result-Code AVP value. When there 1542 is no error, the Diameter server MUST set the Result-Code AVP value 1543 to DIAMETER_SUCCESS in the Diameter LIA message. 1545 One of the errors that the Diameter server may find is that the SIP- 1546 AOR AVP value is not a valid user in the realm. In such cases, the 1547 Diameter server MUST set the Result-Code AVP value to 1548 DIAMETER_ERROR_USER_UNKNOWN and return it in a Diameter LIA message. 1550 If the Diameter server cannot process the Diameter LIR command, e.g., 1551 due to a database error, the Diameter server MUST set the Result-Code 1552 AVP value to DIAMETER_UNABLE_TO_COMPLY and return it in a Diameter 1553 LIA message. The Diameter server MUST NOT include any SIP-Server-URI 1554 or SIP-Server-Capabilities AVP in the Diameter LIA message. 1556 The Diameter server may or may not be aware of a SIP server assigned 1557 to the SIP-AOR AVP value included in the Diameter LIR message. If 1558 the Diameter server is aware of a SIP server allocated to that 1559 particular user, the Diameter server MUST include the URI of such SIP 1560 server in the SIP-Server-URI AVP and return it in a Diameter LIA 1561 message. This is typically the situation when the user is either 1562 registered, or unregistered but a SIP server is still assigned to the 1563 user. 1565 When the Diameter server is not aware of a SIP server allocated to 1566 the user (typically the case when the user unregistered), the Result- 1567 Code AVP value in the Diameter LIA message depends on whether the 1568 Diameter server is aware that the user has services defined for 1569 unregistered users: 1571 o Those users who have services defined for unregistered users may 1572 require the allocation of a SIP server to trigger and perhaps 1573 execute those services. Therefore, when the Diameter server is 1574 not aware of an assigned SIP server, but the user has services 1575 defined for unregistered users, the Diameter server MUST set the 1576 Result-Code AVP value to DIAMETER_UNREGISTERED_SERVICE and return 1577 it in a Diameter LIA message. The Diameter server MAY also 1578 include a SIP-Server-Capabilities AVP to facilitate the SIP server 1579 (Diameter client) with the selection of an appropriate SIP server 1580 with the required capabilities. Absence of the SIP-Server- 1581 Capabilities AVP indicates to the SIP server (Diameter client) 1582 that any SIP server is suitable to be allocated for the user. 1583 o Those users who do not have service defined for unregistered users 1584 do not require further processing. The Diameter server MUST set 1585 the Result-Code AVP value to 1586 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED and return it to the 1587 Diameter client in a Diameter LIA message. The SIP server 1588 (Diameter client) may return the appropriate SIP response (e.g., 1589 480 (Temporarily unavailable)) to the original SIP request. 1591 The Message Format of the LIA command is as follows: 1593 ::= < Diameter Header: ccc, PXY > 1594 < Session-Id > 1595 { Auth-Application-Id } 1596 { Result-Code } 1597 { Auth-Session-State } 1598 { Origin-Host } 1599 { Origin-Realm } 1600 [ SIP-Server-URI ] 1601 [ SIP-Server-Capabilities ] 1602 [ Auth-Grace-Period ] 1603 [ Authorization-Lifetime ] 1604 [ Redirect-Host ] 1605 [ Redirect-Host-Usage ] 1606 [ Redirect-Max-Cache-Time ] 1607 * [ Proxy-Info ] 1608 * [ Route-Record ] 1609 * [ AVP ] 1611 [Note to IANA and the RFC editor: replace ccc with the actual value 1612 allocated to this command] 1614 8.7. Multimedia-Auth-Request (MAR) Command 1616 The Multimedia-Auth-Request (MAR) command is indicated by the 1617 Command-Code set to ddd [Note to IANA and the RFC editor: replace ddd 1618 with the actual value allocated to this command] and the Command 1619 Flags' 'R' bit set. The Diameter client in a SIP server sends this 1620 command to the Diameter server to request that the Diameter server 1621 authenticate and authorize a user attempt to use some SIP service (in 1622 this context, SIP service can be something as simple as a SIP 1623 subscription or using the proxy services for a SIP request). Unlike 1624 the Diameter SAR command, MAR does not store any state in the 1625 Diameter server. 1627 The MAR command also registers the SIP server's own URI to the 1628 Diameter server, so that future LIR/LIA messages can return this URI. 1630 The SIP-Method AVP MUST include the SIP method name of the SIP 1631 request that triggered this Diameter MAR message. The Diameter 1632 server can use this AVP to authorize some SIP requests depending on 1633 the method. 1635 The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP 1636 indicates the target of the SIP request. The value of the AVP is 1637 extracted from different places in SIP request, depending on the 1638 semantics of the SIP request. For SIP REGISTER messages the SIP-AOR 1639 AVP value indicates the intended public user identity under 1640 registration, and it is the SIP or SIPS URI populated in the To 1641 header field value (addr-spec as per RFC 3262 [RFC3261]) of the SIP 1642 REGISTER request. For other types of SIP requests, such as INVITE, 1643 SUBSCRIBE, MESSAGE, etc., the SIP-AOR AVP value indicates the 1644 intended destination of the request. This is typically populated in 1645 the Request-URI of the SIP request. Extracting the SIP-AOR AVP value 1646 from the proper SIP header field is the Diameter client's 1647 responsibility. Extensions to SIP (new SIP methods or new semantics) 1648 may require the SIP-AOR to be extracted from other parts of the 1649 request. 1651 If the SIP request includes some sort of authentication information, 1652 the Diameter client MUST include the user name, extracted from the 1653 authentication information of the SIP request, in the User-Name AVP 1654 value. 1656 The Message Format of the MAR command is as follows: 1658 ::= < Diameter Header: ddd, REQ, PXY > 1659 < Session-Id > 1660 { Auth-Application-Id } 1661 { Auth-Session-State } 1662 { Origin-Host } 1663 { Origin-Realm } 1664 { Destination-Realm } 1665 { SIP-AOR } 1666 { SIP-Method } 1667 [ Destination-Host ] 1668 [ User-Name ] 1669 [ SIP-Server-URI ] 1670 [ SIP-Number-Auth-Items ] 1671 [ SIP-Auth-Data-Item ] 1672 * [ Proxy-Info ] 1673 * [ Route-Record ] 1674 * [ AVP ] 1676 [Note to IANA and the RFC editor: replace ddd with the actual value 1677 allocated to this command] 1679 8.8. Multimedia-Auth-Answer (MAA) Command 1681 The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set 1682 to ddd [Note to IANA and the RFC editor: replace ddd with the actual 1683 value allocated to this command] and the Command Flags' 'R' bit 1684 cleared. The Diameter server sends this command in response to a 1685 previously received Diameter Multimedia-Auth-Request (MAR) command. 1687 In addition to the values already defined in RFC 3588 [RFC3588], the 1688 Result-Code AVP may contain one of the values defined in 1689 Section 10.1. 1691 If the Diameter server requires a User-Name AVP value to process the 1692 Diameter MAR request, but the Diameter MAR message did not contain a 1693 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1694 value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return 1695 it in a Diameter MAA message. The Diameter server MAY include a SIP- 1696 Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs with 1697 authentication information (e.g., a challenge). Upon reception of 1698 this Diameter MAA message with the Result-Code AVP value set to 1699 DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests 1700 authentication by generating a SIP 401 (Unauthorized) or SIP 407 1701 (Proxy Authentication Required) response back to the originator. 1703 If the User-Name AVP is present in the Diameter MAR message, the 1704 Diameter server MUST verify the existence of the user in the realm, 1705 i.e., the User-Name AVP value is a valid user within that realm. If 1706 the Diameter server does not recognize the user name received in the 1707 User-Name AVP, the Diameter server MUST build a Diameter Multimedia- 1708 Auth-Answer (MAA) message and MUST set the Result-Code AVP to 1709 DIAMETER_ERROR_USER_UNKNOWN. 1711 If the SIP-Methods AVP value of the Diameter MAR message is set to 1712 REGISTER and a User-Name AVP is present, then the Diameter server 1713 MUST authorize that User-Name AVP value is able to use the URI 1714 included in the SIP-AOR AVP. If this authorization fails, the 1715 Diameter server must set the Result-Code AVP to 1716 DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter 1717 Multimedia-Auth-Answer (MAA) message. 1719 Correlation between User-Name and SIP-AOR AVP values is only 1720 required for SIP REGISTER request, to prevent a user from 1721 registering a SIP-AOR allocated to another user. In other types 1722 of SIP requests (e.g., INVITE), the SIP-AOR indicates the intended 1723 destination of the request, rather than the originator of it. 1725 The Diameter server MUST verify whether the authentication scheme 1726 (SIP-Authentication-Scheme AVP value) indicated in the grouped SIP- 1727 Auth-Data-Item AVP is supported or not. If that authentication 1728 scheme is not supported, then the Diameter server MUST set the 1729 Result-Code AVP to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send 1730 it in a Diameter Multimedia-Auth-Answer (MAA) message. 1732 If the SIP-Number-Auth-Items AVP is present in the Diameter MAR 1733 message, it indicates the number of authentication data items that 1734 the Diameter client is requesting. It is RECOMMENDED that the 1735 Diameter server, when building the Diameter MAA message, includes a 1736 number of SIP-Auth-Data-Item AVPs that is a subset of the 1737 authentication data items requested by the Diameter client in the 1738 SIP-Number-Auth-Items AVP value of the Diameter MAR message. 1740 If the SIP-Server-URI AVP is present in the Diameter MAR message, 1741 then the Diameter server MUST compare the stored SIP server (assigned 1742 to the user) with the SIP-Server-URI AVP value (received in the 1743 Diameter MAR message). If they don't match, the Diameter server MUST 1744 update the stored SIP server assigned to the user, and MUST set an 1745 "authentication pending" flag for the user. If they match, the 1746 Diameter server shall clear the "authentication pending" flag for the 1747 user. 1749 In any other situation, if there is a success in processing the 1750 Diameter MAR command and the Diameter server stored the SIP-Server- 1751 URI, the Diameter server MUST set the Result-Code AVP value to 1752 DIAMETER_SUCCESS and return it in a Diameter MAA message. 1754 If there is a success in processing the Diameter MAR command, but the 1755 Diameter server does not store the SIP-Server-URI because the AVP was 1756 not present in the Diameter MAR command, then the Diameter server 1757 MUST set the Result-Code AVP value to either: 1759 1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter 1760 server is sending authentication credentials to create a 1761 challenge. 1762 2. DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED, if the Diameter server 1763 successfully authenticated the user and authorized the SIP server 1764 to proceed with the SIP request. 1766 Otherwise, the Diameter server MUST set the Result-Code AVP value to 1767 DIAMETER_UNABLE_TO_COMPLY, and it MUST NOT include any SIP-Auth-Data- 1768 Item AVP. 1770 The Message Format of the MAA command is as follows: 1772 ::= < Diameter Header: ddd, PXY > 1773 < Session-Id > 1774 { Auth-Application-Id } 1775 { Result-Code } 1776 { Auth-Session-State } 1777 { Origin-Host } 1778 { Origin-Realm } 1779 [ User-Name ] 1780 [ SIP-AOR ] 1781 [ SIP-Number-Auth-Items ] 1782 * [ SIP-Auth-Data-Item ] 1783 [ Authorization-Lifetime ] 1784 [ Auth-Grace-Period ] 1785 [ Redirect-Host ] 1786 [ Redirect-Host-Usage ] 1787 [ Redirect-Max-Cache-Time ] 1788 * [ Proxy-Info ] 1789 * [ Route-Record ] 1790 * [ AVP ] 1792 [Note to IANA and the RFC editor: replace ddd with the actual value 1793 allocated to this command] 1795 8.9. Registration-Termination-Request (RTR) Command 1797 The Registration-Termination-Request (RTR) command is indicated by 1798 the Command-Code set to eee [Note to IANA and the RFC editor: replace 1799 eee with the actual value allocated to this command] and the Command 1800 Flags' 'R' bit set. The Diameter server sends this command to the 1801 Diameter client in a SIP server to indicate to the SIP server that 1802 one or more SIP AORs have to be deregistered. The command allows an 1803 operator to administratively cancel the registration of a user from a 1804 centralized Diameter server. 1806 The Diameter server has the capability to initiate the deregistration 1807 of a user and inform the SIP server by means of the Diameter RTR 1808 command. The Diameter server can decide whether only one SIP AOR is 1809 going to be deregistered, a list of SIP AORs, or all the SIP AORs 1810 allocated to the user. 1812 The absence of a SIP-AOR AVP in the Diameter RTR message indicates 1813 that all the SIP AORs allocated to the user identified by the User- 1814 Name AVP are being deregistered. 1816 The Diameter server MUST include a SIP-Deregistration-Reason AVP 1817 value to indicate the reason for the deregistration. 1819 The Message Format of the RTR command is as follows: 1821 ::= < Diameter Header: eee, REQ, PXY > 1822 < Session-Id > 1823 { Auth-Application-Id } 1824 { Auth-Session-State } 1825 { Origin-Host } 1826 { Origin-Realm } 1827 { Destination-Host } 1828 { SIP-Deregistration-Reason } 1829 [ Destination-Realm ] 1830 [ User-Name ] 1831 * [ SIP-AOR ] 1832 * [ Proxy-Info ] 1833 * [ Route-Record ] 1834 * [ AVP ] 1836 [Note to IANA and the RFC editor: replace eee with the actual value 1837 allocated to this command] 1839 8.10. Registration-Termination-Answer (RTA) Command 1841 The Registration-Termination-Answer (RTA) is indicated by the 1842 Command-Code set to eee [Note to IANA and the RFC editor: replace eee 1843 with the actual value allocated to this command] and the Command 1844 Flags' 'R' bit cleared. The Diameter client sends this command in 1845 response to a previously received Diameter Registration-Termination- 1846 Request (RTR) command. 1848 In addition to the values already defined in RFC 3588 [RFC3588], the 1849 Result-Code AVP may contain one of the values defined in 1850 Section 10.1. 1852 If the Diameter server requires a User-Name AVP value to process the 1853 Diameter RTR request, but the Diameter RTR message did not contain a 1854 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1855 value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return 1856 it in a Diameter RTA message. Upon reception of this Diameter RTA 1857 message with the Result-Code AVP value set to 1858 DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests 1859 authentication by generating a SIP 401 (Unauthorized) or SIP 407 1860 (Proxy Authentication Required) response back to the originator. 1862 The SIP server (Diameter client) applies the administrative 1863 deregistration to each of the URIs included in each of the SIP-AOR 1864 AVP values, or, if there is no SIP-AOR AVP present in the Diameter 1865 RTR request, to all the URIs allocated to the User-Name AVP value. 1867 The value of the SIP-Deregistration-Reason AVP in the Diameter RTR 1868 command has an effect on the actions performed at the SIP server 1869 (Diameter client): 1871 o If the value is set to PERMANENT_TERMINATION, then the user has 1872 terminated his/her registration to the realm. If informing the 1873 interested parties (e.g., subscribers to the "reg" event 1874 [RFC3680]) about the administrative deregistration is supported 1875 through SIP procedures, the SIP server (Diameter client) will do 1876 so. The Diameter Client in the SIP Server SHOULD NOT request a 1877 new user registration. The SIP server clears the registration 1878 state of the deregistered AORs. 1879 o If the value is set to NEW_SIP_SERVER_ASSIGNED, the Diameter 1880 server informs the SIP server (Diameter client) that a new SIP 1881 server has been allocated to the user, due to some reason. The 1882 SIP server, if supported through SIP procedures, will inform the 1883 interested parties (e.g., subscribers to the "reg" event 1884 [RFC3680]) about the administrative deregistration at this SIP 1885 server. The Diameter client in the SIP server SHOULD NOT request 1886 a new user registration. The SIP server clears the registration 1887 state of the deregistered SIP AORs. 1888 o If the value is set to SIP_SERVER_CHANGE, the Diameter server 1889 informs the SIP server (Diameter client) that a new SIP server has 1890 to be allocated to the user, e.g., due to user's capabilities 1891 requiring a new SIP server, or not enough resources in the current 1892 SIP server. If informing the interested parties about the 1893 administrative deregistration is supported through SIP procedures 1894 (e.g., subscriptions to the "reg" event [RFC3680]), the SIP server 1895 will do so. The Diameter client in the SIP Server SHOULD NOT 1896 request a new user registration. The SIP server clears the 1897 registration state of the deregistered SIP AORs. 1898 o If the value is set to REMOVE_SIP_SERVER, the Diameter server 1899 informs the SIP server (Diameter client) that the SIP server will 1900 no longer be bound in the Diameter server with that user. The SIP 1901 server can delete all data related to the user. 1903 The Message Format of the RTA command is as follows: 1905 ::= < Diameter Header: eee, PXY > 1906 < Session-Id > 1907 { Auth-Application-Id } 1908 { Result-Code } 1909 { Auth-Session-State } 1910 { Origin-Host } 1911 { Origin-Realm } 1912 [ Authorization-Lifetime ] 1913 [ Auth-Grace-Period ] 1914 [ Redirect-Host ] 1915 [ Redirect-Host-Usage ] 1916 [ Redirect-Max-Cache-Time ] 1917 * [ Proxy-Info ] 1918 * [ Route-Record ] 1919 * [ AVP ] 1921 [Note to IANA and the RFC editor: replace eee with the actual value 1922 allocated to this command] 1924 8.11. Push-Profile-Request (PPR) Command 1926 The Push-Profile-Request (PPR) command is indicated by the Command- 1927 Code set to fff [Note to IANA and the RFC editor: replace fff with 1928 the actual value allocated to this command] and the Command Flags' 1929 'R' bit set. The Diameter server sends this command to the Diameter 1930 client in a SIP server to update either the user profile of an 1931 already registered user in that SIP server or the SIP accounting 1932 information. This allows an operator to modify the data of a user 1933 profile or the accounting information and push it to the SIP server 1934 where the user is registered. 1936 Each user has a user profile associated with him/her and other 1937 accounting information. The profile or the accounting information 1938 may change with time, e.g., due to addition of new services to the 1939 user. When the user profile or the accounting information changes, 1940 the Diameter server sends a Diameter Push-Profile-Request (PPR) 1941 command to the Diameter client in a SIP server, in order to start 1942 applying those new services. 1944 A PPR command MAY contain a SIP-Accounting-Information AVP that 1945 updates the addresses of the accounting servers. Changes in the 1946 addresses of the accounting servers take effect immediately. The 1947 Diameter client SHOULD close any existing accounting session with the 1948 existing server and start providing accounting information to the 1949 newly acquired accounting server. 1951 A PPR command MAY contain zero or more SIP-User-Data AVP values 1952 containing the new user profile. On selecting the type of user data, 1953 the Diameter server SHOULD take into account the supported formats at 1954 the SIP server (SIP-Supported-User-Data-Type AVP sent in a previous 1955 SAR message) and the local policy. 1957 The User-Name AVP indicates the user to whom the profile is 1958 applicable. 1960 The Message Format of the PPR command is as follows: 1962 ::= < Diameter Header: fff, REQ, PXY > 1963 < Session-Id > 1964 { Auth-Application-Id } 1965 { Auth-Session-State } 1966 { Origin-Host } 1967 { Origin-Realm } 1968 { Destination-Realm } 1969 { User-Name } 1970 * [ SIP-User-Data ] 1971 [ SIP-Accounting-Information ] 1972 [ Destination-Host ] 1973 [ Authorization-Lifetime ] 1974 [ Auth-Grace-Period ] 1975 * [ Proxy-Info ] 1976 * [ Route-Record ] 1977 * [ AVP ] 1979 [Note to IANA and the RFC editor: replace fff with the actual value 1980 allocated to this command] 1982 8.12. Push-Profile-Answer (PPA) Command 1984 The Push-Profile-Answer (PPA) is indicated by the Command-Code set to 1985 fff [Note to IANA and the RFC editor: replace fff with the actual 1986 value allocated to this command] and the Command Flags' 'R' bit 1987 cleared. The Diameter client sends this command in response to a 1988 previously received Diameter Push-Profile-Request (PPR) command. 1990 In addition to the values already defined in RFC 3588 [RFC3588], the 1991 Result-Code AVP may contain one of the values defined in 1992 Section 10.1. 1994 If there is no error when processing the received Diameter PPR 1995 message, the SIP server (Diameter client) MUST download the received 1996 user profile from the SIP-User-Data AVP values in the Diameter PPR 1997 message and store it associated with the user specified in the User- 1998 Name AVP value. 2000 If the SIP server does not recognize or does not support some of the 2001 data transferred in the SIP-User-Data AVP values, the Diameter client 2002 in the SIP server MUST return a Diameter PPA message that includes a 2003 Result-Code AVP set to the value 2004 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA. 2006 If the SIP server (Diameter client) receives a Diameter PPR message 2007 with a User-Name AVP that is unknown, the Diameter client MUST set 2008 the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN and MUST 2009 return it to the Diameter server in a Diameter PPA message. 2011 If the SIP server (Diameter client) receives in the SIP-User-Data- 2012 Content AVP value (of the grouped SIP-User-Data AVP) more data than 2013 it can accept, it MUST set the Result-Code AVP value to 2014 DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the Diameter 2015 server in a Diameter PPA message. The SIP server MUST NOT override 2016 the existing user profile with the one received in the PPR message. 2018 If the Diameter server receives the Result-Code AVP value set to 2019 DIAMETER_ERROR_TOO_MUCH_DATA in a Diameter PPA message, it SHOULD 2020 force a new re-registration of the user by sending to the Diameter 2021 client a Diameter Registration-Termination-Request (RTR) with the 2022 SIP-Deregistration-Reason AVP value set to SIP_SERVER_CHANGE. This 2023 will force a re-registration of the user, and will trigger a 2024 selection of a new SIP server. 2026 If the Diameter client is not able to honor the command, for any 2027 other reason, it MUST set the Result-Code AVP value to 2028 DIAMETER_UNABLE_TO_COMPLY and it MUST return it in a Diameter PPA 2029 message. 2031 The Message Format of the PPA command is as follows: 2033 ::= < Diameter Header: fff, PXY > 2034 < Session-Id > 2035 { Auth-Application-Id } 2036 { Result-Code } 2037 { Auth-Session-State } 2038 { Origin-Host } 2039 { Origin-Realm } 2040 [ Redirect-Host ] 2041 [ Redirect-Host-Usage ] 2042 [ Redirect-Max-Cache-Time ] 2043 * [ Proxy-Info ] 2044 * [ Route-Record ] 2045 * [ AVP ] 2047 [Note to IANA and the RFC editor: replace fff with the actual value 2048 allocated to this command] 2050 9. Diameter SIP Application AVPs 2052 This section defines new AVPs used in this Diameter SIP application. 2053 Applications compliant with this specification MUST implement these 2054 AVPs. 2056 Table 2 lists the new AVPs defined in this Diameter SIP application. 2057 The following abbreviations are used in the Data-Type column: 2059 o DURI: DiameterURI 2060 o E: Enumerated 2061 o G: Grouped 2062 o OS: OctetString 2063 o UTF8S: UTF8String 2064 o U32: Unsigned32 2066 +---------------------------------+------+----------------+---------+ 2067 | Attribute Name | AVP | Reference | Data-Ty | 2068 | | Code | | pe | 2069 +---------------------------------+------+----------------+---------+ 2070 | SIP-Accounting-Information | xx01 | Section 9.1 | G | 2071 | SIP-Accounting-Server-URI | xx02 | Section 9.1.1 | DURI | 2072 | SIP-Credit-Control-Server-URI | xx03 | Section 9.1.2 | DURI | 2073 | SIP-Server-URI | xx04 | Section 9.2 | UTF8S | 2074 | SIP-Server-Capabilities | xx05 | Section 9.3 | G | 2075 | SIP-Mandatory-Capability | xx06 | Section 9.3.1 | U32 | 2076 | SIP-Optional-Capability | xx07 | Section 9.3.2 | U32 | 2077 | SIP-Server-Assignment-Type | xx08 | Section 9.4 | E | 2078 | SIP-Auth-Data-Item | xx09 | Section 9.5 | G | 2079 | SIP-Authentication-Scheme | xx10 | Section 9.5.1 | E | 2080 | SIP-Item-Number | xx11 | Section 9.5.2 | U32 | 2081 | SIP-Authenticate | xx12 | Section 9.5.3 | G | 2082 | SIP-Authorization | xx13 | Section 9.5.4 | G | 2083 | SIP-Authentication-Info | xx14 | Section 9.5.5 | G | 2084 | SIP-Number-Auth-Items | xx15 | Section 9.6 | U32 | 2085 | SIP-Deregistration-Reason | xx16 | Section 9.7 | G | 2086 | SIP-Reason-Code | xx17 | Section 9.7.1 | E | 2087 | SIP-Reason-Info | xx18 | Section 9.7.2 | UTF8S | 2088 | SIP-Visited-Network-Id | xx19 | Section 9.9 | UTF8S | 2089 | SIP-User-Authorization-Type | xx20 | Section 9.10 | E | 2090 | SIP-Supported-User-Data-Type | xx21 | Section 9.11 | UTF8S | 2091 | SIP-User-Data | xx22 | Section 9.12 | G | 2092 | SIP-User-Data-Type | xx23 | Section 9.12.1 | UTF8S | 2093 | SIP-User-Data-Contents | xx24 | Section 9.12.2 | OS | 2094 | SIP-User-Data-Already-Available | xx25 | Section 9.13 | E | 2095 +---------------------------------+------+----------------+---------+ 2097 Table 2: Defined AVPs 2099 [Note to IANA and the RFC editor: replace xx01, xx02, xx03, and so on 2100 with the actual values allocated to these AVPs.] 2102 Table 3 expands the table of AVPs included in Section 4.5 of RFC 3588 2103 [RFC3588]. The table indicates the Diameter AVPs defined in this 2104 Diameter SIP Application, their possible flag values, and whether the 2105 AVP may be encrypted. The acronyms 'M', 'P', and 'V' refer to AVP 2106 flags whose semantics are described in RFC 3588 [RFC3588]. The value 2107 of the 'Encr' column is also described in RFC 3588 [RFC3588]. 2109 +----------------------------------+------+-----+-----+------+------+ 2110 | Attribute Name | MUST | MAY | SHD | MUST | Encr | 2111 | | | | NOT | NOT | | 2112 +----------------------------------+------+-----+-----+------+------+ 2113 | SIP-Accounting-Information | M | P | | V | N | 2114 | SIP-Accounting-Server-URI | M | P | | V | N | 2115 | SIP-Credit-Control-Server-URI | M | P | | V | N | 2116 | SIP-Server-URI | M | P | | V | N | 2117 | SIP-Server-Capabilities | M | P | | V | N | 2118 | SIP-Mandatory-Capability | M | P | | V | N | 2119 | SIP-Optional-Capability | M | P | | V | N | 2120 | SIP-Server-Assignment-Type | M | P | | V | N | 2121 | SIP-Auth-Data-Item | M | P | | V | N | 2122 | SIP-Authentication-Scheme | M | P | | V | N | 2123 | SIP-Item-Number | M | P | | V | N | 2124 | SIP-Authenticate | M | P | | V | N | 2125 | SIP-Authorization | M | P | | V | N | 2126 | SIP-Authentication-Info | M | P | | V | N | 2127 | SIP-Number-Auth-Items | M | P | | V | N | 2128 | SIP-Deregistration-Reason | M | P | | V | N | 2129 | SIP-Reason-Code | M | P | | V | N | 2130 | SIP-Reason-Info | M | P | | V | N | 2131 | SIP-Visited-Network-Id | M | P | | V | N | 2132 | SIP-User-Authorization-Type | M | P | | V | N | 2133 | SIP-Supported-User-Data-Type | M | P | | V | N | 2134 | SIP-User-Data | M | P | | V | N | 2135 | SIP-User-Data-Type | M | P | | V | N | 2136 | SIP-User-Data-Contents | M | P | | V | N | 2137 | SIP-User-Data-Already-Available | M | P | | V | N | 2138 | SIP-Method | M | P | | V | N | 2139 +----------------------------------+------+-----+-----+------+------+ 2141 Table 3: Summary of the new AVPs flags 2143 9.1. SIP-Accounting-Information AVP 2145 The SIP-Accounting-Information (AVP code xx01) [Note to IANA and the 2146 RFC editor: replace xx01 with the actual value allocated to this AVP] 2147 is of type Grouped, and contains the Diameter addresses of those 2148 nodes that are able to collect accounting information. 2150 The SIP-Accounting-Information AVP is defined as follows (per the 2151 grouped-avp-def of RFC 3588 [RFC3588]): 2153 SIP-Accounting-Information ::= < AVP Header: xx01 > 2154 * [ SIP-Accounting-Server-URI ] 2155 * [ SIP-Credit-Control-Server-URI ] 2156 * [ AVP] 2158 [Note to IANA and the RFC editor: replace xx01 with the actual value 2159 allocated to this AVP] 2161 9.1.1. SIP-Accounting-Server-URI AVP 2163 The SIP-Accounting-Server-URI AVP (AVP Code xx02) [Note to IANA and 2164 the RFC editor: replace xx02 with the actual value allocated to this 2165 AVP] is of type DiameterURI. This AVP contains the address of a 2166 Diameter server that is able to receive SIP-session-related 2167 accounting information. 2169 9.1.2. SIP-Credit-Control-Server-URI AVP 2171 The SIP-Credit-Control-Server-URI AVP (AVP Code xx03) [Note to IANA 2172 and the RFC editor: replace xx03 with the actual value allocated to 2173 this AVP] is of type DiameterURI. This AVP contains the address of a 2174 Diameter server that is able to authorize real-time credit control 2175 usage. The Diameter Credit Control Application [RFC4006] may be used 2176 for this purpose. 2178 9.2. SIP-Server-URI AVP 2180 The SIP-Server-URI AVP (AVP Code xx04) [Note to IANA and the RFC 2181 editor: replace xx04 with the actual value allocated to this AVP] is 2182 of type UTF8String. This AVP contains a SIP or SIPS URI (as defined 2183 in RFC 3261 [RFC3261]) that identifies a SIP server. 2185 9.3. SIP-Server-Capabilities AVP 2187 The SIP-Server-Capabilities AVP (AVP Code xx05) [Note to IANA and the 2188 RFC editor: replace xx05 with the actual value allocated to this AVP] 2189 is of type Grouped. The Diameter indicates in this AVP the 2190 requirements for a particular SIP capability, so that the Diameter 2191 client (SIP server) is able to select another appropriate SIP server 2192 to serve the user. 2194 The SIP-Server-Capabilities AVP allows a Diameter client (SIP server) 2195 to select another SIP server for triggering or executing services to 2196 the user. A user may have enabled some services that requires the 2197 implementation of certain capabilities in the SIP server that 2198 triggers or executes those services. For example, the SIP server 2199 that triggers or executes services to this user may need to implement 2200 SIP servlets [JSR-000116], Call Processing Language (CPL) [RFC3880], 2201 or any other kind of capability. Or perhaps that user belongs to a 2202 premium users group that have certain stringent quality of service 2203 agreement that requires a fast SIP server. The capabilities required 2204 or recommended to a given user are conveyed in the SIP-Server- 2205 Capabilities AVP. When it receives them, the Diameter client (SIP 2206 server) that does the SIP server selection, needs to have the means 2207 to find out available SIP servers that meet the required or optional 2208 capabilities. Such means are outside the scope of this 2209 specification. 2211 Note that the SIP-Server-Capabilities AVP assists the Diameter client 2212 (SIP server) to produce a subset of all the available SIP servers to 2213 be allocated to the user in the home realm; this is the subset that 2214 conforms the requirements of capabilities on a per user basis. 2215 Typically this subset will be formed of more than a single SIP 2216 server, so once the subset of those SIP servers is identified, it is 2217 possible that several instances of these SIP servers exist, in which 2218 case the Diameter client (SIP server) should choose one particular 2219 SIP server to execute and trigger services to this user. It is 2220 expected that at this point the SIP server (Diameter client) will 2221 follow the procedures of RFC 3263 [RFC3263] to allocate one SIP 2222 server to the user. 2224 The SIP-Server-Capabilities AVP is defined as follows (per the 2225 grouped-avp-def of RFC 3588 [RFC3588]): 2227 SIP-Server-Capabilities ::= < AVP Header: xx05 > 2228 * [ SIP-Mandatory-Capability ] 2229 * [ SIP-Optional-Capability ] 2230 * [ SIP-Server-URI ] 2231 * [ AVP ] 2233 [Note to IANA and the RFC editor: replace xx05 with the actual value 2234 allocated to this AVP] 2236 9.3.1. SIP-Mandatory-Capability AVP 2238 The SIP-Mandatory-Capability AVP (AVP Code xx06) [Note to IANA and 2239 the RFC editor: replace xx06 with the actual value allocated to this 2240 AVP] is of type Unsigned32. The value represents a certain 2241 capability (or set of capabilities) that have to be fulfilled by the 2242 SIP server allocated to the user. 2244 The semantics of the different values are not standardized, as it is 2245 a matter of the administrative network to allocate its own semantics 2246 within its own network. Each value has to represent a single 2247 capability within the administrative network. 2249 9.3.2. SIP-Optional-Capability AVP 2251 The SIP-Optional-Capability AVP (AVP Code xx07) [Note to IANA and the 2252 RFC editor: replace xx07 with the actual value allocated to this AVP] 2253 is of type Unsigned32. The value represents a certain capability (or 2254 set of capabilities) that, optionally, may be fulfilled by the SIP 2255 server allocated to the user. 2257 The semantics of the different values are not standardized, as it is 2258 a matter of the administrative network to allocate its own semantics 2259 within its own network. Each value has to represent a single 2260 capability within the administrative network. 2262 9.4. SIP-Server-Assignment-Type AVP 2264 The SIP-Server-Assignment-Type AVP (AVP code xx08) [Note to IANA and 2265 the RFC editor: replace xx08 with the actual value allocated to this 2266 AVP] is of type Enumerated and indicates the type of server update 2267 being performed in a Diameter Server-Assignment-Request (SAR) 2268 operation. The following values are defined: 2270 o NO_ASSIGNMENT (0) 2271 The Diameter client uses this value to request the user profile of 2272 a SIP AOR, without affecting the registration state of that 2273 identity. 2274 o REGISTRATION (1) 2275 First SIP registration of a SIP AOR. 2276 o RE_REGISTRATION (2) 2277 Subsequent SIP registration of a SIP AOR. 2278 o UNREGISTERED_USER (3) 2279 The SIP server has received a SIP request (e.g., SIP INVITE) 2280 addressed for a SIP AOR that is not registered. 2281 o TIMEOUT_DEREGISTRATION (4) 2282 The SIP registration timer of an identity has expired. 2284 o USER_DEREGISTRATION (5) 2285 The SIP server has received a request to deregister a SIP AOR. 2286 o TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6) 2287 The SIP registration timer of an identity has expired. The SIP 2288 server keeps the user data stored and requests the Diameter server 2289 to store the SIP server address. 2290 o USER_DEREGISTRATION_STORE_SERVER_NAME (7) 2291 The SIP server has received a user initiated deregistration 2292 request. The SIP server keeps the user data stored and requests 2293 the Diameter server to store the SIP server address. 2294 o ADMINISTRATIVE_DEREGISTRATION (8) 2295 The SIP server, due to administrative reasons, has deregistered a 2296 SIP AOR. 2297 o AUTHENTICATION_FAILURE (9) 2298 The authentication of a user has failed. 2299 o AUTHENTICATION_TIMEOUT (10) 2300 The authentication timer has expired. 2301 o DEREGISTRATION_TOO_MUCH_DATA (11) 2302 The SIP server has requested user profile information from the 2303 Diameter server and has received a volume of data higher than it 2304 can accept. 2306 9.5. SIP-Auth-Data-Item AVP 2308 The SIP-Auth-Data-Item (AVP code xx09) [Note to IANA and the RFC 2309 editor: replace xx09 with the actual value allocated to this AVP] is 2310 of type Grouped and contains the authentication and/or authorization 2311 information pertaining to a user. 2313 When the Diameter server uses the grouped SIP-Auth-Data-Item AVP to 2314 include a SIP-Authenticate AVP, the Diameter server MUST send a 2315 maximum of one authentication data item (e.g., in case the SIP 2316 request contained several credentials). Section 11 contains a 2317 detailed discussion and normative text of the case when a SIP request 2318 contains several credentials. 2320 The SIP-Auth-Data-Item AVP is defined as follows (per the grouped- 2321 avp-def of RFC 3588 [RFC3588]): 2323 SIP-Auth-Data-Item ::= < AVP Header: xx09 > 2324 { SIP-Authentication-Scheme } 2325 [ SIP-Item-Number ] 2326 [ SIP-Authenticate ] 2327 [ SIP-Authorization ] 2328 [ SIP-Authentication-Info ] 2329 * [ AVP ] 2331 [Note to IANA and the RFC editor: replace xx09 with the actual value 2332 allocated to this AVP] 2334 9.5.1. SIP-Authentication-Scheme AVP 2336 The SIP-Authentication-Scheme AVP (AVP code xx10) [Note to IANA and 2337 the RFC editor: replace xx10 with the actual value allocated to this 2338 AVP] is of type Enumerated and indicates the authentication scheme 2339 used in the authentication of SIP services. RFC 2617 identifies this 2340 value as an "auth-scheme" (see section 1.2 of RFC 2617 [RFC2617]). 2341 The only currently defined value is: 2343 o DIGEST (0) to indicate HTTP Digest authentication as specified in 2344 RFC 2617 [RFC2617] Section 3.2.1. Derivative work is also 2345 considered Digest authentication scheme, as long as the "auth- 2346 scheme" is identified as Digest in the SIP headers carrying the 2347 HTTP authentication. This includes, e.g., the HTTP Digest 2348 authentication using AKA [RFC3310]. 2350 Each HTTP Digest directive (parameter) is transported in a 2351 corresponding AVP, whose name follows the pattern Digest-*. The 2352 Digest-* AVPs are RADIUS attributes imported from the RADIUS 2353 Extension for Digest Authentication [I-D.ietf-radext-digest-auth] 2354 namespace, allowing a smooth transition between RADIUS and Diameter 2355 applications supporting SIP. The Diameter SIP application goes a 2356 step further by grouping the Digest-* AVPs into the SIP-Authenticate, 2357 SIP-Authorization, and SIP-Authentication-Info grouped AVPs that 2358 correspond to the SIP WWW-Authenticate/Proxy-Authentication, 2359 Authorization/Proxy-Authorization, and Authentication-Info headers 2360 fields, respectively. 2362 NOTE: Due to the fact that HTTP Digest authentication [RFC2617] is 2363 the only mandatory authentication mechanism in SIP, this memo only 2364 provides support for HTTP Digest authentication and derivative 2365 work such as HTTP Digest authentication using AKA [RFC3310]. 2366 Extensions to this memo can register new values and new AVPs to 2367 provide support for other authentication schemes or extensions to 2368 HTTP Digest authentication. 2370 NOTE: Although RFC 2617 [RFC2617] defines the Basic and Digest 2371 schemes for authenticating HTTP requests, RFC 3261 [RFC3261] only 2372 imports HTTP Digest as a mechanism to provide authentication in 2373 SIP. 2375 Due to syntactic requirements, HTTP Digest Authentication have to 2376 escape quote characters in contents of HTTP Digest directives. When 2377 translating directives into Digest-* AVPs, the Diameter client or 2378 server removes the surrounding quotes where present, as required by 2379 the syntax of the Digest-* attributes defined in the RADIUS Extension 2380 for Digest Authentication [I-D.ietf-radext-digest-auth]. 2382 9.5.2. SIP-Item-Number AVP 2384 The SIP-Item-Number (AVP code xx11) [Note to IANA and the RFC editor: 2385 replace xx11 with the actual value allocated to this AVP] is of type 2386 Unsigned32 and is included in a SIP-Auth-Data-Item grouped AVP in 2387 circumstances where there are multiple occurrences of SIP-Auth-Data- 2388 Item AVPs and the order of processing is relevant. The AVP indicates 2389 the order in which the Grouped SIP-Auth-Data-Item should be 2390 processed. Lower values of the SIP-Item-Number AVP indicate that the 2391 whole SIP-Auth-Data-Item SHOULD be processed before other SIP-Auth- 2392 Data-Item AVPs that contain higher values in the SIP-Item-Number AVP. 2394 9.5.3. SIP-Authenticate AVP 2396 The SIP-Authenticate AVP (AVP code xx12) [Note to IANA and the RFC 2397 editor: replace xx12 with the actual value allocated to this AVP] is 2398 of type Grouped and contains a reconstruction of either the SIP WWW- 2399 Authenticate or Proxy-Authentication header fields specified in RFC 2400 2617 [RFC2617] for the HTTP Digest authentication scheme. 2401 Additionally, the AVP may include a Digest-HA1 AVP that contains 2402 H(A1) (as defined in RFC 2617 [RFC2617]). H(A1) allows the Diameter 2403 client to create an expected response and compare it with the Digest 2404 response received from the SIP UA. 2406 The SIP-Authenticate AVP is defined as follows (per the grouped-avp- 2407 def of RFC 3588 [RFC3588]): 2409 SIP-Authenticate ::= < AVP Header: xx12 > 2410 { Digest-Realm } 2411 { Digest-Nonce } 2412 [ Digest-Domain ] 2413 [ Digest-Opaque ] 2414 [ Digest-Stale ] 2415 [ Digest-Algorithm ] 2416 [ Digest-QoP ] 2417 [ Digest-HA1] 2418 * [ Digest-Auth-Param ] 2419 * [ AVP ] 2421 [Note to IANA and the RFC editor: replace xx12 with the actual value 2422 allocated to this AVP] 2424 9.5.4. SIP-Authorization AVP 2426 The SIP-Authorization AVP (AVP code xx13) [Note to IANA and the RFC 2427 editor: replace xx13 with the actual value allocated to this AVP] is 2428 of type Grouped and contains a reconstruction of either the SIP 2429 Authorization or Proxy-Authorization header fields specified in RFC 2430 2617 [RFC2617] for the HTTP Digest authentication scheme. 2432 The SIP-Authorization AVP is defined as follows (per the grouped-avp- 2433 def of RFC 3588 [RFC3588]): 2435 SIP-Authorization ::= < AVP Header: xx13 > 2436 { Digest-Username } 2437 { Digest-Realm } 2438 { Digest-Nonce } 2439 { Digest-URI } 2440 { Digest-Response } 2441 [ Digest-Algorithm ] 2442 [ Digest-CNonce ] 2443 [ Digest-Opaque ] 2444 [ Digest-QoP ] 2445 [ Digest-Nonce-Count ] 2446 [ Digest-Method] 2447 [ Digest-Entity-Body-Hash ] 2448 * [ Digest-Auth-Param ] 2449 * [ AVP ] 2451 [Note to IANA and the RFC editor: replace xx13 with the actual value 2452 allocated to this AVP] 2454 9.5.5. SIP-Authentication-Info AVP 2456 The SIP-Authentication-Info AVP (AVP Code xx14) [Note to IANA and the 2457 RFC editor: replace xx14 with the actual value allocated to this AVP] 2458 is of type Grouped and contains a reconstruction of the SIP 2459 Authentication-Info header specified in RFC 2617 [RFC2617] for the 2460 HTTP Digest authentication scheme. 2462 The SIP-Authentication-Info AVP is defined as follows (per the 2463 grouped-avp-def of RFC 3588 [RFC3588]): 2465 SIP-Authentication-Info ::= < AVP Header: xx14 > 2466 { Digest-Nextnonce } 2467 [ Digest-QoP ] 2468 [ Digest-Response-Auth ] 2469 [ Digest-CNonce ] 2470 [ Digest-Nonce-Count ] 2471 * [ AVP ] 2473 [Note to IANA and the RFC editor: replace xx14 with the actual value 2474 allocated to this AVP] 2475 Note that, in some cases, the Digest-Response-Auth AVP cannot be 2476 calculated at the Diameter server, but has to be calculated at the 2477 Diameter client (SIP server). For example, if the value of the 2478 quality of protection (qop) parameter in Digest is set to "auth-int", 2479 then the response-digest (rspauth parameter value in Digest) is 2480 calculated with the hash of the body of the SIP response, which is 2481 not available at the Diameter server. In this case, the Diameter 2482 client (SIP server) must calculate the response-digest once the body 2483 of the SIP response is calculated. 2485 Therefore, a value of "auth-int" in the Digest-QoP AVP of the SIP- 2486 Authentication-Info AVP indicates that the Diameter client (SIP 2487 server) MUST compute the Digest "rspauth" parameter value at the 2488 Diameter client (SIP server). 2490 9.5.6. Digest AVPs 2492 The following AVPs are RADIUS attributes defined in the RADIUS 2493 Extension for Digest Authentication [I-D.ietf-radext-digest-auth] and 2494 imported by this specification: Digest-AKA-Auts, Digest-Algorithm, 2495 Digest-Auth-Param, Digest-CNonce, Digest-Domain, Digest-Entity-Body- 2496 Hash, Digest-HA1, Digest-Method, Digest-Nextnonce, Digest-Nonce, 2497 Digest-Nonce-Count, Digest-Opaque, Digest-QoP, Digest-Realm, Digest- 2498 Response, Digest-Response-Auth, Digest-URI, Digest-Username, and 2499 Digest-Stale. 2501 9.5.6.1. Considerations about Digest-HA1 AVP 2503 The Digest-HA1 AVP contains the value, pre-calculated at the Diameter 2504 server, of H(A1) as defined in RFC 2617 [RFC2617]. The Diameter 2505 client can use H(A1) to calculate the expected Digest response, 2506 according to this challenge. If the SIP UA is in possession of the 2507 credentials, the calculated expected response and the response sent 2508 from the SIP UA will match. The Diameter server MAY include this AVP 2509 to enable and assist the SIP server in authenticating the SIP UA. 2511 This scenario is not applicable when the Diameter server is 2512 configured to use a session MD5 (MD5-sess) algorithm, because the 2513 Diameter server requires the client nonce to compute the H(A1) before 2514 sending it to the Diameter client, and the client nonce might not be 2515 available when the computation of H(A1) is done. Therefore, if the 2516 final authentication is delegated to the Diameter client it is 2517 RECOMMENDED to configure the Diameter server to use algorithms 2518 different than MD5-sess in HTTP Digest. 2520 It is up to the Diameter server to include a Digest-HA1 AVP. The 2521 Diameter server calculates the Digest H(A1) with the username, 2522 password, realm, (and nonce and cnonce, if applicable) as inputs, and 2523 places the result in the Digest-HA1 AVP value. For more details of 2524 the A1 computation, see RFC 2617 [RFC2617] Section 3.2.2.2. The 2525 Diameter client can calculate the Digest expected response with H(A1) 2526 as input, as described in RFC 2617 [RFC2617] Section 3.2.2. 2528 Section 11 provide further normative details about the usage of the 2529 Digest-HA1 AVP. 2531 9.5.6.2. Considerations about Digest-Entity-Body-Hash AVP 2533 The Digest-Entity-Body-Hash AVP contains a hash of the entity body 2534 contained in the SIP message. This hash is required by HTTP Digest 2535 with quality of protection set to "auth-int". Diameter clients MUST 2536 use this AVP to transport the hash of the entity body when HTTP 2537 Digest is the authentication mechanism and the Diameter server 2538 requires to verify the integrity of the entity body (e.g., qop 2539 parameter set to "auth-int"). 2541 The clarifications described in Section 22.4 of RFC 3261 [RFC3261] 2542 about the hash of empty entity bodies apply to the Digest-Entity- 2543 Body-Hash AVP. 2545 9.5.6.3. Considerations about Digest-Auth-Param AVP 2547 The Digest-Auth-Param AVP is the mechanism whereby the Diameter 2548 client and Diameter server can exchange possible extension parameters 2549 contained in Digest headers that are either not understood by the 2550 Diameter client or for which there are no corresponding stand-alone 2551 AVPs. Unlike the previously listed Digest-* AVPs, the Digest-Auth- 2552 Param contains not only the value, but also the parameter name, since 2553 it is unknown to the Diameter client. The Diameter node MUST insert 2554 one Digest parameter/value combination per AVP value. If the Digest 2555 header contains several unknown parameters, then the Diameter 2556 implementation MUST repeat this AVP and each instance MUST contain 2557 one different unknown Digest parameter/value combination. This AVP 2558 corresponds to the "auth-param" parameter defined in Section 3.2.1 of 2559 RFC 2617 [RFC2617]. 2561 Example: Assume that the Diameter server wants the SIP server to send 2562 a "foo" parameter with the value set to "bar", so that the SIP server 2563 sends that combination in a SIP WWW-Authenticate header field. The 2564 Diameter server builds a grouped SIP-Authenticate AVP that contains a 2565 Digest-Auth-Param whose value is set to foo="bar". Then the SIP 2566 server creates the WWW-Authenticate header field with all the digest 2567 parameters (received in Digest-* AVPs) and adds the foo="bar" 2568 parameter to that header field. 2570 9.6. SIP-Number-Auth-Items AVP 2572 The SIP-Number-Auth-Items AVP (AVP Code xx15) [Note to IANA and the 2573 RFC editor: replace xx15 with the actual value allocated to this 2574 AVP]is of type Unsigned32 and indicates the number of authentication 2575 and/or authorization credentials that the Diameter server included in 2576 a Diameter message. 2578 When the AVP is present in a request, it indicates the number of SIP- 2579 Auth-Data-Items the Diameter client is requesting. This can be used, 2580 for instance, when the SIP server is requesting several pre- 2581 calculated authentication credentials. In the answer message, the 2582 SIP-Number-Auth-Items AVP indicates the actual number of items that 2583 the Diameter server included. 2585 9.7. SIP-Deregistration-Reason AVP 2587 The SIP-Deregistration-Reason AVP (AVP Code xx16) [Note to IANA and 2588 the RFC editor: replace xx16 with the actual value allocated to this 2589 AVP] is of type Grouped and indicates the reason for a deregistration 2590 operation. 2592 The SIP-Deregistration-Reason AVP is defined as follows (per the 2593 grouped-avp-def of RFC 3588 [RFC3588]): 2595 SIP-Deregistration-Reason ::= < AVP Header: xx16 > 2596 { SIP-Reason-Code } 2597 [ SIP-Reason-Info ] 2598 * [ AVP ] 2600 [Note to IANA and the RFC editor: replace xx16 with the actual value 2601 allocated to this AVP] 2603 9.7.1. SIP-Reason-Code AVP 2605 The SIP-Reason-Code AVP (AVP code xx17) [Note to IANA and the RFC 2606 editor: replace xx17 with the actual value allocated to this AVP] is 2607 of type Enumerated and defines the reason for the network initiated 2608 deregistration. The following values are defined: 2610 o PERMANENT_TERMINATION (0) 2611 o NEW_SIP_SERVER_ASSIGNED (1) 2612 o SIP_SERVER_CHANGE (2) 2613 o REMOVE_SIP_SERVER (3) 2615 9.7.2. SIP-Reason-Info AVP 2617 The SIP-Reason-Info AVP (AVP code xx18) [Note to IANA and the RFC 2618 editor: replace xx18 with the actual value allocated to this AVP] is 2619 of type UTF8String and contains textual information that can be 2620 rendered to the user, about the reason for a deregistration. 2622 9.8. SIP-AOR AVP 2624 The SIP-AOR AVP is a RADIUS attribute imported from the RADIUS 2625 Extension for Digest Authentication [I-D.ietf-radext-digest-auth] 2626 namespace, allowing a smooth transition between RADIUS and Diameter 2627 applications supporting SIP. The SIP-AOR AVP carries the URI of the 2628 intended user related to the SIP request (whose location in SIP may 2629 vary depending on the actual SIP request and whether the SIP server 2630 is acting on Diameter due to a SIP-originated or terminating 2631 requests). 2633 The Diameter client (SIP server) uses the value found in a SIP 2634 Request-URI or a header field value of the SIP request to construct 2635 the SIP-AOR AVP. The selection of a Request-URI or a particular 2636 header field to create the value of the SIP-AOR AVP depends on the 2637 semantics of the SIP message and whether the SIP server is acting for 2638 originating or terminating requests. For instance, when the SIP 2639 server receives an INVITE request addressed to the served user (e.g., 2640 the SIP server is receiving a terminating SIP request), it maps the 2641 SIP Request-URI of the SIP request to this AVP. However, when the 2642 SIP server receives an INVITE request originated by the served user, 2643 it can map either the P-Asserted-Identity or the From header field 2644 values to this AVP. If the SIP server is acting as a SIP registrar, 2645 then it maps the To header field of the REGISTER request to the SIP- 2646 AOR AVP. 2648 9.9. SIP-Visited-Network-Id AVP 2650 The SIP-Visited-Network-Id AVP (AVP Code xx19) [Note to IANA and the 2651 RFC editor: replace xx19 with the actual value allocated to this AVP] 2652 is of type UTF8String. This AVP contains an identifier that helps 2653 the home network identify the visited network (e.g., the visited 2654 network domain name), in order to authorize roaming to that visited 2655 network. 2657 9.10. SIP-User-Authorization-Type AVP 2659 The SIP-User-Authorization-Type AVP (AVP code xx20) [Note to IANA and 2660 the RFC editor: replace xx20 with the actual value allocated to this 2661 AVP] is of type Enumerated and indicates the type of user 2662 authorization being performed in a User Authorization operation, 2663 i.e., the Diameter User-Authorization-Request (UAR) command. The 2664 following values are defined: 2666 o REGISTRATION (0) 2667 This value is used for initial registration or re-registration. 2668 This is the default value. 2669 o DEREGISTRATION (1) 2670 This value is used for deregistration. 2671 o REGISTRATION_AND_CAPABILITIES (2) 2672 This value is used for initial registration or re-registration 2673 when the SIP server explicitly requests the Diameter server to get 2674 capability information. This capability information helps the SIP 2675 server to allocate another SIP server to serve the user. 2677 9.11. SIP-Supported-User-Data-Type AVP 2679 The SIP-Supported-User-Data-Type AVP (AVP Code xx21) [Note to IANA 2680 and the RFC editor: replace xx21 with the actual value allocated to 2681 this AVP] is of type UTF8String and contains a string that identifies 2682 the type of supported user data (user profile, see SIP-User-Data AVP 2683 (Section 9.12)) supported in the node. The AVP can be repeated, if 2684 the SIP server supports several user data types. In case of 2685 repetition, the Diameter client should order the different instances 2686 of this AVP according to its preferences. 2688 When the Diameter client inserts this AVP in a SAR message, it allows 2689 the Diameter client to provide an indication to the Diameter server 2690 of the types of user data supported by the SIP server. The Diameter 2691 server, upon inspection of these AVPs, will return a suitable SIP- 2692 User-Data AVP (Section 9.12) of the type indicated in the SIP-User- 2693 Data-Type AVP (Section 9.12.1). 2695 9.12. SIP-User-Data AVP 2697 The SIP-User-Data AVP (AVP Code xx22) [Note to IANA and the RFC 2698 editor: replace xx22 with the actual value allocated to this AVP] is 2699 of type Grouped. This AVP allows the Diameter server to transport 2700 user-specific data, such as a user profile, to the SIP server (in the 2701 Diameter client). The Diameter server selects a type of user data 2702 that is understood by the SIP server in the Diameter client, and has 2703 been indicated in a SIP-Supported-User-Data-Type AVP. In case the 2704 Diameter client indicated support for several types of user data, the 2705 Diameter server SHOULD choose the first type supported by the client. 2707 The SIP-User-Data grouped AVP contains a SIP-User-Data-Type AVP that 2708 indicates the type of user data included in the SIP-User-Data- 2709 Contents-AVP. 2711 The SIP-User-Data AVP is defined as follows (per the grouped-avp-def 2712 of RFC 3588 [RFC3588]): 2714 SIP-User-Data ::= < AVP Header: xx22 > 2715 { SIP-User-Data-Type } 2716 { SIP-User-Data-Contents } 2717 * [ AVP ] 2719 [Note to IANA and the RFC editor: replace xx22 with the actual value 2720 allocated to this AVP] 2722 9.12.1. SIP-User-Data-Type AVP 2724 The SIP-User-Data AVP (AVP Code xx23) [Note to IANA and the RFC 2725 editor: replace xx23 with the actual value allocated to this AVP] is 2726 of type UTF8String and contains a string that identifies the type of 2727 user data included in the SIP-User-Data AVP (Section 9.12). 2729 This document does not specify a convention to characterize the type 2730 of user data contained in the SIP-User-Data AVP (Section 9.12). It 2731 is believed that in most cases this feature will be used in 2732 environments controlled by a network administrator who can configure 2733 both the client and server to assign the same value type at the 2734 client and server. It is also RECOMMENDED that organizations 2735 developing their own profile of SIP-User-Data AVP (Section 9.12) 2736 allocate a type based on their canonical DNS name. For instance, 2737 organization "example.com" can define several types of SIP-User-Data 2738 and allocate the types "type1.dsa.example.com", 2739 "type2.dsa.example.com", and so on. This convention will avoid a 2740 clash in the allocation of types of SIP-User-Data AVP (Section 9.12). 2742 9.12.2. SIP-User-Data-Contents AVP 2744 The SIP-User-Data-Contents AVP (AVP Code xx24) [Note to IANA and the 2745 RFC editor: replace xx24 with the actual value allocated to this AVP] 2746 is of type OctetString. The Diameter peers do not need to understand 2747 the value of this AVP. 2749 The AVP contains the user profile data required for a SIP server to 2750 give service to the user. 2752 9.13. SIP-User-Data-Already-Available AVP 2754 The SIP-User-Data-Already-Available AVP (AVP code xx25) [Note to IANA 2755 and the RFC editor: replace xx25 with the actual value allocated to 2756 this AVP] is of type Enumerated and gives an indication to the 2757 Diameter server about whether the Diameter client (SIP server) 2758 already received the portion of the user profile needed in order to 2759 serve the user. The following values are defined: 2761 o USER_DATA_NOT_AVAILABLE (0) 2762 The Diameter client (SIP server) does not have the data that it 2763 needs to serve the user. 2764 o USER_DATA_ALREADY_AVAILABLE (1) 2765 The Diameter client (SIP server) already has received the data 2766 that it needs to serve the user. 2768 9.14. SIP-Method AVP 2770 The SIP-Method-AVP (AVP code xx26) [Note to IANA and the RFC editor: 2771 replace xx26 with the actual value allocated to this AVP] is of type 2772 UTF8String and contains the method of the SIP request that triggered 2773 the Diameter message. The Diameter server MUST use this AVP solely 2774 for authorization of SIP requests, and MUST NOT use it to compute the 2775 Digest authentication. To compute the Digest authentication, the 2776 Diameter server MUST use the Digest-Method AVP instead. 2778 10. New Values for Existing AVPs 2780 This section defines new values that the Diameter SIP application 2781 extends to already existing AVPs. 2783 10.1. Extension to the Result-Code AVP Values 2785 The Result-Code AVP is already defined in RFC 3588 [RFC3588]. In 2786 addition to the values already defined in RFC 3588 [RFC3588], the 2787 Diameter SIP application defines the following new Result-Code AVP 2788 values: 2790 10.1.1. Success Result-Code AVP Values 2792 A Diameter peer uses Result-Code AVP values that fall into the 2793 success category to inform the remote peer that a request has been 2794 successfully completed. 2796 [Note to IANA and the RFC editor: replace 2xxy with the actual values 2797 allocated to the Result-Code AVP] 2799 o DIAMETER_FIRST_REGISTRATION 2xx1 2800 The user was not previously registered. The Diameter server has 2801 now authorized the registration. 2802 o DIAMETER_SUBSEQUENT_REGISTRATION 2xx2 2803 The user is already registered. The Diameter server has now 2804 authorized the re-registration. 2806 o DIAMETER_UNREGISTERED_SERVICE 2xx3 2807 The user is not currently registered, but the requested service 2808 can still be granted to the user. 2809 o DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2xx4 2810 The request operation was successfully processed. The Diameter 2811 server does not keep a record of the SIP server address assigned 2812 to the user. 2813 o DIAMETER_SERVER_SELECTION 2xx5 2814 The Diameter server has authorized the registration. The user has 2815 already been assigned a SIP server, but it may be necessary to 2816 select a new SIP server for the user. 2817 o DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED 2xx6 2818 The requested operation was successfully executed. The Diameter 2819 server is sending a number of authentication credentials in the 2820 answer message. The Diameter server does not keep a record of the 2821 SIP server. 2823 10.1.2. Transient Failures Result-Code AVP Values 2825 A Diameter peer uses a Result-Code AVP value that falls in the 2826 transient failures category to inform the remote peer that a request 2827 could not be satisfied at the time it was received, but it MAY be 2828 satisfied by the Diameter peer in the future. 2830 [Note to IANA and the RFC editor: replace 4xxy with the actual values 2831 allocated to the Result-Code AVP] 2833 o DIAMETER_USER_NAME_REQUIRED 4xx1 2834 The Diameter request did not contain a User-Name AVP, which is 2835 required to complete the transaction. The Diameter peer MAY 2836 include a User-Name AVP and attempt the request again. 2838 10.1.3. Permanent Failures Result-Code AVP Values 2840 A Diameter peer uses a Result-Code AVP value that falls into the 2841 permanent failure category to inform the remote peer that the request 2842 failed and should not be attempted again. 2844 [Note to IANA and the RFC editor: replace 5xxy with the actual values 2845 allocated to the Result-Code AVP] 2847 o DIAMETER_ERROR_USER_UNKNOWN 5xx1 2848 The SIP-AOR AVP value does not belong to a known user in this 2849 realm. 2850 o DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5xx2 2851 The value in one of the SIP-AOR AVPs is not allocated to the user 2852 specified in the User-Name AVP. 2854 o DIAMETER_ERROR_IDENTITY_NOT_REGISTERED 5xx3 2855 A query for location information is received for a SIP AOR that 2856 has not been registered before. The user to which this identity 2857 belongs cannot be given service in this situation. 2858 o DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5xx4 2859 The user is not allowed to roam to the visited network. 2860 o DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5xx5 2861 The identity being registered has already been assigned a server 2862 and the registration status does not allow that it is overwritten. 2863 o DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED 5xx6 2864 The authentication scheme indicated in an authentication request 2865 is not supported. 2866 o DIAMETER_ERROR_IN_ASSIGNMENT_TYPE 5xx7 2867 The SIP server address sent in the SIP-Server-URI AVP value of the 2868 Diameter Server-Assignment-Request (SAR) command is the same SIP 2869 server address that is currently assigned to the user name, but 2870 the SIP-Server-Assignment-Type AVP is not allowed. For example, 2871 the user is registered and the Server-Assignment-Request indicates 2872 the assignment for an unregistered user. 2873 o DIAMETER_ERROR_TOO_MUCH_DATA 5xx8 2874 The Diameter peer in the SIP server receives more data than it can 2875 accept. The SIP server cannot overwrite the already stored data. 2876 o DIAMETER_ERROR_NOT SUPPORTED_USER_DATA 5xx9 2877 The SIP server informs the Diameter server that the received 2878 subscription data contained information that was not recognized or 2879 supported. 2881 11. Authentication Details 2883 Authenticating a user can occur through various mechanisms. 2884 Currently HTTP Digest authentication is supported. The actual 2885 authentication is performed in either the SIP server or the Diameter 2886 server. 2888 If the Diameter server wants to assure that authentication will take 2889 place in the Diameter server (as opposed to a delegated 2890 authentication taking place in the SIP server), it MUST NOT include a 2891 Digest-HA1 AVP (part of the grouped SIP-Authenticate AVP which in 2892 turn is part of the SIP-Auth-Data-Item AVP) in a MAA message. The 2893 Diameter server MAY include a pre-calculated Digest-HA1 AVP in the 2894 MAA message if it wants to delegate authentication of the user to the 2895 SIP server. 2897 Note that on systems where the SIP User Agent is using HTTP Digest 2898 authentication [RFC2617] inside of TLS [RFC2246], where only the SIP 2899 proxy server has a certificate, delegating authentication to the SIP 2900 server (by making Digest-HA1 available to the SIP server) might 2901 reduce the load on the Diameter server. 2903 When requesting authentication, the Diameter client indicates in the 2904 SIP-Number-Auth-Items AVP value of a Diameter MAR message how many 2905 authentication credentials are being requested. In the Diameter MAA 2906 message, the Diameter server MAY include more than one SIP-Auth-Data- 2907 Item AVP, but it is only useful for the Diameter client if the 2908 Digest-QoP AVP was set to 'auth-int' (in the MAR message), and if 2909 future authentications will have the same realm. When including more 2910 than one SIP-Auth-Data-Item AVP, the Diameter server SHOULD indicate 2911 how many instances of SIP-Auth-Data-Item AVPs are present with the 2912 SIP-Number-Auth-Items AVP. This number may be different from the one 2913 requested in the Diameter MAR message. If multiple SIP-Auth-Data- 2914 Item AVPs are present, and their ordering is significant, the 2915 Diameter server MUST include a SIP-Item-Number AVP in each grouping 2916 to indicate the order. The SIP-Authentication-Scheme AVP indicates 2917 "Digest" and the SIP-Authenticate AVP contains data (typically a 2918 challenge of some kind) that the user can use for her authentication. 2919 The grouped SIP-Authorization AVP contains the AVPs that conform to 2920 the response expected from the user. 2922 If the Diameter server performs the authentication of the user, the 2923 Diameter MAR message that the Diameter client sends to the Diameter 2924 server MUST include all the authentication credentials supplied by 2925 the SIP UA (there might be more than one credential, e.g., different 2926 realms, authentication of proxies, etc.). Each credential is 2927 inserted in a grouped SIP-Authorization AVP (part of the grouped SIP- 2928 Auth-Data-Item AVP). The Diameter client MUST insert a SIP-Number- 2929 Auth-Items AVP with the value set to the number of credentials 2930 enclosed. If necessary, the Digest-Entity-Body-Hash AVP will contain 2931 a hash of the body, needed to perform the authentication. If the 2932 authentication is successful, the Diameter MAA message will contain a 2933 Result-Code AVP indicating success, and if necessary, the Diameter 2934 server MAY include one or more SIP-Auth-Data-Item AVPs to provide 2935 further authentication credentials to the SIP server. If the 2936 authentication is unsuccessful due to missing credentials, the 2937 Diameter MAA message will include an SIP-Auth-Data-Item AVP with the 2938 SIP-Authentication-Scheme and SIP-Authenticate AVPs containing data 2939 (typically a challenge of some kind) that the user can use to 2940 authenticate itself. 2942 There are situations where a SIP request traverses several proxies, 2943 and each of the proxies request to authenticate the SIP UA. In this 2944 situation, it is a valid scenario that a SIP request received at a 2945 SIP server contains several sets of credentials. The 'realm' 2946 directive in HTTP is the key that the Diameter client can use to 2947 determine which credential is applicable. Also, none of the realms 2948 may be of interest to the Diameter client, in which case the Diameter 2949 client MUST consider that no credentials (of interest) were sent. In 2950 any case, a Diameter client MUST send zero or exactly one credential 2951 to the Diameter server. The Diameter client MUST choose the 2952 credential based on the 'realm' directive in the Authorization/ 2953 Proxy-Authorization header field, and it MUST match the realm of the 2954 Diameter client. 2956 It must be noted that nonces are always generated in the Diameter 2957 server. 2959 12. Migration from RADIUS 2961 RADIUS offers support for HTTP Digest authentication in the RADIUS 2962 Extension for Digest Authentication [I-D.ietf-radext-digest-auth]. A 2963 number of AVPs (the Digest-* AVPs) of this Diameter SIP application 2964 are imported from the RADIUS attributes namespace, thus making the 2965 migration from RADIUS to Diameter smooth. 2967 Note that the RADIUS Extension for Digest Authentication 2968 [I-D.ietf-radext-digest-auth] provides a more limited scope than this 2969 Diameter SIP application. Specifically, the RADIUS extension for 2970 Digest Authentication merely provides support for HTTP Digest 2971 authentication, whereas the Diameter SIP application provides support 2972 for user location, profile downloading and update, etc. 2974 The following sections discuss several configurations in which a 2975 gateway translates RADIUS to Diameter and vice versa: 2977 12.1. Gateway from RADIUS Client to Diameter Server 2979 The gateway maps Access-Request messages to MAR request. If a RADIUS 2980 Access-Request message contains at least one Digest-* attribute, the 2981 gateway maps all Digest-* attributes to the AVPs of a Diameter SIP- 2982 Authorization AVP, constructs a MAR message and sends it to the 2983 Diameter server. If the RADIUS Access-Request message does not 2984 contain any Digest-* attribute, then RADIUS client does not want to 2985 apply HTTP Digest authentication, in which case, actions at the 2986 gateway are outside the scope of this document. 2988 The Diameter Server responds with a MAA message. If the MAA message 2989 contains a Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH 2990 and contains challenge parameters in a SIP-Authenticate AVP, then the 2991 gateway translates the AVPs of SIP-Authenticate AVP and puts the 2992 resulting RADIUS attributes into an Access-Challenge message. It 2993 sends the Access-Challenge message to the RADIUS client. 2995 If the MAA message contains a SIP-Authentication-Info and a Digest- 2996 Response AVP, the gateway converts these AVPs to the corresponding 2997 RADIUS attributes and constructs a RADIUS message. If the Result- 2998 Code AVP is DIAMETER_SUCCESS, an Access-Accept is sent. In all other 2999 cases, an Access-Reject is sent. 3001 12.2. Gateway from Diameter Client to RADIUS Server 3003 The Diameter client sends a Diameter MAR message to the gateway. If 3004 the MAR message does not contain SIP-Auth-Data-Item AVPs, the gateway 3005 constructs an Access-Request message and maps the SIP-AOR and SIP- 3006 Method AVPs to RADIUS attributes. The gateway sends the Access- 3007 Request message to the RADIUS server which will respond with an 3008 Access-Challenge. The gateway creates a MAA message with a Result- 3009 Code AVP set to DIAMETER_MULTI_ROUND_AUTH and maps the Digest-* 3010 attributes to Diameter AVPs in a SIP-Authenticate AVP. The gateway 3011 sends the resulting MAA to the Diameter client, which will respond 3012 with a new MAR. 3014 The gateway checks the SIP-Auth-Data-Item AVPs of this MAR for an AVP 3015 where the Digest-Realm AVP matches the locally configured realm 3016 value. It takes the AVPs from this SIP-Auth-Data-Item AVP, converts 3017 them into the corresponding RADIUS attributes and constructs a RADIUS 3018 Access-Request message. The gateway sends the Access-Request message 3019 to the RADIUS server. If the RADIUS server responds with an Access- 3020 Accept message, the gateway converts the RADIUS attributes to 3021 Diameter AVPs, constructs a MAA message with a Result-Code AVP set to 3022 DIAMETER_SUCCESS and sends this message to the Diameter client. If 3023 the RADIUS server responds with an Access-Reject message, the gateway 3024 converts the RADIUS attributes to Diameter AVPs, constructs a MAA 3025 message with a Result-Code AVP set to 3026 DIAMETER_ERROR_IDENTITIES_DONT_MATCH, and sends this message to the 3027 Diameter client. 3029 12.3. Known Limitations 3031 As mentioned earlier, there is not a 100% match between the Diameter 3032 SIP application and the RADIUS Extension for Digest Authentication 3033 [I-D.ietf-radext-digest-auth]. In particular, the RADIUS Extension 3034 for Digest Authentication [I-D.ietf-radext-digest-auth] does not 3035 offer equivalent functionality to the Diameter UAR/UAA, SAR/SAA, LIR/ 3036 LIA, RTR/RTA, and PPR/PPA messages defined by this specification. 3038 13. IANA Considerations 3040 This document serves as IANA registration request for a number of 3041 items that should be registered in the AAA parameters registry. 3043 13.1. Application Identifier 3045 This document defines a standards-track Application-ID that falls 3046 into the Application Identifier standards-track address space defined 3047 by RFC 3588 [RFC3588] Section 11.3. This Application-ID should be 3048 registered in the Application IDs sub-registry of the AAA parameters 3049 registry with the following data: 3051 ID values Name Reference 3052 ----------- ------------------------ --------- 3053 XXX Diameter Session Initiation [RFC YYYY] 3054 Protocol (SIP) Application 3056 [Note to IANA and the RFC Editor: replace XXX with the allocated 3057 number, YYYY with the RFC number of this specification] 3059 13.2. Command Codes 3061 This document defines new standard commands whose Command Codes are 3062 to be allocated within the standard permanent Command Codes address 3063 space defined in RFC 3588 [RFC3588] Section 11.2.1. These command 3064 codes should be registered in the Command Codes sub-registry of the 3065 AAA parameters registry. 3067 Table 1 in Section 8 contains the detailed list of Command Code names 3068 and values that are part of this Diameter application. 3070 13.3. AVP Codes 3072 This document defines new standard AVPs, whose AVP Codes are to be 3073 allocated within the AVP Codes address space defined in RFC 3588 3074 [RFC3588] Section 11.4. These AVP codes should be registered in the 3075 AVP Codes sub-registry of the AAA parameters registry. 3077 Table 2 in Section 9 contains the detailed list of AVP names and AVP 3078 codes that are part of this Diameter application. 3080 13.4. Additional Values for the Result-Code AVP Value 3082 This document defines new standard Result-Code AVP values to be 3083 allocated within the Result-Code AVP address space defined in RFC 3084 3588 [RFC3588] Section 14.4.1. These values should be listed in the 3085 Result-Code AVP values section of the AVP Specific Values sub- 3086 registry of the AAA parameters registry. 3088 Section 10.1.1 lists the new Result-Code AVP values that fall into 3089 the success category, according to RFC 3588 [RFC3588] Section 7.1.2. 3091 Section 10.1.2 lists the new Result-Code AVP values that fall into 3092 the transient failure category, according to RFC 3588 [RFC3588] 3093 Section 7.1.4. 3095 Section 10.1.3 lists the new Result-Code AVP values that fall into 3096 the permanent failures category, according to RFC 3588 [RFC3588] 3097 Section 7.1.5. 3099 13.5. Creation of the SIP-Server-Assignment-Type section in the AAA 3100 registry 3102 This document defines a new SIP-Server-Assignment-Type AVP (see 3103 Section 9.4). This AVP is of type Enumerated. We define an initial 3104 set of values which should be registered by IANA. IANA should create 3105 a new "SIP-Sever-Assignment-Type AVP values" section under the AVP 3106 Specific Values sub-registry of the AAA parameters registry. The 3107 initial list of values is listed in Section 9.4. 3109 13.6. Creation of the SIP-Authentication-Scheme section in the AAA 3110 registry 3112 This document defines a new SIP-Authentication-Scheme AVP (see 3113 Section 9.5.1). This AVP is of type Enumerated. We currently define 3114 a single value that should be registered by IANA. IANA should create 3115 a new "SIP-Authentication-Scheme AVP values" section under the AVP 3116 Specific Values sub-registry of the AAA parameters registry. The 3117 initial list of values is included in Section 9.5.1. 3119 13.7. Creation of the SIP-Reason-Code section in the AAA registry 3121 This document defines a new SIP-Reason-Code AVP (see Section 9.7.1). 3122 This AVP is of type Enumerated. We define an initial set of values 3123 which should be registered by IANA. IANA should create a new "SIP- 3124 Reason-Code AVP values" section under the AVP Specific Values sub- 3125 registry of the AAA parameters registry. The initial list of values 3126 is listed in Section 9.7.1. 3128 13.8. Creation of the SIP-User-Authorization-Type section in the AAA 3129 registry 3131 This document defines a new SIP-User-Authorization-Type AVP (see 3132 Section 9.10). This AVP is of type Enumerated. We define an initial 3133 set of values which should be registered by IANA. IANA should create 3134 a new "SIP-User-Authorization-Type AVP values" section under the AVP 3135 Specific Values sub-registry of the AAA parameters registry. The 3136 initial list of values is listed in Section 9.10. 3138 13.9. Creation of the SIP-User-Data-Already-Available section in the 3139 AAA registry 3141 This document defines a new SIP-User-Data-Already-Available AVP (see 3142 Section 9.13). This AVP is of type Enumerated. We define an initial 3143 set of values which should be registered by IANA. IANA should create 3144 a new "SIP-User-Data-Already-Available AVP values" section under the 3145 AVP Specific Values sub-registry of the AAA parameters registry. The 3146 initial list of values is listed in Section 9.13. 3148 14. Security Considerations 3150 This memo does not describe a stand-alone protocol, but a particular 3151 application for the Diameter protocol [RFC3588]. Consequently, all 3152 the security considerations applicable to Diameter automatically 3153 apply to this memo. In particular, Section 13 of RFC 3588 applies to 3154 this memo. 3156 This Diameter SIP application allows a Diameter client to use the 3157 properties of HTTP Digest authentication [RFC2617] by evaluating or 3158 sending to the Diameter server the credentials supplied by a user. 3159 The discussion of HTTP Digest authentication in Section 4 of RFC 2617 3160 [RFC2617] is also applicable to this memo. 3162 This Diameter SIP application also allows a Diameter client to use 3163 the properties of HTTP Digest authentication using AKA [RFC3310] by 3164 evaluating or sending to the Diameter server the credentials supplied 3165 by a user. Section 5 of RFC 3310 [RFC3310] is also applicable to 3166 this memo. 3168 14.1. Final Authentication Check in the Diameter Client/SIP server 3170 The Diameter SIP application can be configured to operate in a 3171 scenario where the final authentication check is performed in the 3172 Diameter client (SIP server). There are a number of security 3173 considerations associated to it, all of them are consequence of the 3174 requirement to transfer H(A1) from the Diameter server to the 3175 Diameter client: 3177 o Both Diameter client and server must trust each other, such as 3178 when both client and server belong to the same administrative 3179 domain. 3180 o To avoid eavesdroppers, the transport protocol between the 3181 Diameter client and server MUST be secured. RFC 3588 [RFC3588] 3182 specifies TLS [RFC2246] and IPSec as possible transport protection 3183 mechanisms for Diameter. 3185 Due to these security considerations, it is RECOMMENDED to configure 3186 the Diameter SIP application to operate in the mode where the final 3187 authentication check is performed in the Diameter server. 3189 15. Contributors 3191 The authors would like to thank the following contributors who made 3192 substantial contributions to this work: 3194 Pete McCann Lucent 3195 Jaakko Rajaniemi Nokia 3197 Wolfgang Beck (Deutsche Telekom AG) provided the text in the 3198 Migration to RADIUS Section. 3200 16. Acknowledgements 3202 The authors would like to thank Tony Johansson and Kevin Purser for 3203 their invaluable contribution to the start-up of this application and 3204 the continuous progress. The authors would like to thank Daniel 3205 Warren, Jayshree Bharatia, Kuntal Chowdhury, Jari Arkko, Avi Lior, 3206 Wolfgang Beck, Ulrich Wiehe, Cullen Jennings, Anu Leinonen, Glen 3207 Zorn, German Blanco, Mikko Aittola, Bert Wijnen, and Sam Hartman for 3208 their reviews and valuable comments. 3210 The Diameter SIP Application is based on the Diameter Application for 3211 the Cx interface of the 3GPP IP Multimedia Subsystem [3GPP.29.229]. 3212 The authors would like to thank 3GPP Working Group CN4 for this work. 3214 17. Changes With Respect Previous Versions 3216 Note to the RFC editor: Delete this section before publication as 3217 RFC. 3219 17.1. Changes in draft-ietf-aaa-diameter-sip-app-10.txt from -00.txt 3221 o Now there can be only one Redirect-Host AVP in a given Diameter 3222 answer command. The motivation is that the data pertaining to a 3223 given user is stored in only a single Diameter server, thus, there 3224 is not room for repeatibility of this AVP. 3225 o The text has been clarified in several parts making it consistent 3226 with the idea of a single Diameter server for a given user. 3228 17.2. Changes in draft-ietf-aaa-diameter-sip-app-09.txt from -08.txt 3230 o A number of editorial changes as suggested by the RFC Editor, as 3231 part of the Early Copy Edit experiment. 3232 o Added reference to RFC 3588 to indicate that Message Formats in 3233 commands and AVPs are based on the grammar defined in RFC 3588. 3234 o Fixed a bug in Section 5.9 that suggested a DE-REGISTRATION value 3235 was possible for the SIP-Server-Assignment-Type AVP. That value 3236 does not exist. Instead, there are a number of deregistration 3237 values. 3238 o Some normative text in Section 7.10 was affecting the behaviour of 3239 SIP servers, with respect subscriptions to the SIP "reg" event 3240 package. Since the SIP aspects are outside the scope of this 3241 document, the text has been reworded in an informative way. 3242 o Added an informative reference to the SIP "reg" event package, RFC 3243 3680. 3245 17.3. Changes in draft-ietf-aaa-diameter-sip-app-08.txt from -07.txt 3247 o This version of the specification added support for the generation 3248 of nonces in the Diameter client. This change had impact 3249 throughout the whole document. 3250 o Fixed some errors indicating that the final verification of the 3251 user's credentials could only take place in the Diameter client if 3252 client nonces weren't used. Now the text clarifies that this 3253 scenario is not possible when the combination of client nonces and 3254 MD5-sess happens. 3255 o The Migration from RADIUS Section has been imported from the 3256 RADIUS draft. 3258 17.4. Changes in draft-ietf-aaa-diameter-sip-app-07.txt from -06.txt 3260 o Added Table 3 that includes a summary of all the AVPs defined by 3261 this specification are the AVP flags. 3262 o Title in Section 5.4 is changed to "SIP Server Requests 3263 Authentication and Authorization" 3264 o Fixed typo in Section 7.7 that compared MAR with UAR (about 3265 storing state). The comparison should have been done with SAR. 3266 o Section 8.5 wrongly indicated that the Diameter client could send 3267 a SIP-Authenticate AVP. Actually, the Diameter *** server *** is 3268 the peer that sends SIP-Authenticate AVPs. 3269 o The draft used to speak about "authentication vectors". The 3270 terminology has been replaced by "a number of authentication 3271 credentials", which is more aligned with HTTP Digest. 3272 o On Section 10, a paragraph that used to couple Digest-HA1 with the 3273 qop value has been removed: it was a left over from a previous 3274 version of the document. 3276 17.5. Changes in draft-ietf-aaa-diameter-sip-app-06.txt from -05.txt 3278 o The SIP-AOR AVP is now imported from the RADIUS Extension for 3279 Digest Authentication [I-D.ietf-radext-digest-auth]. More 3280 information of how to derive the SIP-AOR from the SIP message is 3281 provided. 3282 o The Authentication Details section now tries to clarify the 3283 possibility of delegation of authentication to the SIP server, and 3284 cases where it might unload the Diameter server. 3286 17.6. Changes in draft-ietf-aaa-diameter-sip-app-05.txt from -04.txt 3288 o The Digest-* AVPs are imported from the RADIUS Extension for 3289 Digest Authentication [I-D.ietf-radext-digest-auth]. An 3290 introduction paragraph has been added in Section 9.5.1. 3291 o As a side effect of the above change, the SIP-Authentication- 3292 Context disappeared. This was a grouped AVP that only contained a 3293 Digest-Entity-Body-Hash AVP. The latter will remain (in the 3294 RADIUS draft). 3295 o The Digest-Expected-Response was considered not secure enough. 3296 Instead, the Digest-Expected-Response has been replaced by Digest- 3297 HA1, which contains a hash of A1 (see RFC 2617 [RFC2617] Section 3298 3.2.2 for more details. This allows the Diameter server to 3299 delegate the final authentication to the Diameter client in a 3300 secure way. The Digest-HA1 AVP is also imported from RADIUS 3301 Extension for Digest Authentication [I-D.ietf-radext-digest-auth]. 3302 o The Digest-Digest-URI has been renamed as Digest-URI, as it is now 3303 imported from RADIUS Extension for Digest Authentication 3304 [I-D.ietf-radext-digest-auth]. 3305 o The SIP-Accounting-Information AVP was originally specified in the 3306 SAA command. It has been also added to the PPR command, so that 3307 it is possible that PPR updates the addresses of the accounting 3308 servers. 3309 o It has been clarified that when the Diameter client receives a 3310 answer command that contains the Result-Code AVP set to 3311 DIAMETER_USER_NAME_REQUIRED the SIP server will typically request 3312 authentication. Previously, the description seemed to indicate 3313 that this typical action applied to any Result-Code. 3314 o The TEL URI (RFC 2806bis) is now known as RFC 3966. 3315 o If multiple SIP proxies are authenticating the user, the SIP 3316 request may contain several Proxy-Authorization headers. The 3317 Diameter server cannot send all the credentials, since the 3318 Diameter server may be serving several common realms for which 3319 credentials exist. In this situation the Diameter server will not 3320 known which credentials to use. It has been clarified that the 3321 Diameter client MUST send only one set of credentials at a time, 3322 those belonging to the served realm. 3324 o Reference added to RFC 3588 when a Subscriber Locator Function can 3325 populate the Redirect-Host-Usage with the value ALL_USER. 3326 o The IANA registration section has clarified what are the registry 3327 and sub-registries where IANA needs to take an action. 3329 17.7. Changes in draft-ietf-aaa-diameter-sip-app-04.txt from -03.txt 3331 o DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED and 3332 DIAMETER_SUCCESS_SERVER_NOT_STORED have the same semantics: the 3333 former is kept, the latter is deleted. 3334 o Added a new Digest-Method AVP. This AVP contains the method used 3335 to compute the Digest authentication, and it is independent from 3336 the SIP-Method AVP. It has been clarified that Digest-Method is 3337 used for authentication whereas SIP-Method is used for 3338 authorization. 3339 o SIP-User-Data-Request-Type AVP is removed. Its purpose was to 3340 retrieve a fraction of the user profile. This seems to create 3341 expensive complexity, and we don't seem to have requirements to 3342 support this function anymore. 3343 o Fixed the general section layout. Some sections got, by accident, 3344 buried in deep level section. 3345 o The grouped SIP-Authenticate AVP allowed multiple instances of the 3346 Digest-Expected-Response AVP. However, since there can be only 3347 one expected response computed at the Diameter server, we now 3348 allow a single Digest-Expected-Response. 3349 o A note is added indicating that if Digest-Qop is set to "auth-int" 3350 in the SIP-Authentication-Info AVP, then the Diameter client (SIP 3351 server) is responsible to compute the "rspauth" value in the 3352 Digest Authentication-Info header. 3353 o This version of the draft provides support to identify the type of 3354 user data included in the SIP-User-Data AVP (this can contain a 3355 user profile). The following changes has been made: 3356 o 3357 * Added a new SIP-Supported-User-Data-Type AVP. 3358 * The old SIP-User-Data AVP is now a grouped AVP that contains 3359 two AVPs: SIP-User-Data-Type and SIP-User-Data-Contents. 3360 * Added a new SIP-User-Data-Type AVP. 3361 * Added a new SIP-User-Data-Contents (that contains the profile). 3362 This is equivalent to the old SIP-User-Data AVP. 3363 * All the above AVPs are visible in SAR, SAA, and PPR commands. 3364 * The new SIP-User-Data and SIP-Supported-User-Data-Type allows 3365 repetition (a server could potential send more than one 3366 profile; a client can express support for more than one type of 3367 profile). 3368 o Fixed a typo that defined the SIP-Visited-Network-Id AVP as an 3369 OctetString AVP rather than UTF-8. 3371 17.8. Changes in draft-ietf-aaa-diameter-sip-app-03.txt from -02.txt 3373 o A Diameter Subscriber Locator was either a Diameter Relay or a 3374 Diameter Redirect node. We have removed the Diameter Relay 3375 functionality, since Diameter relays will not relay CER/CEA 3376 messages, thus, a Diameter client will never be able to determine 3377 which Diameter applications are running in a given Diameter 3378 server. So a Diameter Subscriber Locator is implemented as a 3379 Diameter redirect node. 3380 o Section "Registration termination" has been rewritten. Now the 3381 procedures speak about SIP soft state management, rather than SIP 3382 registration, so this procedures are applicable to SIP event 3383 subscriptions as well. A discussion on how to couple Diameter 3384 user sessions with SIP soft states is also added 3385 o Added a new Digest-Expected-Response AVP that allows the Diameter 3386 server to send a pre-calculated expected digest response to the 3387 Diameter client. This is only applicable to the case when the SIP 3388 UA does not use client nonces. 3389 o The Authentication Details Section has been updated with the 3390 latest details of the authentication process. 3392 17.9. Changes in draft-ietf-aaa-diameter-sip-app-02.txt from -01.txt 3394 o We have changed the type of the SIP-Authenticate, SIP- 3395 Authorization, SIP-Authentication-Info AVPs. Now, each is a 3396 grouped AVP and contains one or more AVPs that maps to the 3397 corresponding Digest parameter. This means that the Diameter 3398 server will receive in a different AVP each of the values of the 3399 different parameters contained in the Digest headers. This 3400 approach relieves the Diameter server of implementing a SIP parser 3401 to determine the values of each of the parameters. 3402 o Specifically added support for Digest AKA operation, as per RFC 3403 3310 [RFC3310]. A Digest-AKA-Auts AVP is added. 3404 o List of authors trimmed. Contributors section added. 3405 o The SIP-Entity-Body-Hash is renamed to Digest-Entity-Body-Hash to 3406 be aligned with the rest of the Digest-* AVPs. 3407 o The NAS-Session-Key AVP has been deleted. We never knew why this 3408 AVP was here. 3409 o We have removed the support for key distribution. Specifically we 3410 have removed the Confidentiality-Key and Integrity-Key AVPs. 3412 17.10. Changes in draft-ietf-aaa-diameter-sip-app-01.txt from -00.txt 3414 o The SIP-Authentication-Info AVP was mistakenly typed as 3415 OctetString. We changed it to UTF8String. Since SIP is encoded 3416 in UTF8String, there is no point in having an OctetString AVP 3417 here. 3419 o The SIP-Authentication-Context AVP is changed to be a grouped AVP. 3420 It contains a SIP-Entity-Body-Hash AVP that contains the hash of 3421 the entity body (e.g., the hash of the SDP [RFC2327]). This is 3422 because some authentication mechanisms require to make a hash of 3423 the entity body. Instead of sending the whole entity body to the 3424 Diameter server, it is more efficient to send the hash of the 3425 body. 3426 o Added a descriptive text indicating the intended use/actions of 3427 each command. 3428 o Removed references to PGP since it is deprecated in SIP. 3429 o We have focused on providing support for HTTP Digest 3430 authentication in SIP, since it is the mandatory authentication 3431 mechanism in SIP. Other documents can extend this one adding 3432 support for other authentication mechanisms if that is required in 3433 the future. 3434 o Added a Security Considerations section. 3435 o The scenario "Diameter server authenticates the user" had an 3436 error, because it was assuming that the MAR/MAA commands were used 3437 to download the user profile. However, MAR/MAA do not contain 3438 provisions to download any user profile. The solution is to add a 3439 SAR/SAA commands that allow the SIP server to get the user profile 3440 stored in the Diameter server. 3441 o Added the missing Redirect-Host-Usage and Redirect-Max-Cache-Time 3442 to all the answers. 3444 17.11. Changes in draft-ietf-aaa-diameter-sip-app-00.txt from 3445 draft-belinchon-aaa-diameter-mm-app-01.txt 3447 o Application name changed to Diameter SIP application. 3448 o New Definitions section added. 3449 o New Applicability section added. 3450 o The problem of locating a Diameter server is addressed with the 3451 introduction of a new Diameter Subscriber Locator role. 3452 o Added new scenarios to indicate usage in a more generic Internet 3453 environment. 3454 o A few AVPs have been renamed to accurately reflect the intention 3455 of the AVP. For instance, SIP-Server-Name becomes SIP-Server-URI, 3456 and SIP-Public-User-ID becomes SIP-AOR. 3457 o MAR command can be used more generically. Particularly, it does 3458 not assume a SIP REGISTER message. So we had to add a new SIP- 3459 Method AVP to indicate the SIP method that triggered the MAR 3460 command. 3461 o User-Name is no longer mandatory in requests, as typically a SIP 3462 request will not contain a user name. As a result of this change, 3463 a new transit failure Result-Code AVP value has been added: 3464 DIAMETER_USER_NAME_REQUIRED, to indicate the Diameter client that 3465 the request didn't include a User-Name AVP and it is required to 3466 process it. Typically, SIP servers, upon reception of this 3467 Result-Code AVP value, will generate a SIP 401 (Unauthorized) or 3468 SIP 407 (Proxy Authentication Required) to request the user name 3469 from the user. 3470 o IANA section has been carefully rewritten to give detailed 3471 instructions to IANA on what is required to register. 3473 18. References 3475 18.1. Normative References 3477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3478 Requirement Levels", BCP 14, RFC 2119, March 1997. 3480 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 3481 Leach, P., Luotonen, A., and L. Stewart, "HTTP 3482 Authentication: Basic and Digest Access Authentication", 3483 RFC 2617, June 1999. 3485 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3486 A., Peterson, J., Sparks, R., Handley, M., and E. 3487 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3488 June 2002. 3490 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 3491 Protocol (HTTP) Digest Authentication Using Authentication 3492 and Key Agreement (AKA)", RFC 3310, September 2002. 3494 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 3495 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3497 [I-D.ietf-radext-digest-auth] 3498 Sterman, B., "RADIUS Extension for Digest Authentication", 3499 draft-ietf-radext-digest-auth-08 (work in progress), 3500 April 2006. 3502 18.2. Informative References 3504 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 3505 RFC 2246, January 1999. 3507 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 3508 Protocol", RFC 2327, April 1998. 3510 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 3511 Protocol (SIP): Locating SIP Servers", RFC 3263, 3512 June 2002. 3514 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 3515 Package for Registrations", RFC 3680, March 2004. 3517 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 3518 Language (CPL): A Language for User Control of Internet 3519 Telephony Services", RFC 3880, October 2004. 3521 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 3522 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 3523 August 2005. 3525 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 3526 "Diameter Network Access Server Application", RFC 4005, 3527 August 2005. 3529 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 3530 Loughney, "Diameter Credit-Control Application", RFC 4006, 3531 August 2005. 3533 [3GPP.29.229] 3534 3GPP, "Cx and Dx interfaces based on the Diameter 3535 protocol; Protocol details", 3GPP TS 29.229 5.11.0, 3536 October 2005. 3538 [JSR-000116] 3539 Java Community Process, "SIP Servlet API Specification 1.0 3540 Final Release", JSR 000116, March 2003. 3542 Authors' Addresses 3544 Miguel A. Garcia Martin (editor) 3545 Nokia 3546 P.O. Box 407 3547 NOKIA GROUP, FIN 00045 3548 Finland 3550 Phone: +358 50 480 4586 3551 Email: miguel.an.garcia@nokia.com 3552 Maria-Carmen Belinchon 3553 Ericsson 3554 Via de los Poblados 13 3555 Madrid 28033 3556 Spain 3558 Phone: +34 91 339 3535 3559 Email: maria.carmen.belinchon@ericsson.com 3561 Miguel A. Pallares-Lopez 3562 Ericsson 3563 Via de los Poblados 13 3564 Madrid 28033 3565 Spain 3567 Phone: +34 91 339 4222 3568 Email: miguel-angel.pallares@ericsson.com 3570 Carolina Canales-Valenzuela 3571 Ericsson 3572 Via de los Poblados 13 3573 Madrid 28033 3574 Spain 3576 Phone: +34 91 339 2680 3577 Email: carolina.canales@ericsson.com 3579 Kalle Tammi 3580 Nokia 3581 P.O.Box 785 3582 Tampere 33101 3583 Finland 3585 Phone: +358 40 505 8670 3586 Email: kalle.tammi@nokia.com 3588 Full Copyright Statement 3590 Copyright (C) The Internet Society (2006). 3592 This document is subject to the rights, licenses and restrictions 3593 contained in BCP 78, and except as set forth therein, the authors 3594 retain all their rights. 3596 This document and the information contained herein are provided on an 3597 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3598 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3599 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3600 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3601 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3602 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3604 Intellectual Property 3606 The IETF takes no position regarding the validity or scope of any 3607 Intellectual Property Rights or other rights that might be claimed to 3608 pertain to the implementation or use of the technology described in 3609 this document or the extent to which any license under such rights 3610 might or might not be available; nor does it represent that it has 3611 made any independent effort to identify any such rights. Information 3612 on the procedures with respect to rights in RFC documents can be 3613 found in BCP 78 and BCP 79. 3615 Copies of IPR disclosures made to the IETF Secretariat and any 3616 assurances of licenses to be made available, or the result of an 3617 attempt made to obtain a general license or permission for the use of 3618 such proprietary rights by implementers or users of this 3619 specification can be obtained from the IETF on-line IPR repository at 3620 http://www.ietf.org/ipr. 3622 The IETF invites any interested party to bring to its attention any 3623 copyrights, patents or patent applications, or other proprietary 3624 rights that may cover technology that may be required to implement 3625 this standard. Please address the information to the IETF at 3626 ietf-ipr@ietf.org. 3628 Acknowledgment 3630 Funding for the RFC Editor function is provided by the IETF 3631 Administrative Support Activity (IASA).