idnits 2.17.1 draft-ietf-aaa-diameter-sip-app-07.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.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3258. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 72 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 REGISTRATION or RE_REGISTRATION, the Diameter server SHOULD verify that there is only one SIP-AOR AVP. Otherwise, the Diameter server MUST answer with a Diameter SAA message with the Result-Code AVP value set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any SIP-User-Data AVP. If there is only one SIP-AOR AVP and if the SIP-User-Data-Already-Available AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include one or more 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. Additionally, the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. The Diameter server considers the SIP AOR authenticated and registered. o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to UNREGISTERED_USER then the Diameter server MUST store the SIP server address included in the SIP-Server-URI AVP value. The Diameter server will return the SIP server address in Diameter Location-Info-Answer (LIA) messages. If the SIP-User-Data-Already-Available AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include one or more user profile data associated with the SIP or SIPS URI (SIP-AOR AVP) and associated identities 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. The Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS. The Diameter server considers the SIP AOR UNREGISTERED, but with a SIP server allocated to trigger and provide services for unregistered users. Note that in case of UNREGISTERED_USER (SIP-Server-Assignment-Type AVP), the Diameter server MUST verify that there is only one SIP-AOR AVP. Otherwise, the Diameter server MUST answer the Diameter SAR message with a Diameter SAA message, it MUST set the Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any SIP-User-Data AVP. If the User-Name AVP was not present in the Diameter SAR message and the SIP-AOR is not known for the Diameter server, the Diameter server MUST NOT include a User-Name AVP in the Diameter SAA message and MUST set the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN. 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 Addresses of Record indicated in each of the SIP-AOR AVP values included in the Diameter SAR message. The Diameter server considers all of these SIP Addresses of Record 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 Addresses of Record included in the SIP-AOR AVP values of the Diameter SAR message, even though the SIP Addresses of Record will become unregistered. This feature allows a SIP server to request the Diameter server to remain as an assigned SIP server for those SIP Addresses of Record (SIP-AOR AVP values), and avoid SIP server assignment. The Diameter server MUST consider all these SIP Addresses of Record 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 Addresses of Record 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 Addresses of Record 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 Address of Record, 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 (March 18, 2005) is 6972 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 2823, but not defined == Unused Reference: 'I-D.ietf-aaa-diameter-mobileip' is defined on line 3167, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-aaa-diameter-nasreq' is defined on line 3173, but no explicit reference was found in the text ** 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) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 9 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 Expires: September 19, 2005 M. Belinchon 5 M. Pallares-Lopez 6 C. Canales 7 Ericsson 8 K. Tammi 9 Nokia 10 March 18, 2005 12 Diameter Session Initiation Protocol (SIP) Application 13 draft-ietf-aaa-diameter-sip-app-07 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 19, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document specifies the Diameter Session Initiation Protocol 49 (SIP) Application. This is a Diameter application that allows a 50 Diameter client to request authentication and authorization 51 information. This application is designed to be used in conjunction 52 with the Session Initiation Protocol (SIP), and provides a Diameter 53 client in a SIP server with the ability to request a Diameter server 54 the authentication of users and authorization of SIP resources usage. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Applicability Statement . . . . . . . . . . . . . . . . . . 7 62 5. Overview of Operation . . . . . . . . . . . . . . . . . . . 7 63 5.1 General Architecture . . . . . . . . . . . . . . . . . . . 8 64 5.2 Diameter Server Authenticates the User . . . . . . . . . . 9 65 5.3 Delegating Final Authentication Check to the SIP Server . 12 66 5.4 SIP Server Requests Authentication and Authorization . . . 15 67 5.5 Locating the recipient of the SIP request . . . . . . . . 16 68 5.6 Update of the User Profile . . . . . . . . . . . . . . . . 17 69 5.7 SIP Soft State Termination . . . . . . . . . . . . . . . . 18 70 5.8 Diameter Server Discovery . . . . . . . . . . . . . . . . 19 71 6. Advertising Application Support . . . . . . . . . . . . . . 21 72 7. Diameter SIP Application Command Codes . . . . . . . . . . . 21 73 7.1 User-Authorization-Request (UAR) Command . . . . . . . . . 22 74 7.2 User-Authorization-Answer (UAA) Command . . . . . . . . . 23 75 7.3 Server-Assignment-Request (SAR) Command . . . . . . . . . 27 76 7.4 Server-Assignment-Answer (SAA) Command . . . . . . . . . . 28 77 7.5 Location-Info-Request (LIR) Command . . . . . . . . . . . 32 78 7.6 Location-Info-Answer (LIA) Command . . . . . . . . . . . . 33 79 7.7 Multimedia-Auth-Request (MAR) Command . . . . . . . . . . 35 80 7.8 Multimedia-Auth-Answer (MAA) Command . . . . . . . . . . . 36 81 7.9 Registration-Termination-Request (RTR) Command . . . . . . 39 82 7.10 Registration-Termination-Answer (RTA) Command . . . . . 40 83 7.11 Push-Profile-Request (PPR) Command . . . . . . . . . . . 42 84 7.12 Push-Profile-Answer (PPA) Command . . . . . . . . . . . 43 85 8. Diameter SIP Application AVPs . . . . . . . . . . . . . . . 44 86 8.1 SIP-Accounting-Information AVP . . . . . . . . . . . . . . 46 87 8.1.1 SIP-Accounting-Server-URI AVP . . . . . . . . . . . . 47 88 8.1.2 SIP-Credit-Control-Server-URI AVP . . . . . . . . . . 47 89 8.2 SIP-Server-URI AVP . . . . . . . . . . . . . . . . . . . . 47 90 8.3 SIP-Server-Capabilities AVP . . . . . . . . . . . . . . . 47 91 8.3.1 SIP-Mandatory-Capability AVP . . . . . . . . . . . . . 48 92 8.3.2 SIP-Optional-Capability AVP . . . . . . . . . . . . . 48 93 8.4 SIP-Server-Assignment-Type AVP . . . . . . . . . . . . . . 48 94 8.5 SIP-Auth-Data-Item AVP . . . . . . . . . . . . . . . . . . 49 95 8.5.1 SIP-Authentication-Scheme AVP . . . . . . . . . . . . 50 96 8.5.2 SIP-Item-Number AVP . . . . . . . . . . . . . . . . . 50 97 8.5.3 SIP-Authenticate AVP . . . . . . . . . . . . . . . . . 51 98 8.5.4 SIP-Authorization AVP . . . . . . . . . . . . . . . . 51 99 8.5.5 SIP-Authentication-Info AVP . . . . . . . . . . . . . 52 100 8.5.6 Digest AVPs . . . . . . . . . . . . . . . . . . . . . 53 101 8.6 SIP-Number-Auth-Items AVP . . . . . . . . . . . . . . . . 54 102 8.7 SIP-Deregistration-Reason AVP . . . . . . . . . . . . . . 55 103 8.7.1 SIP-Reason-Code AVP . . . . . . . . . . . . . . . . . 55 104 8.7.2 SIP-Reason-Info AVP . . . . . . . . . . . . . . . . . 55 105 8.8 SIP-AOR AVP . . . . . . . . . . . . . . . . . . . . . . . 55 106 8.9 SIP-Visited-Network-Id AVP . . . . . . . . . . . . . . . . 56 107 8.10 SIP-User-Authorization-Type AVP . . . . . . . . . . . . 56 108 8.11 SIP-Supported-User-Data-Type AVP . . . . . . . . . . . . 57 109 8.12 SIP-User-Data AVP . . . . . . . . . . . . . . . . . . . 57 110 8.12.1 SIP-User-Data-Type AVP . . . . . . . . . . . . . . . 57 111 8.12.2 SIP-User-Data-Contents AVP . . . . . . . . . . . . . 58 112 8.13 SIP-User-Data-Already-Available AVP . . . . . . . . . . 58 113 8.14 SIP-Method AVP . . . . . . . . . . . . . . . . . . . . . 58 114 9. New Values for Existing AVPs . . . . . . . . . . . . . . . . 59 115 9.1 Extension to the Result-Code AVP Values . . . . . . . . . 59 116 9.1.1 Success Result-Code AVP Values . . . . . . . . . . . . 59 117 9.1.2 Transient Failures Result-Code AVP Values . . . . . . 59 118 9.1.3 Permanent failures Result-Code AVP Values . . . . . . 60 119 10. Authentication Details . . . . . . . . . . . . . . . . . . . 61 120 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 62 121 11.1 Application Identifier . . . . . . . . . . . . . . . . . 62 122 11.2 Command Codes . . . . . . . . . . . . . . . . . . . . . 63 123 11.3 AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 63 124 11.4 Additional Values for the Result-Code AVP Value . . . . 63 125 12. Security Considerations . . . . . . . . . . . . . . . . . . 64 126 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64 127 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 128 15. Changes With Respect Previous Versions . . . . . . . . . . . 64 129 15.1 Changes in draft-ietf-aaa-diameter-sip-app-07.txt 130 from -06.txt . . . . . . . . . . . . . . . . . . . . . . 65 131 15.2 Changes in draft-ietf-aaa-diameter-sip-app-06.txt 132 from -05.txt . . . . . . . . . . . . . . . . . . . . . . 65 133 15.3 Changes in draft-ietf-aaa-diameter-sip-app-05.txt 134 from -04.txt . . . . . . . . . . . . . . . . . . . . . . 65 135 15.4 Changes in draft-ietf-aaa-diameter-sip-app-04.txt 136 from -03.txt . . . . . . . . . . . . . . . . . . . . . . 66 137 15.5 Changes in draft-ietf-aaa-diameter-sip-app-03.txt 138 from -02.txt . . . . . . . . . . . . . . . . . . . . . . 67 139 15.6 Changes in draft-ietf-aaa-diameter-sip-app-02.txt 140 from -01.txt . . . . . . . . . . . . . . . . . . . . . . 67 141 15.7 Changes in draft-ietf-aaa-diameter-sip-app-01.txt 142 from -00.txt . . . . . . . . . . . . . . . . . . . . . . 68 143 15.8 Changes in draft-ietf-aaa-diameter-sip-app-00.txt 144 from draft-belinchon-aaa-diameter-mm-app-01.txt . . . . 68 146 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 147 16.1 Normative References . . . . . . . . . . . . . . . . . . 69 148 16.2 Informational References . . . . . . . . . . . . . . . . 70 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 70 150 Intellectual Property and Copyright Statements . . . . . . . 72 152 1. Terminology 154 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 155 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 156 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 157 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 158 levels for compliant implementations. 160 2. Definitions 162 For the purpose of this document, the following terms and definitions 163 apply. 165 o *Node: * an addressable device attached to a computer network that 166 implements SIP functionality, Diameter functionality or a 167 combination of both. 169 For the purpose of this document, the following terms and definitions 170 given in RFC 3261 [RFC3261] Section 6, apply: 172 o *Address-of-Record (AOR)* 173 o *Outbound proxy* 174 o *Proxy* 175 o *Server (SIP server)* 176 o *User Agent (UA)* 177 o *User Agent Client (UAC)* 178 o *User Agent Server (UAS)* 180 For the purpose of this document, the following terms and definitions 181 given in RFC 3588 [RFC3588] Section 1.3, apply: 183 o *Authorization* 184 o *Authentication* 185 o *AVP* 186 o *Diameter Client* 187 o *Diameter Server* 188 o *Home Realm* 189 o *Redirect Agent* 190 o *User* 192 3. Introduction 194 This document specifies the Diameter Session Initiation Protocol 195 (SIP) Application. This is a Diameter application that allows a 196 Diameter client to request authentication and authorization 197 information to a Diameter server for Session Initiation Protocol 198 (SIP) [RFC3261] based IP multimedia services. We assume that the SIP 199 server and the Diameter client are located in the same node, so that 200 the SIP server is able to receive and process SIP requests and 201 responses which in turn relies on the AAA infrastructure for 202 authenticating the SIP request and authorizing the usage of 203 particular SIP services. 205 This document provides Diameter procedures to implement certain 206 required functionality when SIP is the protocol chosen to initiate 207 and tear-down multimedia sessions or when SIP is used for other non- 208 session related applications. However, this document does not 209 mandate any particular mapping of SIP procedures to Diameter SIP 210 application procedures, nor does it mandate any particular sequence 211 of events between SIP and Diameter. This document provides useful 212 examples to show the interaction between SIP and the Diameter SIP 213 application in order to achieve the desired functionality. 215 This application does not require or is not related to other 216 authentication services provided by the Mobile IP Diameter [I-D.ietf- 217 aaa-diameter-mobileip] or the Network Access Server Diameter [I- 218 D.ietf-aaa-diameter-nasreq] applications. 220 This Diameter SIP application is loosely related to the Diameter 221 Credit Control Application [I-D.ietf-aaa-diameter-cc]. Although both 222 applications are independent, the Diameter SIP application is able to 223 supply the addresses of credit control servers that will be 224 implementing the Diameter Credit Control Application [I-D.ietf-aaa- 225 diameter-cc]. 227 Section 4 discusses assumptions and configurations assumed by this 228 document. 230 Section 5 provides the reader with informative descriptions of the 231 Diameter SIP application commands and responses and some guidance to 232 their linkage with SIP procedures. 234 Advertising of this application is specified in Section 6. 236 Section 7 provides a normative description of all the new Diameter 237 commands defined by this specification. 239 This application extends the Result-Code Attribute-Value-Pair (AVP) 240 with some new values. Further information is described in Section 9. 242 This application defines some new AVPs. All these AVPs are described 243 in Section 8. 245 Some extra information about authentication is provided in 246 Section 10. 248 4. Applicability Statement 250 This document assumes a general architecture where a Home Realm is 251 composed of one or more nodes implementing Diameter or SIP functions. 252 Users are issuing SIP requests to access SIP resources. For each 253 particular user, the Home Realm needs to authenticate and authorize 254 the usage of those resources and/or route to the appropriate node. 255 We assume that the database containing the user related data is 256 located outside the SIP node that requires authorization. Data 257 belonging to different users may be stored in different nodes in the 258 Home Realm, but we assume that all the data related to a particular 259 user is stored in a single node. 261 Central to the architecture is the fact that the user data is 262 stored in a single point in the network. This restriction does 263 not mandate a particular implementation, e.g., it is possible to 264 implement clusters of databases operating in mirror mode to 265 provide redundancy. The property required by this specification 266 is that the user data the Diameter Server has access to is stored 267 safely in what, from the external point of view, is seen as a 268 single user database. 270 This document allows several configurations of the Home Realm. In 271 one configuration, a SIP server is allocated to a user for the 272 purpose of triggering and executing services. The allocation of the 273 SIP server may be done dynamically, e.g., at the time the user 274 registers in the network. This configuration requires a SIP server, 275 typically located at the edge of the network, that is able to 276 allocate another SIP server for the user and also supports routing of 277 SIP requests and responses towards that allocated SIP server. Both 278 SIP server nodes implement a Diameter Client. 280 In another configuration, the address of a SIP outbound proxy is 281 configured (by means outside the scope of this specification) into 282 the SIP endpoint. The outbound Diameter Client in the SIP outbound 283 proxy node authenticates the user, requests authorization for SIP 284 requests and performs accounting activities. 286 5. Overview of Operation 288 This section provides an informative description of how the Diameter 289 SIP application can be used together with SIP. This section is not 290 intended to mandate any specific usage of the Diameter SIP 291 application nor does it mandate a specific mapping between SIP and 292 Diameter messages. We provide a collection of examples that show how 293 the required AAA functionality can be achieved in conjunction with 294 SIP. 296 5.1 General Architecture 298 The Diameter SIP application can be used in a SIP environment where 299 an interface to a AAA infrastructure is required to authenticate and 300 authorize the usage of SIP resources. This application provides a 301 limited support for accounting services, limited to the Diameter 302 server being able to provide the addresses of accounting severs to 303 the Diameter client. Figure 1 below shows a general overview of the 304 integration of the SIP architecture with the AAA architecture. 306 According to Figure 1, there is one or more SIP User Agents (UA) that 307 initiate or terminate SIP traffic through one or more SIP servers. 308 Both SIP servers implement a Diameter client that supports the 309 Diameter application described in this specification. 311 +--------+ 312 UAR/UAA +--->|Diameter|<----+ PPR/PPA 313 LIR/LIA | | server | | MAR/MAA 314 | +--------+ | SAR/SAA 315 | | RTR/RTA 316 | | 317 v v 318 +------+ SIP +--------+ SIP +--------+ SIP +------+ 319 | SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP | 320 | UA | |server 1| |server 2| | UA | 321 +------+ +--------+ +--------+ +------+ 322 ^ ^ 323 UAR/UAA | | 324 LIR/LIA | | MAR/MAA 325 | +--------+ | SAR/SAA 326 +--->|Diameter|<----+ 327 | SL | 328 +--------+ 330 Figure 1: Architecture of the Diameter application for SIP 332 In Figure 1, it can be seen that SIP server 1 sends different 333 Diameter commands and receives different responses to those sent and 334 received by SIP server 2. This is because SIP server 1 in Figure 1 335 is located at the edge of a network, and its main task is to locate 336 SIP server 2. SIP server 2 is requesting and receiving 337 authentication and authorization data from the Diameter server and is 338 not located at the edge of the network. 340 The Diameter Subscriber Locator (SL) serves for the purposes of 341 locating the Diameter server that contains the user related data. 342 Its functionality is based on the Diameter redirect mechanism, and is 343 further described in Section 5.8. 345 It should be noted that this document does not mandate any particular 346 SIP/AAA architecture. However, the Diameter SIP application provides 347 the functionality needed to accommodate all the different 348 architectures where SIP and Diameter are used. 350 The following subsections provide an informative overview of the 351 Diameter SIP application, its commands, and a possible interaction 352 with SIP signaling. 354 5.2 Diameter Server Authenticates the User 356 This is the generic mechanism to authenticate users. In this 357 approach we show an example of an administrative network where the 358 Diameter server is authenticating SIP user requests. This could be 359 the case of a medium size network where the Diameter server is 360 keeping user records and authenticating SIP requests to perform a 361 certain transaction. We have chosen to show a SIP REGISTER request 362 in the example, but the SIP server could request authentication of 363 any other SIP request. 365 +--------+ +--------+ +--------+ 366 | SIP | |Diameter| | SIP | 367 |server 1| | server | |server 2| 368 +--------+ +--------+ +--------+ 369 | | | 370 1. SIP REGISTER | | | 371 -------------------->| 2. UAR | | 372 |------------------>| | 373 | 3. UAA | | 374 |<------------------| | 375 | 4. SIP REGISTER | 376 |-------------------------------------->| 377 | | 5. MAR | 378 | |<------------------| 379 | | 6. MAA | 380 | |------------------>| 381 | 7. SIP 401 (Unauthorized) | 382 8. SIP 401 (Unauth.) |<--------------------------------------| 383 <--------------------| | | 384 9. SIP REGISTER | | | 385 -------------------->| 10. UAR | | 386 |------------------>| | 387 | 11. UAA | | 388 |<------------------| | 389 | 12. SIP REGISTER | 390 |-------------------------------------->| 391 | | 13. MAR | 392 | |<------------------| 393 | | 14. MAA | 394 | |------------------>| 395 | 15. SIP 200 (OK) | 396 16. SIP 200 (OK) |<--------------------------------------| 397 <--------------------| | | 398 | | 17. SAR | 399 | |<------------------| 400 | | 18. SAA | 401 | |------------------>| 402 | | | 404 Figure 2: Authentication performed in the Diameter server 406 According to Figure 2 a SIP User Agent Client (UAC) sends a SIP 407 REGISTER request (step 1) to SIP server 1, which will receive the SIP 408 request. We assume that this SIP server may be located, e.g., at the 409 edge of the administrative home domain. The Diameter client in SIP 410 server 1 will contact its Diameter server by sending a Diameter User- 411 Authorization-Request (UAR) message (step 2) to determine if this 412 user is allowed to receive service, and if so, request the address of 413 a local SIP server capable of handling this user. The Diameter 414 server will answer with a Diameter User-Authorization-Answer (UAA) 415 message (step 3), which will indicate either a list of capabilities 416 that SIP server 1 may use to select an appropriate SIP server (SIP 417 server 2) and/or a SIP or SIPS URI pointing to SIP server 2. 419 SIP server 1 will forward the SIP REGISTER request (step 4) to an 420 appropriate SIP server (SIP server 2). The Diameter client in SIP 421 server 2 will then request user authentication from the Diameter 422 server by sending a Diameter Multimedia-Auth-Request (MAR) message 423 (step 5). This request will also serve to make the Diameter server 424 aware of the SIP or SIPS URI of SIP server 2, so as to return 425 subsequent requests for the same user to the same SIP server 2. The 426 Diameter server will respond with a Diameter Multimedia-Auth-Answer 427 (MAA) message (step 6) with Result-Code AVP set to the value 428 DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a 429 challenge, which SIP server 2 will use to map into the WWW- 430 authentication header in the SIP 401 (Unauthorized) response (step 431 7), which is sent back to SIP server 1 and then to the SIP UAC (step 432 8). 434 SIP server 1 will receive a next SIP REGISTER request containing the 435 user credentials (step 9). Note that SIP server 1 does not need to 436 keep a state, and even more, there is no guarantee that the SIP 437 request will arrive at the same SIP server 1, there could be a farm 438 of SIP servers 1 operating in redundant configuration. The Diameter 439 client in SIP server 1 will contact a Diameter server by sending a 440 Diameter UAR message (step 10) to determine the SIP server allocated 441 to the user. The Diameter server will send the SIP or SIPS URI of 442 SIP server 2 in a Diameter UAA message (step 11). 444 SIP server 1 will then forward the SIP REGISTER request to SIP server 445 2 (step 12). SIP server 2 will extract the credentials from the SIP 446 REGISTER request. The Diameter client in SIP server 2 will send 447 those credentials in a Diameter MAR message (step 13) to the Diameter 448 server. At this point, the Diameter server will be able to 449 authenticate the user, and upon success, will return a Diameter MAA 450 message (step 14) with the AVP Result-Code set to the value 451 DIAMETER_SUCCESS. 453 SIP server 2 will then generate a SIP 200 (OK) response (step 15) 454 which is forwarded to SIP server 1 and eventually to the SIP UAC 455 (step 16). 457 If the Diameter client in SIP server 2 is interested in downloading 458 the user profile information or requires to store the address of the 459 SIP server in the Diameter server, then the Diameter client will send 460 a Diameter SAR message (step 17) to the Diameter server. The 461 Diameter server will reply with a Diameter SAA message (step 18) that 462 contains the requested user profile information and the 463 acknowledgement of the SIP server address storage. These actions are 464 needed when the SIP server needs to retrieve a user profile used to 465 provide services to the served user or when the SIP server will keep 466 a state for the user, so the Diameter server needs to store its 467 address. 469 5.3 Delegating Final Authentication Check to the SIP Server 471 An operator with a large base of installed SIP servers may wish to 472 minimize the number of round trips between the Diameter client and 473 the Diameter server. We provide support for a mechanism that allows 474 the Diameter server to delegate the final authentication check to the 475 SIP server, saving a round trip. However, it must also noted that 476 this scenario is only applicable when the authentication of the user 477 does not use client nonces, since the mechanism is based on the 478 computation of an expected response in the Diameter server, which 479 makes it available to the SIP server. 481 +--------+ +--------+ +--------+ 482 | SIP | |Diameter| | SIP | 483 |server 1| | server | |server 2| 484 +--------+ +--------+ +--------+ 485 | | | 486 1. SIP REGISTER | | | 487 -------------------->| 2. UAR | | 488 |------------------>| | 489 | 3. UAA | | 490 |<------------------| | 491 | 4. SIP REGISTER | 492 |-------------------------------------->| 493 | | 5. MAR | 494 | |<------------------| 495 | | 6. MAA | 496 | |------------------>| 497 | 7. SIP 401 (Unauthorized) | 498 8. SIP 401 (Unauth.) |<--------------------------------------| 499 <--------------------| | | 500 9. SIP REGISTER | | | 501 -------------------->| 10. UAR | | 502 |------------------>| | 503 | 11. UAA | | 504 |<------------------| | 505 | 12. SIP REGISTER | 506 |-------------------------------------->| 507 | | 13. SAR | 508 | |<------------------| 509 | | 14. SAA | 510 | |------------------>| 511 | 15. SIP 200 (OK) | 512 16. SIP 200 (OK) |<--------------------------------------| 513 <--------------------| | | 514 | | | 516 Figure 3: Delegation of authentication to the SIP server 518 Figure 3 shows an example where a SIP server is dynamically allocated 519 to serve a SIP User Agent with the support of the Diameter server. 520 This may be the case of certain architectures, such as that of the 521 3rd Generation Partnership Project (3GPP) IP Core Network Multimedia 522 Subsystem (IMS). 524 A first SIP server receives a SIP REGISTER request (step 1) whose 525 target is the home network domain. We assume that this SIP server 526 may be located, e.g., at the edge of the administrative home domain. 527 The Diameter client in this SIP server requests authorization from 528 the Diameter server to proceed with the registration, by sending a 529 Diameter User-Authorization-Request (UAR) message (step 2). The 530 message includes, among other Attribute-Value-Pairs (AVP), the SIP 531 address-of-record that is included in the SIP REGISTER request. The 532 Diameter server will verify the SIP address-of-record and, if it is a 533 valid defined user in the home network, will authorize the 534 registration to proceed. The Diameter server will respond with a 535 Diameter User-Authorization-Answer (UAA) message (step 3), which will 536 inform the Diameter client/SIP server about the result of the user 537 authorization. In case of a successful authorization, the Diameter 538 UAA message will indicate either the address of a local SIP server 539 (SIP server 2 in Figure 3) and/or a list of capabilities that SIP 540 server 1 may use to select an appropriate SIP server 2. 542 When the authorization is successful, SIP server 1 will forward the 543 SIP REGISTER request (step 4) to the appropriate SIP server (SIP 544 server 2). The Diameter client in SIP server 2 will then request 545 authentication parameters by sending a Diameter Multimedia-Auth- 546 Request (MAR) message (step 5) to the Diameter server. This request 547 will also serve to make the Diameter server aware of the SIP or SIPS 548 URI of SIP server 2, so as to return subsequent requests of the same 549 user to the same SIP server 2. The Diameter server will respond with 550 a Diameter Multimedia-Auth-Answer (MAA) message (step 6), which will 551 include all parameters necessary for the designated authentication 552 algorithm associated with the user. Among others, the MAA message 553 will include a Digest-HA1 AVP that contains H(A1) (as defined in RFC 554 2617 [RFC2617]), and allows the Diameter client to calculate the 555 expected response. Then the Diameter client can use this expected 556 response compare it with the response to the challenge sent from the 557 SIP UA. If the Digest-HA1 AVP is not present in MAA, it indicates 558 that authentication and authorization will take place in the Diameter 559 server, as per the scenario described in Section 5.2. 561 SIP server 2 will then create a SIP 401 (Unauthorized) SIP response 562 (step 7) based on the challenge included in the MAA message, 563 including the authentication material needed by the SIP User Agent 564 Client (UAC) to include the appropriate credentials. SIP server 1 565 forwards the SIP response to the SIP UAC (step 8). 567 When SIP server 1 receives a next SIP REGISTER request containing the 568 user credentials (step 9), as SIP server 1 does not need to keep a 569 state (even there is no guarantee that the SIP request arrives to the 570 same SIP server 1), the Diameter client in SIP server 1 will contact 571 again the Diameter server by sending a Diameter UAR message (step 10) 572 to determine the SIP server allocated to the user. The Diameter 573 server will send the SIP or SIPS URI of SIP server 2 in a Diameter 574 UAA message (step 11). 576 SIP server 1 will then forward the SIP REGISTER request to SIP server 577 2 (step 12). If the credentials include a client nonce, then SIP 578 server 2 falls back to the authentication in the Diameter server (see 579 Section 5.2). Otherwise, SIP server 2 will validate the credentials 580 by comparing the response supplied by the SIP UA with the expected 581 response supplied by the Diameter server. 583 If the credentials are valid, SIP server 2 will send a Diameter 584 Server-Assignment-Request (SAR) message (step 13) requesting the 585 Diameter server to confirm the completion of the authentication 586 procedure and to confirm the SIP or SIPS URI of the SIP server that 587 is currently serving the user. The Diameter SAR message also serves 588 the purpose to request the Diameter server to send the user profile 589 to the SIP server. The Diameter server will respond with a Diameter 590 Server-Assignment-Answer (SAA) message (step 14). If the Result-Code 591 AVP value does not inform about an error, the SAA message can include 592 zero or more SIP-User-Data AVPs containing the information that SIP 593 server 2 needs in order to provide a service to the user. 595 SIP server 2 generates a SIP 200 (OK) response (step 15) that will be 596 forwarded to SIP server 1 and eventually to the SIP UAC (step 16). 598 5.4 SIP Server Requests Authentication and Authorization 600 Figure 4 depicts a typical scenario where a stateless SIP proxy 601 requests authentication information and authorization to a Diameter 602 server, for the purpose of providing SIP routing services to a SIP 603 User Agent. The SIP proxy server may be configured as an outbound 604 SIP proxy, so that all the requests initiated by the SIP UA traverse 605 the SIP proxy. 607 According to Figure 4, a SIP User Agent sends a SIP request to its 608 outbound SIP proxy server. In this case, the message is a SIP INVITE 609 request (see step 1), but it could be any other SIP request. We 610 assume that this SIP request does not contain any credentials at this 611 time. The outbound SIP proxy server needs to authenticate and 612 authorize the proxy services offered to the user. The Diameter 613 client in the SIP server sends a Multimedia-Auth-Request (MAR) 614 message (step 2). The Diameter server sends a Multimedia-Auth-Answer 615 (MAA) message (step 3) that includes all the data necessary for the 616 SIP server to challenge the user, typically with HTTP Digest 617 Authentication indicated in the MAA message. This data will serve 618 the SIP server to create a SIP 407 (Proxy Authentication Required) 619 response (step 4) that contains a challenge. The SIP UA will create 620 a new INVITE request (step 5) that contains the credentials. The 621 Diameter client in the SIP server will send the credentials to the 622 Diameter server in a new Diameter MAR message (step 6). The Diameter 623 server will validate the credentials and authorize the SIP 624 transaction in a Diameter MAA message (step 7). The SIP server 625 forwards the SIP INVITE request to its destination (step 8) as per 626 regular SIP procedures. Eventually, the session setup will be 627 confirmed with a SIP 200 (OK) response (step 9) that is forwarded to 628 the SIP UA (step 10). The session setup is complete. 630 +--------+ +--------+ 631 |Diameter| | SIP | 632 | server | | server | 633 +--------+ +--------+ 634 | | 635 | | 636 1. SIP INVITE | 637 ----------------------------------->| 638 | 2. MAR | 639 |<------------------| 640 | 3. MAA | 641 |------------------>| 642 | | 643 4. SIP 407 (Proxy | 644 Authentication Required) | 645 <-----------------------------------| 646 | | 647 5. SIP INVITE | 648 ----------------------------------->| 649 | 6. MAR | 650 |<------------------| 651 | 7. MAA | 652 |------------------>| 8. SIP INVITE 653 | |----------------> 654 | | 9. SIP 200 (OK) 655 10. SIP 200 (OK) |<---------------- 656 <-----------------------------------| 657 | | 659 Figure 4: SIP server requests authorization 661 5.5 Locating the recipient of the SIP request 663 Figure 5 shows the scenario where SIP server 1 may be configured as a 664 SIP edge proxy server, processing SIP traffic at the edge of a 665 network. SIP server 1 receives a SIP INVITE request (step 1). SIP 666 server 1 needs to find the address of SIP server 2, which is serving 667 the recipient of the SIP request. The Diameter client in SIP server 668 1 sends Diameter Location-Info-Request (LIR) message (step 2) to the 669 Diameter server. The Diameter server responds with a Diameter 670 Location-Info-Answer (LIA) message (step 3) that contains the SIP or 671 SIPS URI of SIP server 2. SIP server 1 then forwards the SIP INVITE 672 to SIP server 2 (step 4). SIP server 2 will eventually forward the 673 SIP INVITE to the appropriate UAS (step 5). 675 +--------+ +--------+ +--------+ 676 | SIP | |Diameter| | SIP | 677 |server 1| | server | |server 2| 678 +--------+ +--------+ +--------+ 679 | | | 680 1. SIP INVITE | | | 681 -------------->| 2. LIR | | 682 |---------------->| | 683 | 3. LIA | | 684 |<----------------| | 685 | 4. SIP INVITE | 686 |--------------------------------->| 687 | | | 5. SIP INVITE 688 | | |--------------> 689 | | | 690 | | | 692 Figure 5: Locating the SIP server of the recipient 694 Although the example shows the connection between a SIP INVITE 695 request and the Diameter LIR message, any other SIP request other 696 than REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the 697 same Diameter message (A SIP REGISTER request will trigger a Diameter 698 UAR message, as indicated in Figures Figure 2 and Figure 3. 700 The scenario described in this section is also applicable in case an 701 outbound SIP server is interested not in authenticating the user, but 702 requires to locate a further SIP server to route the outbound SIP 703 requests. In this case, the outbound SIP server is mapped to SIP 704 server 1 in Figure 5. 706 5.6 Update of the User Profile 708 The Diameter SIP application provides a mechanism for a Diameter 709 server to asynchronously download a user profile to a SIP server 710 whenever there is an update of such user profile. It must be noted 711 that the Diameter server also attaches the user profile in the 712 Diameter Server-Assignment-Answer (SAA) message. Although this is 713 valid for most of the daily situations, it may happen that the 714 administrator decides to update or modify the user profile for a 715 particular user, due to, e.g., new services made available to the 716 user. This may involve mechanisms outside the scope of this 717 specification, such as human intervention, in the Diameter server. 718 In this situation, the Diameter server is able to push the new user 719 profile into the SIP server allocated to the user. 721 The scenario is illustrated in Figure 6. Where the user profile 722 changes, the Diameter server will send a Diameter Push-Profile- 723 Request (PPR) message (step 1) to the Diameter client in the SIP 724 server allocated to that user (SIP server 2 in the examples). The 725 Diameter PPR message will contain one or more SIP-User-Data AVP, a 726 User-Name AVP and zero or more SIP-AOR AVPs. The Diameter client in 727 SIP server 2 will acknowledge the Diameter PPR message by sending a 728 Diameter Push-Profile-Answer (PPA) message (step 2) to the Diameter 729 server. 731 +--------+ +--------+ 732 |Diameter| | SIP | 733 | server | |server 2| 734 +--------+ +--------+ 735 | | 736 | 1. PPR | 737 |------------------>| 738 | | 739 | 2. PPA | 740 |<------------------| 741 | | 743 Figure 6: Diameter server pushes an update of the user profile 745 5.7 SIP Soft State Termination 747 SIP can create soft states in SIP nodes based on, e.g., SIP 748 registrations or SIP event subscriptions. These states are 749 periodically refreshed, and cease to exist if they are not refreshed. 750 Additionally, an administrative action can be taken to terminate a 751 SIP soft state, or the SIP UA can explicitly terminate a SIP soft 752 state. 754 The Diameter base protocol offers a mechanism to create and delete 755 states in Diameter nodes. These states are called Diameter user 756 sessions. The Diameter server decides whether to use a Diameter user 757 session as a mechanism to map to a SIP soft state. If the Diameter 758 server decides to use Diameter user sessions, the termination of a 759 Diameter user session implies the termination of the corresponding 760 SIP soft state (e.g., registration, event subscription), and vice 761 versa. If the Diameter server does not use Diameter user sessions, 762 this Diameter SIP application offers specific commands to manage the 763 SIP soft states. Implementations compliant to this specification 764 MUST support both mechanisms of session management. 766 We provide support for both Diameter client and Diameter server 767 initiated session termination. 769 Depending on whether Diameter sessions are used or not, termination 770 of a SIP soft state can be achieved by either of the following 771 methods: 773 When the Diameter client (SIP proxy) wants to terminate the SIP soft 774 state and Diameter user sessions are not maintained (i.e., the Auth- 775 Session-State AVP has been previously set to NO_STATE_MAINTAINED), 776 the Diameter client MUST send a Server-Assignment-Request (SAR) 777 message with the SIP-Server-Assignment-Type AVP set to the value DE- 778 REGISTRATION. 780 When the Diameter client (SIP proxy) wants to terminate the SIP soft 781 state and Diameter user sessions are maintained (i.e., the Auth- 782 Session-State AVP has been previously set to STATE_MAINTAINED) the 783 Diameter client MUST send a Session-Termination-Request message as 784 per regular procedures according to the RFC 3588 [RFC3588]. 786 When the Diameter server wants to terminate the SIP soft state and 787 Diameter user sessions are not maintained (i.e., the Auth-Session- 788 State AVP has been previously set to NO_STATE_MAINTAINED), the 789 Diameter server MUST send a Registration-Termination-Request message 790 (see Section 7.9). 792 When the Diameter server wants to terminate the SIP soft state and 793 Diameter user sessions are maintained (i.e., the Auth-Session-State 794 AVP has been previously set to STATE_MAINTAINED), the Diameter server 795 MUST send an Abort-Session-Request message as per regular procedures 796 according to the RFC 3588 [RFC3588]. 798 5.8 Diameter Server Discovery 800 The basic architecture assumption of this document is that all the 801 data related to a user is stored in a unique Diameter server. This 802 does not create a single point of failure, as it may be generally 803 thought. It is assumed that Diameter servers will be configured in a 804 redundant fashion as an attempt to mitigate the single point of 805 failure problem. 807 In large networks, where the number of users may be significantly 808 high, there might be a need to scale the number of Diameter servers. 809 All the data associated with a user will be still stored in one 810 Diameter server (typically operating in a redundant configuration). 811 But the data associated with different users may reside in different 812 Diameter servers. 814 This configuration, although scales well, introduces a new problem, 815 namely: given the user's SIP AOR as an input, how to determine which 816 of various Diameter servers is storing the data for that particular 817 SIP AOR. We solve this problem by inspiring on the Diameter 818 redirection mechanism specified in RFC 3588 [RFC3588]. We include in 819 the architecture a new Diameter node that, for the purpose of this 820 document, it is known as Diameter Subscriber Locator (SL). The 821 Diameter Subscriber Locator contains a database or routing tables 822 that maps SIP AORs with Diameter server URIs. A particular Diameter 823 server URI points to the actual Diameter server that stores all the 824 data related to a particular SIP AOR, and in consequence, to the user 825 who owns the SIP AOR. The Diameter Subscriber Locator acts in a 826 similar way to a Diameter Redirect Agent, dispatching Diameter 827 requests (e.g., providing the redirection URI in the answer). The 828 Diameter Subscriber Locator can redirect all the request pertaining 829 to a user by setting the Redirect-Host-Usage AVP with a value 830 ALL_USER, as specified in RFC 3588 [RFC3588]. 832 The Diameter SL can be replicated in different nodes along the 833 network, for the purpose of building scalability and redundancy. The 834 database or routing tables have to be consistent across all these 835 different Diameter SLs, so that equal Diameter requests will produce 836 the equal Diameter answers no matter which Diameter SL processes the 837 request. 839 +--------+ +--------+ +--------+ +--------+ 840 | SIP | |Diameter| |Diameter| | SIP | 841 |server 1| |SL red. | |server 1| |server 2| 842 +--------+ +--------+ +--------+ +--------+ 843 | | | | 844 1. SIP INVITE| | | | 845 ------------>| 2. LIR | | | 846 |---------->| | | 847 | 3. LIA | | | 848 |<----------| | | 849 | 4. LIR | | 850 |---------------------->| | 851 | 5. LIA | | 852 |<----------------------| | 853 | 6. SIP INVITE | | 854 |----------------------------------->| 7. SIP INVITE 855 | | | | -------------> 856 | | | | 858 Figure 7: Locating a Diameter server. SL redirecting requests 860 Figure 7 shows an example of operation of a Diameter Subscriber 861 Locator acting in redirect mode. SIP server 1 is receiving an INVITE 862 request (step 1) addressed (in the SIP Request-URI) to a user for 863 which the Diameter client in SIP server 1 does not posses routing 864 information. In other words, the Diameter client in SIP server 1 865 does not know the URI of Diameter server 1. The Diameter client 866 sends a Diameter LIR message (step 2) to any of the Diameter SLs 867 configured in the network. The address of those SLs is assumed to be 868 pre-provisioned in the Diameter client. The Diameter SL, based on 869 the contents of the SIP-AOR AVP and its own routing tables determines 870 the Diameter server that stores the information allocated to such 871 user. Then it builds a Diameter LIA message (step 3) that includes a 872 Result-Code AVP set to DIAMETER_REDIRECT_INDICATION and one or more 873 Redirect-Host AVPs, whose values are set to one or more URIs of 874 Diameter servers that store the information related to such user. 875 Then the Diameter client in SIP server 1 builds a new LIR message 876 (step 4) addressed to any of the Diameter servers received in the 877 Redirect-Host AVPs. The rest of procedure is completed as described 878 in previous sections. 880 6. Advertising Application Support 882 Diameter implementations conforming to this specification MUST 883 advertise its support by including an Auth-Application-Id AVP in the 884 Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer 885 (CEA) commands, according to the Diameter base protocol, RFC 3588 886 [RFC3588]. This Auth-Application-Id AVP MUST be set to the value of 887 this Diameter SIP application (Section 11.1 indicates the actual 888 value allocated by IANA). 890 7. Diameter SIP Application Command Codes 892 All the Diameter implementations conforming to this specification 893 MUST implement and support the list of Diameter commands listed in 894 Table 1. 896 +----------------------------------+-------+-------+----------------+ 897 | Command Name | Abbr. | Code | Reference | 898 +----------------------------------+-------+-------+----------------+ 899 | User-Authorization-Request | UAR | aaa | Section 7.1 | 900 | User-Authorization-Answer | UAA | aaa | Section 7.2 | 901 | Server-Assignment-Request | SAR | bbb | Section 7.3 | 902 | Server-Assignment-Answer | SAA | bbb | Section 7.4 | 903 | Location-Info-Request | LIR | ccc | Section 7.5 | 904 | Location-Info-Answer | LIA | ccc | Section 7.6 | 905 | Multimedia-Auth-Request | MAR | ddd | Section 7.7 | 906 | Multimedia-Auth-Answer | MAA | ddd | Section 7.8 | 907 | Registration-Termination-Request | RTR | eee | Section 7.9 | 908 | Registration-Termination-Answer | RTA | eee | Section 7.10 | 909 | Push-Profile-Request | PPR | fff | Section 7.11 | 910 | Push-Profile-Answer | PPA | fff | Section 7.12 | 911 +----------------------------------+-------+-------+----------------+ 913 Table 1: Defined command codes 915 [Note to IANA and the RFC editor: replace aaa, bbb, ccc, and so on 916 with the actual values allocated to these commands.] 918 7.1 User-Authorization-Request (UAR) Command 920 The User-Authorization-Request (UAR) is indicated by the Command-Code 921 set to aaa [Note to IANA and the RFC editor: replace aaa with the 922 actual value allocated to this command] and the Command Flags' 'R' 923 bit set. The Diameter client in a SIP server sends this command to 924 the Diameter server to request authorization for the SIP User Agent 925 to route a SIP REGISTER request. As the SIP REGISTER request 926 implicitly carries a permission to bind an AOR to a contact address, 927 the Diameter client uses the Diameter UAR as a first authorization 928 request towards the Diameter server to authorize the registration. 929 For instance, the Diameter server can verify that the AOR is a 930 legitimate user of the realm. 932 The Diameter client in the SIP server will request authorization for 933 one of the possible values defined in the SIP-User-Authorization-Type 934 AVP (Section 8.10). 936 The user name used for authentication of the user is conveyed in a 937 User-Name AVP (defined in the Diameter base protocol, RFC 3588 938 [RFC3588]). The location of the authentication user name in the SIP 939 REGISTER request varies depending on the authentication mechanism. 940 When the authentication mechanism is HTTP Digest as defined in RFC 941 2617 [RFC2617], the authentication user name is found in the 942 "username" directive of the SIP Authorization header field value. 943 This Diameter SIP application only provides support for HTTP Digest 944 authentication in SIP: other authentication mechanisms are not 945 currently supported. 947 The SIP or SIPS URI to be registered is conveyed in the SIP-AOR AVP 948 (Section 8.8). Typically this SIP or SIPS URI is found in the To 949 header field value of the SIP REGISTER request that triggered the 950 Diameter UAR message. 952 The SIP-Visited-Network-Id AVP indicates the network that is 953 providing SIP services (e.g., SIP proxy functionality or any other 954 kind of services) to the SIP User Agent. 956 Message Format 957 ::= < Diameter Header: aaa, REQ, PXY > 958 < Session-ID > 959 < Auth-Application-Id > 960 { Auth-Session-State } 961 { Origin-Host } 962 { Origin-Realm } 963 { Destination-Realm } 964 { SIP-AOR } 965 [ Destination-Host ] 966 [ User-Name ] 967 [ SIP-Visited-Network-Id ] 968 [ SIP-User-Authorization-Type ] 969 * [ Proxy-Info ] 970 * [ Route-Record ] 971 * [ AVP ] 973 [Note to IANA and the RFC editor: replace aaa with the actual value 974 allocated to this command] 976 7.2 User-Authorization-Answer (UAA) Command 978 The User-Authorization-Answer (UAA) is indicated by the Command-Code 979 set to aaa [Note to IANA and the RFC editor: replace aaa with the 980 actual value allocated to this command] and the Command Flags' 'R' 981 bit cleared. The Diameter server sends this command in response to a 982 previously received Diameter User-Authorization-Request (UAR) 983 command. The Diameter server indicates the result of the requested 984 registration authorization. Additionally, the Diameter server may 985 indicate a collection of SIP capabilities that assists the Diameter 986 client to select a SIP proxy to the AOR under registration. 988 In addition to the values already defined in RFC 3588 [RFC3588], the 989 Result-Code AVP may contain one of the values defined in Section 9.1. 991 Whenever the Diameter server fails to process the Diameter UAR 992 message, it MUST stop processing and return the concerned error in 993 the Diameter UAA message. When there is success in the process, the 994 Diameter server MUST set the code to DIAMETER_SUCCESS in the Diameter 995 UAA message. 997 If the Diameter server requires a User-Name AVP value to process the 998 Diameter UAR request, but the Diameter UAR message did not contain a 999 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1000 value to DIAMETER_USER_NAME_REQUIRED (see Section 9.1.2) and return 1001 it in a Diameter UAA message. Upon reception of this Diameter UAA 1002 message with the Result-Code AVP value set to 1003 DIAMETER_USER_NAME_REQUIRED, the SIP server will typically request 1004 authentication by generating a SIP 401 (Unauthorized) or SIP 407 1005 (Proxy Authentication Required) response back to the originator. 1007 When the authorization procedure succeeds, the Diameter server 1008 constructs a User-Authorization-Answer (UAA) message that MUST 1009 include the address of the SIP server already assigned to the user, 1010 the capabilities needed by the SIP server (Diameter client) to select 1011 another SIP server for the user or a combination of the previous two 1012 options. 1014 The Diameter UAA message contains the address of the SIP server 1015 allocated to the user if the Diameter server is already aware of an 1016 allocated SIP server to the user. 1018 The Diameter UAA message contains the capabilities required by a SIP 1019 server when there is a possibility that the Diameter client (in the 1020 SIP server) needs to allocate another SIP server that will be 1021 handling all the requests associated with this user, and possibly 1022 triggering and executing services. 1024 If a User-Name AVP is present in the Diameter UAR message, then the 1025 Diameter server MUST verify the existence of the user in the realm, 1026 i.e., the User-Name AVP value is a valid user within that realm. If 1027 the Diameter server does not recognize the user name received in the 1028 User-Name AVP, the Diameter server MUST build a Diameter User- 1029 Authorization-Answer (UAA) message and MUST set the Result-Code AVP 1030 to DIAMETER_ERROR_USER_UNKNOWN. 1032 If a User-Name AVP is present in the Diameter UAR message, then the 1033 Diameter server MUST authorize that User-Name AVP value is able to 1034 register the SIP or SIPS URI included in the SIP-AOR AVP. If this 1035 authorization fails, the Diameter server must set the Result-Code AVP 1036 to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter 1037 User-Authorization-Answer (UAA) message. 1039 Correlation between User-Name and SIP-AOR AVP values is required 1040 just to avoid that any user can register a SIP-AOR allocated to 1041 another user. 1043 If there is a SIP-Visited-Network-Id AVP in the Diameter UAR message, 1044 and the SIP-User-Authorization-Type AVP value received in the 1045 Diameter UAR message is set to REGISTRATION or REGISTRATION& 1046 CAPABILITIES then the Diameter server SHOULD verify whether the user 1047 is allowed to roam into the network specified in the SIP-Visited- 1048 Network-Id AVP in the Diameter UAR message. If the user is not 1049 allowed to roam into such network, the Diameter AAA server MUST set 1050 the Result-Code AVP value in the Diameter UAA message to 1051 DIAMETER_ERROR_ROAMING_NOT_ALLOWED. 1053 If the SIP-User-Authorization-Type AVP value received in the Diameter 1054 UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES then 1055 the Diameter server SHOULD verify whether the SIP-AOR AVP value is 1056 authorized to register in the home realm. Where the SIP Address of 1057 Record is not authorized to register in the home realm, the Diameter 1058 server MUST set the Result-Code AVP to 1059 DIAMETER_AUTHORIZATION_REJECTED and send it in a Diameter UAA 1060 message. 1062 When the SIP-User-Authorization-Type AVP is not present in the 1063 Diameter UAR message, or it is present and its value is set to 1064 REGISTRATION then: 1066 o If the Diameter server is not aware of any previous registration 1067 of the user name (including registrations of other SIP Addresses 1068 of Record allocated to the same user name), then the Diameter 1069 server does not know of any SIP server allocated to the user. In 1070 this case the Diameter server MUST set the Result-Code AVP value 1071 to DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and 1072 the Diameter server SHOULD include the required SIP server 1073 capabilities in the SIP-Server-Capabilities AVP value in the 1074 Diameter UAA message. The SIP-Server-Capabilities AVP will assist 1075 the Diameter client (SIP server) to select an appropriate SIP 1076 server for the user, according to the required capabilities. 1077 o In some cases, the Diameter server is aware of a previously 1078 assigned SIP server for the same or different SIP Addresses of 1079 Record allocated to the same user name. In these cases, re- 1080 assignment of a new SIP server may or may not be needed, depending 1081 on the capabilities of the SIP server. The Diameter server MUST 1082 always include the allocated SIP server URI in the SIP-Server-URI 1083 AVP of the UAA message. If the Diameter server does not return 1084 the SIP capabilities, the Diameter server MUST set the Result-Code 1085 AVP in the Diameter UAA message to 1086 DIAMETER_SUBSEQUENT_REGISTRATION. Otherwise, if the Diameter 1087 server includes a SIP-Server-Capabilities AVP then the Diameter 1088 server MUST set the Result-Code AVP in the Diameter UAA message to 1089 DIAMETER_SERVER_SELECTION. The Diameter client will then 1090 determine, based on the received information, whether it needs to 1091 select a new SIP server or not. 1093 When the SIP-User-Authorization-Type AVP value received in the 1094 Diameter UAR message is set to REGISTRATION&CAPABILITIES then 1095 Diameter Server MUST return the list of capabilities in the SIP- 1096 Server-Capabilities AVP value of the Diameter UAA message, it MUST 1097 set the Result-Code to DIAMETER_SUCCESS and it MUST NOT return a SIP- 1098 Server-URI AVP. The SIP-Server-Capabilities AVP enables the SIP 1099 server (Diameter Client) to select another appropriate SIP server for 1100 invoking and executing services for the user, depending on the 1101 required capabilities. The Diameter server MAY leave the list of 1102 capabilities empty to indicate that any SIP server can be selected. 1104 When the SIP-User-Authorization-Type AVP value received in the 1105 Diameter UAR message is set to DE-REGISTRATION then: 1107 o If the Diameter server is aware of a SIP server assigned to the 1108 SIP AOR under de-registration, the Diameter server MUST set the 1109 Result-Code AVP to DIAMETER_SUCCESS and MUST set the SIP-Server- 1110 URI AVP value to the known SIP server, and return them in the 1111 Diameter UAA message. 1112 o If the Diameter server is not aware of a SIP server assigned to 1113 the SIP AOR under de-registration, then the Diameter server MUST 1114 set the Result-Code AVP in the Diameter UAA message to 1115 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED. 1117 Message Format 1118 ::= < Diameter Header: aaa, PXY > 1119 < Session-Id > 1120 { Auth-Application-Id } 1121 { Auth-Session-State } 1122 { Result-Code } 1123 { Origin-Host } 1124 { Origin-Realm } 1125 [ SIP-Server-URI ] 1126 [ SIP-Server-Capabilities ] 1127 [ Authorization-Lifetime ] 1128 [ Auth-Grace-Period ] 1129 * [ Redirect-Host ] 1130 [ Redirect-Host-Usage ] 1131 [ Redirect-Max-Cache-Time ] 1132 * [ Proxy-Info ] 1133 * [ Route-Record ] 1134 * [ AVP ] 1136 [Note to IANA and the RFC editor: replace aaa with the actual value 1137 allocated to this command] 1139 7.3 Server-Assignment-Request (SAR) Command 1141 The Server-Assignment-Request (SAR) command is indicated by the 1142 Command-Code set to bbb [Note to IANA and the RFC editor: replace bbb 1143 with the actual value allocated to this command] and the Command 1144 Flags' 'R' bit set. The Diameter client in a SIP server sends this 1145 command to the Diameter server to indicate the completion of the 1146 authentication process and to request the Diameter server to store 1147 the URI of the SIP server that is currently serving the user. The 1148 Diameter SAR command has the main function to inform and store/clear 1149 in the Diameter server the URI of the SIP server allocated to the 1150 user. Additionally, the Diameter client can request to download the 1151 user profile or part of it. 1153 During the registration procedure, a SIP server becomes assigned to 1154 the user. The Diameter client in the assigned SIP server MUST 1155 include its own URI in the SIP-Server-URI AVP of the Server- 1156 Assignment-Request (SAR) Diameter message and send it to the Diameter 1157 server. The Diameter server then becomes aware of the allocation of 1158 the SIP server and its URI. 1160 The Diameter client in the SIP server MAY send a Diameter SAR message 1161 because of other reasons. These reasons are identified in the SIP- 1162 Server-Assignment-Type AVP value (Section 8.4). For instance, a 1163 Diameter client in a SIP server may contact the Diameter server to 1164 request de-registration of a user, to inform the Diameter server of 1165 an authentication failure or just to download the user profile. For 1166 a complete description of all the SIP-Server-Assignment-Type AVP 1167 values see Section 8.4. 1169 Typically the reception of a SIP REGISTER request in a SIP server 1170 will trigger the Diameter client in the SIP server to send the 1171 Diameter SAR message. However, if a SIP server is receiving other 1172 SIP request, such as INVITE, and the SIP server does not have the 1173 user profile, the Diameter client in the SIP server may send the 1174 Diameter SAR message to the Diameter server in order to download the 1175 user profile and make the Diameter server aware of the SIP server 1176 assigned to the user. 1178 The user profile is an important piece of information that dictates 1179 the behavior of the SIP server when triggering or providing services 1180 for the user. Typically the user profile is divided into: 1182 o Services to be rendered to the user when the user is registered 1183 and initiates a SIP request. 1184 o Services to be rendered to the user when the user is registered 1185 and a SIP request destined to that user arrives to the SIP proxy. 1186 o Services to be rendered to the user when the user is not 1187 registered and a SIP request destined to that user arrives to the 1188 SIP proxy. 1190 The SIP-Server-Assignment-Type AVP will indicate the reason why the 1191 Diameter client (SIP server) contacted the Diameter server. If the 1192 Diameter client sets the SIP-Server-Assignment-Type AVP value to 1193 REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT, 1194 AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter client 1195 MUST include exactly one SIP-AOR AVP in the Diameter SAR message. 1197 The SAR message MAY contain zero or more SIP-Supported-User-Data-Type 1198 AVPs. Each of them will contain a type of user data understood by 1199 the SIP server. This allows the Diameter client to provide an 1200 indication to the Diameter server of the different format of user 1201 data understood by the SIP server. The Diameter server will use this 1202 information to select one more SIP-User-Data AVPs that will be 1203 included in the SAA message. 1205 Message Format 1206 ::= < Diameter Header: bbb, REQ, PXY > 1207 < Session-Id > 1208 { Auth-Application-Id } 1209 { Auth-Session-State } 1210 { Origin-Host } 1211 { Origin-Realm } 1212 { Destination-Realm } 1213 { SIP-Server-Assignment-Type } 1214 { SIP-User-Data-Already-Available } 1215 [ Destination-Host ] 1216 [ User-Name ] 1217 [ SIP-Server-URI ] 1218 * [ SIP-Supported-User-Data-Type ] 1219 * [ SIP-AOR ] 1220 * [ Proxy-Info ] 1221 * [ Route-Record ] 1222 * [ AVP ] 1224 [Note to IANA and the RFC editor: replace bbb with the actual value 1225 allocated to this command] 1227 7.4 Server-Assignment-Answer (SAA) Command 1229 The Server-Assignment-Answer (SAA) is indicated by the Command-Code 1230 set to bbb [Note to IANA and the RFC editor: replace bbb with the 1231 actual value allocated to this command] and the Command Flags' 'R' 1232 bit cleared. The Diameter server sends this command in response to a 1233 previously received Diameter Server-Assignment-Request (SAR) command. 1234 The response may include the user profile or part of it, if 1235 requested. 1237 In addition to the values already defined in RFC 3588 [RFC3588], the 1238 Result-Code AVP may contain one of the values defined in Section 9.1. 1240 The Result-Code AVP value in the Diameter SAA message may indicate a 1241 success or an error in the execution of the Diameter SAR command. If 1242 Result-Code AVP value in the Diameter SAA message does not contain an 1243 error code, the SAA message MAY include one more SIP-User-Data AVPs 1244 that will typically contain the profile of the user, indicating 1245 services that the SIP server can provide to that user. 1247 The Diameter server MAY include one or more SIP-Supported-User-Data- 1248 Type AVPs, each one identifying a type of user data format supported 1249 in the Diameter server. If there is not a common supported user data 1250 type between the Diameter client and the Diameter server, the 1251 Diameter server SHOULD declare its list of supported user data types 1252 by including one or more SIP-Supported-User-Data-Type AVPs in a 1253 Diameter SAA message. This indication is merely for debugging 1254 reasons, since there is not a fall-back mechanism that allows the 1255 Diameter client to retrieve the profile in a supported format. 1257 If the Diameter server requires a User-Name AVP value to process the 1258 Diameter SAR request, but the Diameter SAR message did not contain a 1259 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1260 value to DIAMETER_USER_NAME_REQUIRED (see Section 9.1.2) and return 1261 it in a Diameter SAA message. Upon reception of this Diameter SAA 1262 message with the Result-Code AVP value set to 1263 DIAMETER_USER_NAME_REQUIRED, the SIP server will typically request 1264 authentication by generating a SIP 401 (Unauthorized) or SIP 407 1265 (Proxy Authentication Required) response back to the originator. 1267 If the User-Name AVP is included in the Diameter SAR message, at 1268 reception of the Diameter SAR message, the Diameter server MUST 1269 verify the existence of the user in the realm, i.e., the User-Name 1270 AVP value is a valid user within that realm. If the Diameter server 1271 does not recognize the user name received in the User-Name AVP, the 1272 Diameter server MUST build a Diameter Server-Assignment-Answer (SAA) 1273 message and MUST set the Result-Code AVP to 1274 DIAMETER_ERROR_USER_UNKNOWN. 1276 Then the Diameter server MUST authorize that User-Name AVP value is a 1277 valid authentication name for the SIP or SIPS URI included in the 1278 SIP-AOR AVP of the Diameter SAR message. If this authorization 1279 fails, the Diameter server must set the Result-Code AVP to 1280 DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter 1281 Server-Assignment-Answer (SAA) message. 1283 The actions of the Diameter server at the reception of the Diameter 1284 SAR message depends on the value of the SIP-Server-Assignment-Type: 1286 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1287 message is set to REGISTRATION or RE_REGISTRATION, the Diameter 1288 server SHOULD verify that there is only one SIP-AOR AVP. 1289 Otherwise, the Diameter server MUST answer with a Diameter SAA 1290 message with the Result-Code AVP value set to 1291 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any SIP- 1292 User-Data AVP. If there is only one SIP-AOR AVP and if the SIP- 1293 User-Data-Already-Available AVP value is set to 1294 USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include 1295 one or more user profile data with the SIP or SIPS URI (SIP-AOR 1296 AVP) and all other SIP identities associated with that AVP in the 1297 SIP-User-Data AVP value of the Diameter SAA message. On selecting 1298 the type of user data, the Diameter server SHOULD take into 1299 account the supported formats at the SIP server (SIP-Supported- 1300 User-Data-Type AVP in the SAR message) and the local policy. 1301 Additionally, the Diameter server MUST set the Result-Code AVP 1302 value to DIAMETER_SUCCESS in the Diameter SAA message. The 1303 Diameter server considers the SIP AOR authenticated and 1304 registered. 1305 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1306 message is set to UNREGISTERED_USER then the Diameter server MUST 1307 store the SIP server address included in the SIP-Server-URI AVP 1308 value. The Diameter server will return the SIP server address in 1309 Diameter Location-Info-Answer (LIA) messages. If the SIP-User- 1310 Data-Already-Available AVP value is set to 1311 USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include 1312 one or more user profile data associated with the SIP or SIPS URI 1313 (SIP-AOR AVP) and associated identities in the SIP-User-Data AVP 1314 value of the Diameter SAA message. On selecting the type of user 1315 data, the Diameter server SHOULD take into account the supported 1316 formats at the SIP server (SIP-Supported-User-Data-Type AVP in the 1317 SAR message) and the local policy. The Diameter server MUST set 1318 the Result-Code AVP value to DIAMETER_SUCCESS. The Diameter 1319 server considers the SIP AOR UNREGISTERED, but with a SIP server 1320 allocated to trigger and provide services for unregistered users. 1321 Note that in case of UNREGISTERED_USER (SIP-Server-Assignment-Type 1322 AVP), the Diameter server MUST verify that there is only one SIP- 1323 AOR AVP. Otherwise, the Diameter server MUST answer the Diameter 1324 SAR message with a Diameter SAA message, it MUST set the Result- 1325 Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT 1326 include any SIP-User-Data AVP. 1327 If the User-Name AVP was not present in the Diameter SAR message 1328 and the SIP-AOR is not known for the Diameter server, the Diameter 1329 server MUST NOT include a User-Name AVP in the Diameter SAA 1330 message and MUST set the Result-Code AVP value to 1331 DIAMETER_ERROR_USER_UNKNOWN. 1332 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1333 message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, 1334 DEREGISTRATION_TOO_MUCH_DATA or ADMINISTRATIVE_DEREGISTRATION the 1335 Diameter server MUST clear the SIP server address associated with 1336 all SIP Addresses of Record indicated in each of the SIP-AOR AVP 1337 values included in the Diameter SAR message. The Diameter server 1338 considers all of these SIP Addresses of Record as not registered. 1339 The Diameter server MUST set the Result-Code AVP value to 1340 DIAMETER_SUCCESS in the Diameter SAA message. 1341 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1342 message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or 1343 USER_DEREGISTRATION_STORE_SERVER_NAME the Diameter server MAY keep 1344 the SIP server address associated with the SIP Addresses of Record 1345 included in the SIP-AOR AVP values of the Diameter SAR message, 1346 even though the SIP Addresses of Record will become unregistered. 1347 This feature allows a SIP server to request the Diameter server to 1348 remain as an assigned SIP server for those SIP Addresses of Record 1349 (SIP-AOR AVP values), and avoid SIP server assignment. The 1350 Diameter server MUST consider all these SIP Addresses of Record as 1351 not registered. If the Diameter server honors the request of the 1352 Diameter client (SIP server) to remain as an allocated SIP server, 1353 then the Diameter server MUST keep the SIP server assigned to 1354 those SIP Addresses of Record and MUST set the Result-Code AVP 1355 value to DIAMETER_SUCCESS in the Diameter SAA message. Otherwise, 1356 when the Diameter server does not honor the request of the 1357 Diameter client (SIP server) to remain as an allocated SIP server, 1358 the Diameter server MUST clear the SIP server name assigned to 1359 those SIP Addresses of Record and it MUST set the Result-Code AVP 1360 value to DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED in the Diameter 1361 SAA message. 1362 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1363 message is set to NO_ASSIGNMENT, the Diameter server SHOULD first 1364 verify that the SIP-Server-URI AVP value in the Diameter SAR 1365 message is the same URI as the one assigned to the SIP-AOR AVP 1366 value. If they differ, then the Diameter server MUST set the 1367 Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY in the Diameter 1368 SAA message. Otherwise, if the SIP-User-Data-Already-Available 1369 AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter 1370 server SHOULD include the user profile data with the SIP or SIPS 1371 URI (SIP-AOR AVP) and all other SIP identities associated with 1372 that AVP in the SIP-User-Data AVP value of the Diameter SAA 1373 message. On selecting the type of user data, the Diameter server 1374 SHOULD take into account the supported formats at the SIP server 1375 (SIP-Supported-User-Data-Type AVP in the SAR message) and the 1376 local policy. 1377 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1378 message is set to AUTHENTICATION_FAILURE or 1379 AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there 1380 is exactly one SIP-AOR AVP in the Diameter SAR message. If the 1381 number of occurrences of the SIP-AOR AVP is not exactly one, the 1382 Diameter server MUST set the Result-Code AVP value to 1383 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message, 1384 and SHOULD not take further actions. If there is exactly one SIP- 1385 AOR AVP in the Diameter SAR message, the Diameter server MUST 1386 clear the address of the SIP server assigned to the SIP Address of 1387 Record, and the Diameter server MUST set the Result-Code AVP value 1388 to DIAMETER_SUCCESS in the Diameter SAA message. The Diameter 1389 server MUST consider the SIP AOR as not registered. 1391 Message Format 1392 ::= < Diameter Header: bbb, PXY > 1393 < Session-Id > 1394 { Auth-Application-Id } 1395 { Result-Code } 1396 { Auth-Session-State } 1397 { Origin-Host } 1398 { Origin-Realm } 1399 * [ SIP-User-Data ] 1400 [ SIP-Accounting-Information ] 1401 * [ SIP-Supported-User-Data-Type ] 1402 [ User-Name ] 1403 [ Auth-Grace-Period ] 1404 [ Authorization-Lifetime ] 1405 * [ Redirect-Host ] 1406 [ Redirect-Host-Usage ] 1407 [ Redirect-Max-Cache-Time ] 1408 * [ Proxy-Info ] 1409 * [ Route-Record ] 1410 * [ AVP ] 1412 [Note to IANA and the RFC editor: replace bbb with the actual value 1413 allocated to this command] 1415 7.5 Location-Info-Request (LIR) Command 1417 The Location-Info-Request (LIR) is indicated by the Command-Code set 1418 to ccc [Note to IANA and the RFC editor: replace ccc with the actual 1419 value allocated to this command] and the Command Flags' 'R' bit set. 1420 The Diameter client in a SIP server sends this command to the 1421 Diameter server to request routing information, e.g., the URI of the 1422 SIP server assigned to a particular user. The user is identified by 1423 the SIP-AOR AVP value. 1425 Message Format 1426 ::= < Diameter Header: ccc, REQ, PXY > 1427 < Session-Id > 1428 { Auth-Application-Id } 1429 { Auth-Session-State } 1430 { Origin-Host } 1431 { Origin-Realm } 1432 { Destination-Realm } 1433 { SIP-AOR } 1434 [ Destination-Host ] 1435 * [ Proxy-Info ] 1436 * [ Route-Record ] 1437 * [ AVP ] 1439 [Note to IANA and the RFC editor: replace ccc with the actual value 1440 allocated to this command] 1442 7.6 Location-Info-Answer (LIA) Command 1444 The Location-Info-Answer (LIA) is indicated by the Command-Code set 1445 to ccc [Note to IANA and the RFC editor: replace ccc with the actual 1446 value allocated to this command] and the Command Flags' 'R' bit 1447 cleared. The Diameter server sends this command in response to a 1448 previously received Diameter Location-Info-Request (LIR) command. 1450 In addition to the values already defined in RFC 3588 [RFC3588], the 1451 Result-Code AVP may contain one of the values defined in Section 9.1. 1452 When the Diameter server finds an error in processing the Diameter 1453 LIR message, the Diameter server MUST stop the process of the message 1454 and answer with a Diameter LIA message that includes the appropriate 1455 error code in the Result-Code AVP value. When there is no error, the 1456 Diameter server MUST set the Result-Code AVP value to 1457 DIAMETER_SUCCESS in the Diameter LIA message. 1459 One of the errors that the Diameter server may find is that the SIP- 1460 AOR AVP value is not a valid user in the realm. In such cases, the 1461 Diameter server MUST set the Result-Code AVP value to 1462 DIAMETER_ERROR_USER_UNKNOWN and return it in a Diameter LIA message. 1464 If the Diameter server cannot process the Diameter LIR command, e.g., 1465 due to a database error, the Diameter server MUST set the Result-Code 1466 AVP value to DIAMETER_UNABLE_TO_COMPLY and return it in a Diameter 1467 LIA message. The Diameter server MUST NOT include any SIP-Server-URI 1468 or SIP-Server-Capabilities AVP in the Diameter LIA message. 1470 The Diameter server can or cannot be aware of a SIP server assigned 1471 to the user contained in the SIP-AOR AVP value in the Diameter LIR 1472 message. If the Diameter server is aware of a SIP server allocated 1473 to that particular user, the Diameter server MUST include the URI of 1474 such SIP server in the SIP-Server-URI AVP and return it in a Diameter 1475 LIA message. This is typically the situation when the user is either 1476 registered, or unregistered but there is a SIP server still assigned 1477 to the user. 1479 When the Diameter server is not aware of a SIP server allocated to 1480 the user, typically the case when the user unregistered, the Result- 1481 Code AVP value in the Diameter LIA message depends on whether the 1482 Diameter server is aware that the user has services defined for 1483 unregistered users or not: 1485 o Those users who have services defined for unregistered users may 1486 require the allocation of a SIP server to trigger and perhaps 1487 execute those services. Therefore, when the Diameter server is 1488 not aware of an assigned SIP server, but the user has services 1489 defined for unregistered users, the Diameter server MUST set the 1490 Result-Code AVP value to DIAMETER_UNREGISTERED_SERVICE and return 1491 it in a Diameter LIA message. The Diameter server MAY also 1492 include a SIP-Server-Capabilities AVP to facilitate the SIP server 1493 (Diameter client) with the selection of an appropriate SIP server 1494 with the required capabilities. Absence of the SIP-Server- 1495 Capabilities AVP will indicate to the SIP server (Diameter client) 1496 that any SIP server is suitable to be allocated for the user. 1497 o Those users who do not have service defined for unregistered users 1498 do not require further processing. The Diameter server MUST set 1499 the Result-Code AVP value to 1500 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED and return it to the 1501 Diameter client in a Diameter LIA message. The SIP server 1502 (Diameter client) may return the appropriate SIP response (e.g., 1503 480 (Temporarily unavailable)) to the original SIP request. 1505 Message Format 1506 ::= < Diameter Header: ccc, PXY > 1507 < Session-Id > 1508 { Auth-Application-Id } 1509 { Result-Code } 1510 { Auth-Session-State } 1511 { Origin-Host } 1512 { Origin-Realm } 1513 [ SIP-Server-URI ] 1514 [ SIP-Server-Capabilities ] 1515 [ Auth-Grace-Period ] 1516 [ Authorization-Lifetime ] 1517 * [ Redirect-Host ] 1518 [ Redirect-Host-Usage ] 1519 [ Redirect-Max-Cache-Time ] 1520 * [ Proxy-Info ] 1521 * [ Route-Record ] 1522 * [ AVP ] 1524 [Note to IANA and the RFC editor: replace ccc with the actual value 1525 allocated to this command] 1527 7.7 Multimedia-Auth-Request (MAR) Command 1529 The Multimedia-Auth-Request (MAR) command is indicated by the 1530 Command-Code set to ddd [Note to IANA and the RFC editor: replace ddd 1531 with the actual value allocated to this command] and the Command 1532 Flags' 'R' bit set. The Diameter client in a SIP server sends this 1533 command to the Diameter server to request the Diameter server to 1534 authenticate and authorize a user attempt to use some SIP service (in 1535 this context, SIP service can be something as simple as a SIP 1536 subscription or using the proxy services for a SIP request). Unlike 1537 the Diameter SAR command, MAR does not store any state in the 1538 Diameter server. 1540 The MAR command also registers the SIP server's own URI to the 1541 Diameter server, so that future LIR/LIA messages can return this URI. 1543 The SIP-Method AVP MUST include the SIP method name of the SIP 1544 request that triggered this Diameter MAR message. The Diameter 1545 server can use this AVP to authorize some SIP requests depending on 1546 the method. 1548 The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP 1549 indicates the target of the SIP request. The value of the AVP is 1550 extracted from different places in SIP request, depending on the 1551 semantics of the SIP request. For SIP REGISTER messages the SIP-AOR 1552 AVP value indicates the intended public user identity under 1553 registration, and it is the SIP or SIPS URI populated in the To 1554 header field value (addr-spec, according to the SIP ABNF) of the SIP 1555 REGISTER request. For other types of SIP requests, such as INVITE, 1556 SUBSCRIBE, MESSAGE, etc., the SIP-AOR AVP value indicates the 1557 intended destination of the request. This is typically populated in 1558 the Request-URI of the SIP request. It is the Diameter client 1559 responsibility to extract the SIP-AOR AVP value from the proper SIP 1560 header field. Extensions to SIP (new SIP methods or new semantics) 1561 may require to extract the SIP-AOR from other parts of the request. 1563 If the SIP request includes some sort of authentication information, 1564 the Diameter client MUST include the user name, extracted from the 1565 authentication information of the SIP request, in the User-Name AVP 1566 value. 1568 Message Format 1569 ::= < Diameter Header: ddd, REQ, PXY > 1570 < Session-Id > 1571 { Auth-Application-Id } 1572 { Auth-Session-State } 1573 { Origin-Host } 1574 { Origin-Realm } 1575 { Destination-Realm } 1576 { SIP-AOR } 1577 { SIP-Method } 1578 [ Destination-Host ] 1579 [ User-Name ] 1580 [ SIP-Server-URI ] 1581 [ SIP-Number-Auth-Items ] 1582 [ SIP-Auth-Data-Item ] 1583 * [ Proxy-Info ] 1584 * [ Route-Record ] 1585 * [ AVP ] 1587 [Note to IANA and the RFC editor: replace ddd with the actual value 1588 allocated to this command] 1590 7.8 Multimedia-Auth-Answer (MAA) Command 1592 The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set 1593 to ddd [Note to IANA and the RFC editor: replace ddd with the actual 1594 value allocated to this command] and the Command Flags' 'R' bit 1595 cleared. The Diameter server sends this command in response to a 1596 previously received Diameter Multimedia-Auth-Request (MAR) command. 1598 In addition to the values already defined in RFC 3588 [RFC3588], the 1599 Result-Code AVP may contain one of the values defined in Section 9.1. 1601 If the Diameter server requires a User-Name AVP value to process the 1602 Diameter MAR request, but the Diameter MAR message did not contain a 1603 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1604 value to DIAMETER_USER_NAME_REQUIRED (see Section 9.1.2) and return 1605 it in a Diameter MAA message. The Diameter server MAY include a SIP- 1606 Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs with 1607 authentication information (e.g., a challenge). Upon reception of 1608 this Diameter MAA message with the Result-Code AVP value set to 1609 DIAMETER_USER_NAME_REQUIRED, the SIP server will typically request 1610 authentication by generating a SIP 401 (Unauthorized) or SIP 407 1611 (Proxy Authentication Required) response back to the originator. 1613 If the User-Name AVP is present in the Diameter MAR message, the 1614 Diameter server MUST verify the existence of the user in the realm, 1615 i.e., the User-Name AVP value is a valid user within that realm. If 1616 the Diameter server does not recognize the user name received in the 1617 User-Name AVP, the Diameter server MUST build a Diameter Multimedia- 1618 Auth-Answer (MAA) message and MUST set the Result-Code AVP to 1619 DIAMETER_ERROR_USER_UNKNOWN. 1621 If the SIP-Methods AVP value of the Diameter MAR message is set to 1622 REGISTER and a User-Name AVP is present, then the Diameter server 1623 MUST authorize that User-Name AVP value is able to use the URI 1624 included in the SIP-AOR AVP. If this authorization fails, the 1625 Diameter server must set the Result-Code AVP to 1626 DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter 1627 Multimedia-Auth-Answer (MAA) message. 1629 Correlation between User-Name and SIP-AOR AVP values is only 1630 required for SIP REGISTER request, just to avoid that any user can 1631 register a SIP-AOR allocated to another user. In other types of 1632 SIP requests (e.g., INVITE), the SIP-AOR will indicate the 1633 intended destination of the request, rather than the originator of 1634 it. 1636 Then Diameter server MUST verify whether the authentication scheme 1637 (SIP-Authentication-Scheme AVP value) indicated in the grouped SIP- 1638 Auth-Data-Item AVP is supported or not. If that authentication 1639 scheme is not supported, then the Diameter server MUST set the 1640 Result-Code AVP to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send 1641 it in a Diameter Multimedia-Auth-Answer (MAA) message. 1643 If the received Diameter MAR message contains a grouped SIP- 1644 Authorization AVP within the grouped SIP-Auth-Data-Item AVP, the 1645 Diameter server considers that the authorization information is being 1646 requested after a synchronization failure. In this case, the 1647 sequence of the SIP-Auth-Data-Item AVPs would take into account the 1648 SIP-Authorization AVP value to synchronize the different 1649 authentication credentials. The Diameter server MUST set the Result- 1650 Code AVP to DIAMETER_SUCCESS. 1652 If the SIP-Number-Auth-Items AVP is present in the Diameter MAR 1653 message, it will indicate the number of authentication data items 1654 that the Diameter client is requesting. It is RECOMMENDED that the 1655 Diameter server, when building the Diameter MAA message, includes a 1656 number of SIP-Auth-Data-Item AVPs that is a subset of the 1657 authentication data items requested by the Diameter client in the 1658 SIP-Number-Auth-Items AVP value of the Diameter MAR message. 1660 If the SIP-Server-URI AVP is present in the Diameter MAR message, 1661 then the Diameter server MUST compare the stored SIP server assigned 1662 to the SIP AOR with the SIP-Server-URI AVP value received in the 1663 Diameter MAR message. If there is not a match, the Diameter server 1664 MUST update the stored SIP server assigned to the SIP AOR, and MUST 1665 set an "authentication pending" flag for the SIP AOR. If there is a 1666 match, the Diameter server shall clear the "authentication pending" 1667 flag for the SIP AOR. 1669 In any other situation, if there is a success in processing the 1670 Diameter MAR command and the Diameter server stored the SIP-Server- 1671 URI, the Diameter server MUST set the Result-Code AVP value to 1672 DIAMETER_SUCCESS and return it in a Diameter MAA message. 1674 If there is a success in processing the Diameter MAR command but the 1675 Diameter server does not store the SIP-Server-URI because the AVP was 1676 not present in the Diameter MAR command, then the Diameter server 1677 MUST set the Result-Code AVP value to either: 1679 1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter 1680 server is sending authentication credentials to create a 1681 challenge. 1682 2. DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED, if the Diameter server 1683 successfully authenticated the user and authorized the SIP server 1684 to proceed with the SIP request. 1686 Otherwise, the Diameter server MUST set the Result-Code AVP value to 1687 DIAMETER_UNABLE_TO_COMPLY and it MUST NOT include any SIP-Auth-Data- 1688 Item AVP. 1690 Message Format 1691 ::= < Diameter Header: ddd, PXY > 1692 < Session-Id > 1693 { Auth-Application-Id } 1694 { Result-Code } 1695 { Auth-Session-State } 1696 { Origin-Host } 1697 { Origin-Realm } 1698 [ User-Name ] 1699 [ SIP-AOR ] 1700 [ SIP-Number-Auth-Items ] 1701 * [ SIP-Auth-Data-Item ] 1702 [ Authorization-Lifetime ] 1703 [ Auth-Grace-Period ] 1704 * [ Redirect-Host ] 1705 [ Redirect-Host-Usage ] 1706 [ Redirect-Max-Cache-Time ] 1707 * [ Proxy-Info ] 1708 * [ Route-Record ] 1709 * [ AVP ] 1711 [Note to IANA and the RFC editor: replace ddd with the actual value 1712 allocated to this command] 1714 7.9 Registration-Termination-Request (RTR) Command 1716 The Registration-Termination-Request (RTR) command is indicated by 1717 the Command-Code set to eee [Note to IANA and the RFC editor: replace 1718 eee with the actual value allocated to this command] and the Command 1719 Flags' 'R' bit set. The Diameter server sends this command to the 1720 Diameter client in a SIP server to indicate the SIP server that one 1721 or more SIP AORs have to be de-registered. The command allows an 1722 operator to administratively cancel the registration of a user from a 1723 centralized Diameter server. 1725 The Diameter server has the capability to initiate the de- 1726 registration of a user and inform the SIP server by means of the 1727 Diameter RTR command. The Diameter server can decide whether only 1728 one SIP AOR is going to be deregistered, a list of SIP AORs, or all 1729 the SIP AORs allocated to the user. 1731 The absence of a SIP-AOR AVP in the Diameter RTR message indicates 1732 that all the SIP Addresses of Record allocated to the user identified 1733 by the User-Name AVP are being deregistered. 1735 The Diameter server MUST include a SIP-Deregistration-Reason AVP 1736 value to indicate the reason for the deregistration. 1738 Message Format 1739 ::= < Diameter Header: eee, REQ, PXY > 1740 < Session-Id > 1741 { Auth-Application-Id } 1742 { Auth-Session-State } 1743 { Origin-Host } 1744 { Origin-Realm } 1745 { Destination-Host } 1746 { SIP-Deregistration-Reason } 1747 [ Destination-Realm ] 1748 [ User-Name ] 1749 * [ SIP-AOR ] 1750 * [ Proxy-Info ] 1751 * [ Route-Record ] 1752 * [ AVP ] 1754 [Note to IANA and the RFC editor: replace eee with the actual value 1755 allocated to this command] 1757 7.10 Registration-Termination-Answer (RTA) Command 1759 The Registration-Termination-Answer (RTA) is indicated by the 1760 Command-Code set to eee [Note to IANA and the RFC editor: replace eee 1761 with the actual value allocated to this command] and the Command 1762 Flags' 'R' bit cleared. The Diameter client sends this command in 1763 response to a previously received Diameter Registration-Termination- 1764 Request (RTR) command. 1766 In addition to the values already defined in RFC 3588 [RFC3588], the 1767 Result-Code AVP may contain one of the values defined in Section 9.1. 1769 If the Diameter server requires a User-Name AVP value to process the 1770 Diameter RTR request, but the Diameter RTR message did not contain a 1771 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1772 value to DIAMETER_USER_NAME_REQUIRED (see Section 9.1.2) and return 1773 it in a Diameter RTA message. Upon reception of this Diameter RTA 1774 message with the Result-Code AVP value set to 1775 DIAMETER_USER_NAME_REQUIRED, the SIP server will typically request 1776 authentication by generating a SIP 401 (Unauthorized) or SIP 407 1777 (Proxy Authentication Required) response back to the originator. 1779 The SIP server (Diameter client) will apply the administrative 1780 deregistration to each of the URIs included in each of the SIP-AOR 1781 AVP values, or, if there is no SIP-AOR AVP present in the Diameter 1782 RTR request, to all the URIs allocated to the User-Name AVP value. 1784 The value of the SIP-Deregistration-Reason AVP in the Diameter RTR 1785 command will have an effect on the actions performed at the SIP 1786 server (Diameter client): 1788 o If the value is set to PERMANENT_TERMINATION, then the user has 1789 terminated his/her registration to the realm. The SIP server 1790 (Diameter client), if supported through SIP procedures, SHOULD 1791 inform the interested parties (e.g., subscribers to the 1792 registration event) about the administrative de-registration and 1793 SHOULD NOT request a new user registration. The SIP server SHOULD 1794 clear the registration state of the de-registered AORs. 1795 o If the value is set to NEW_SIP_SERVER_ASSIGNED, the Diameter 1796 server informs the SIP server (Diameter client) that a new SIP 1797 server has been allocated to the user, due to some reason. The 1798 SIP server, if supported through SIP procedures, SHOULD inform the 1799 interested parties (e.g., subscribers to the registration event) 1800 about the administrative de-registration at this SIP server and 1801 SHOULD NOT request a new user registration. The SIP server SHOULD 1802 clear the registration state of the de-registered SIP AORs. 1803 o If the value is set to SIP_SERVER_CHANGE, the Diameter server 1804 informs the SIP server (Diameter client) that a new SIP server has 1805 to be allocated to the user, due to e.g. user's capabilities 1806 requiring a new SIP server, or not enough resources in the current 1807 SIP server. The SIP server, if supported through SIP procedures, 1808 SHOULD inform the interested parties (e.g., subscribers to the 1809 registration event) about the administrative de-registration at 1810 this SIP server and SHOULD request a new user registration. The 1811 SIP server SHOULD clear the registration state of the de- 1812 registered SIP AORs. 1813 o If the value is set to REMOVE_SIP_SERVER, the Diameter server 1814 informs the SIP server (Diameter client) that the SIP server will 1815 no longer be bound in the Diameter server with such user. The SIP 1816 server can delete all data related to the user. 1818 Message Format 1819 ::= < Diameter Header: eee, PXY > 1820 < Session-Id > 1821 { Auth-Application-Id } 1822 { Result-Code } 1823 { Auth-Session-State } 1824 { Origin-Host } 1825 { Origin-Realm } 1826 [ Authorization-Lifetime ] 1827 [ Auth-Grace-Period ] 1828 * [ Redirect-Host ] 1829 [ Redirect-Host-Usage ] 1830 [ Redirect-Max-Cache-Time ] 1831 * [ Proxy-Info ] 1832 * [ Route-Record ] 1833 * [ AVP ] 1835 [Note to IANA and the RFC editor: replace eee with the actual value 1836 allocated to this command] 1838 7.11 Push-Profile-Request (PPR) Command 1840 The Push-Profile-Request (PPR) command is indicated by the Command- 1841 Code set to fff [Note to IANA and the RFC editor: replace fff with 1842 the actual value allocated to this command] and the Command Flags' 1843 'R' bit set. The Diameter server sends this command to the Diameter 1844 client in a SIP server to update the user profile of an already 1845 registered user in that SIP server. This allows an operator to 1846 modify the data of a user profile and push it to the SIP server where 1847 the user is registered. 1849 Each user has a user profile associated with him/her. The profile 1850 may change with time, due to, e.g., addition of new services to the 1851 user. When the user profile changes, the Diameter server sends a 1852 Diameter Push-Profile-Request (PPR) command to the Diameter client in 1853 a SIP server, in order to start applying those new services. 1855 A PPR command MAY contain a SIP-Accounting-Information AVP that 1856 updates the addresses of the accounting servers. Changes in the 1857 addresses of the accounting servers take effect immediately. The 1858 Diameter client SHOULD close any existing accounting session with the 1859 existing server and start providing accounting information to the 1860 newly acquired accounting server. 1862 The Diameter server sends the new user profile in one or more SIP- 1863 User-Data AVP value. On selecting the type of user data, the 1864 Diameter server SHOULD take into account the supported formats at the 1865 SIP server (SIP-Supported-User-Data-Type AVP sent in a previous SAR 1866 message) and the local policy. 1868 The user to who the profile is applicable is indicated by the User- 1869 Name AVP. 1871 Message Format 1872 ::= < Diameter Header: fff, REQ, PXY > 1873 < Session-Id > 1874 { Auth-Application-Id } 1875 { Auth-Session-State } 1876 { Origin-Host } 1877 { Origin-Realm } 1878 { Destination-Realm } 1879 * { SIP-User-Data } 1880 { User-Name } 1881 [ SIP-Accounting-Information ] 1882 [ Destination-Host ] 1883 [ Authorization-Lifetime ] 1884 [ Auth-Grace-Period ] 1885 * [ Proxy-Info ] 1886 * [ Route-Record ] 1887 * [ AVP ] 1889 [Note to IANA and the RFC editor: replace fff with the actual value 1890 allocated to this command] 1892 7.12 Push-Profile-Answer (PPA) Command 1894 The Push-Profile-Answer (PPA) is indicated by the Command-Code set to 1895 fff [Note to IANA and the RFC editor: replace fff with the actual 1896 value allocated to this command] and the Command Flags' 'R' bit 1897 cleared. The Diameter client sends this command in response to a 1898 previously received Diameter Push-Profile-Request (PPR) command. 1900 In addition to the values already defined in RFC 3588 [RFC3588], the 1901 Result-Code AVP may contain one of the values defined in Section 9.1. 1903 If there is no error when processing the received Diameter PPR 1904 message, the SIP server (Diameter client) MUST download the received 1905 user profile from the SIP-User-Data AVP values in the Diameter PPR 1906 message and store it associated with the user specified in the User- 1907 Name AVP value. 1909 If the SIP server does not recognize or does not support some of the 1910 data transferred in the SIP-User-Data AVP values, the Diameter client 1911 in the SIP server MUST return a Diameter PPA message that includes a 1912 Result-Code AVP set to the value 1913 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA. 1915 If the SIP server (Diameter client) receives a Diameter PPR message 1916 with a User-Name AVP that is unknown, the Diameter client MUST set 1917 the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN and MUST 1918 return it to the Diameter server in a Diameter PPA message. 1920 If the SIP server (Diameter client) receives in the SIP-User-Data- 1921 Content AVP value (of the grouped SIP-User-Data AVP) more data than 1922 it can accept, it MUST set the Result-Code AVP value to 1923 DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the Diameter 1924 server in a Diameter PPA message. The SIP server MUST NOT override 1925 the existing user profile with that received in the PPR message. 1927 If the Diameter server receives the Result-Code AVP value set to 1928 DIAMETER_ERROR_TOO_MUCH_DATA in a Diameter PPA message, it SHOULD 1929 force a new re-registration of the user by sending to the Diameter 1930 client a Diameter Registration-Termination-Request (RTR) with the 1931 SIP-Deregistration-Reason AVP value set to SIP_SERVER_CHANGE. This 1932 will force a re-registration of the user, and will trigger a 1933 selection of a new SIP server. 1935 If the Diameter client is not able to honor the command, for any 1936 other reason, it MUST set the Result-Code AVP value to 1937 DIAMETER_UNABLE_TO_COMPLY and it MUST return it in a Diameter PPA 1938 message. 1940 Message Format 1941 ::= < Diameter Header: fff, PXY > 1942 < Session-Id > 1943 { Auth-Application-Id } 1944 { Result-Code } 1945 { Auth-Session-State } 1946 { Origin-Host } 1947 { Origin-Realm } 1948 * [ Redirect-Host ] 1949 [ Redirect-Host-Usage ] 1950 [ Redirect-Max-Cache-Time ] 1951 * [ Proxy-Info ] 1952 * [ Route-Record ] 1953 * [ AVP ] 1955 [Note to IANA and the RFC editor: replace fff with the actual value 1956 allocated to this command] 1958 8. Diameter SIP Application AVPs 1960 This section defines new AVPs used in this Diameter SIP application. 1961 Applications compliant to this specification MUST implement these 1962 AVPs. 1964 Table 2 lists the new AVPs defined in this Diameter SIP application. 1966 The following abbreviations are used in the Data-Type column: 1968 * DURI: DiameterURI 1969 * E: Enumerated 1970 * G: Grouped 1971 * OS: OctetString 1972 * UTF8S: UTF8String 1973 * U32: Unsigned32 1975 +-----------------------------------+------+----------------+-------+ 1976 | AVP Name | AVP | Reference | Data- | 1977 | | Code | | Type | 1978 +-----------------------------------+------+----------------+-------+ 1979 | SIP-Accounting-Information | xx01 | Section 8.1 | G | 1980 | SIP-Accounting-Server-URI | xx02 | Section 8.1.1 | DURI | 1981 | SIP-Credit-Control-Server-URI | xx03 | Section 8.1.2 | DURI | 1982 | SIP-Server-URI | xx04 | Section 8.2 | UTF8S | 1983 | SIP-Server-Capabilities | xx05 | Section 8.3 | G | 1984 | SIP-Mandatory-Capability | xx06 | Section 8.3.1 | U32 | 1985 | SIP-Optional-Capability | xx07 | Section 8.3.2 | U32 | 1986 | SIP-Server-Assignment-Type | xx08 | Section 8.4 | E | 1987 | SIP-Auth-Data-Item | xx09 | Section 8.5 | G | 1988 | SIP-Authentication-Scheme | xx10 | Section 8.5.1 | E | 1989 | SIP-Item-Number | xx11 | Section 8.5.2 | U32 | 1990 | SIP-Authenticate | xx12 | Section 8.5.3 | G | 1991 | SIP-Authorization | xx13 | Section 8.5.4 | G | 1992 | SIP-Authentication-Info | xx14 | Section 8.5.5 | G | 1993 | SIP-Number-Auth-Items | xx15 | Section 8.6 | U32 | 1994 | SIP-Deregistration-Reason | xx16 | Section 8.7 | G | 1995 | SIP-Reason-Code | xx17 | Section 8.7.1 | E | 1996 | SIP-Reason-Info | xx18 | Section 8.7.2 | UTF8S | 1997 | SIP-Visited-Network-Id | xx19 | Section 8.9 | UTF8S | 1998 | SIP-User-Authorization-Type | xx20 | Section 8.10 | E | 1999 | SIP-Supported-User-Data-Type | xx21 | Section 8.11 | UTF8S | 2000 | SIP-User-Data | xx22 | Section 8.12 | G | 2001 | SIP-User-Data-Type | xx23 | Section 8.12.1 | UTF8S | 2002 | SIP-User-Data-Contents | xx24 | Section 8.12.2 | OS | 2003 | SIP-User-Data-Already-Available | xx25 | Section 8.13 | E | 2004 | SIP-Method | xx26 | Section 8.14 | UTF8S | 2005 +-----------------------------------+------+----------------+-------+ 2007 Table 2: Defined AVPs 2009 [Note to IANA and the RFC editor: replace xx01, xx02, xx03, and so on 2010 with the actual values allocated to these AVPs.] 2012 Table 3 expands the table of AVPs included in Section 4.5 of RFC 3588 2013 [RFC3588]. The table indicates the Diameter AVPs defined in this 2014 Diameter SIP Application, their possible flag values, and whether the 2015 AVP may be encrypted. The acronyms 'M', 'P', and 'V' refer to AVP 2016 flags whose semantics are described in RFC 3588 [RFC3588]. The value 2017 of the 'Encr' column is also described in RFC 3588 [RFC3588]. 2019 +---------------------------------+------+------+-----+------+------+ 2020 | AVP Name | MUST | MAY | SHD | MUST | Encr | 2021 | | | | NOT | NOT | | 2022 +---------------------------------+------+------+-----+------+------+ 2023 | SIP-Accounting-Information | M | P | | V | N | 2024 | SIP-Accounting-Server-URI | M | P | | V | N | 2025 | SIP-Credit-Control-Server-URI | M | P | | V | N | 2026 | SIP-Server-URI | M | P | | V | N | 2027 | SIP-Server-Capabilities | M | P | | V | N | 2028 | SIP-Mandatory-Capability | M | P | | V | N | 2029 | SIP-Optional-Capability | M | P | | V | N | 2030 | SIP-Server-Assignment-Type | M | P | | V | N | 2031 | SIP-Auth-Data-Item | M | P | | V | N | 2032 | SIP-Authentication-Scheme | M | P | | V | N | 2033 | SIP-Item-Number | M | P | | V | N | 2034 | SIP-Authenticate | M | P | | V | N | 2035 | SIP-Authorization | M | P | | V | N | 2036 | SIP-Authentication-Info | M | P | | V | N | 2037 | SIP-Number-Auth-Items | M | P | | V | N | 2038 | SIP-Deregistration-Reason | M | P | | V | N | 2039 | SIP-Reason-Code | M | P | | V | N | 2040 | SIP-Reason-Info | M | P | | V | N | 2041 | SIP-Visited-Network-Id | M | P | | V | N | 2042 | SIP-User-Authorization-Type | M | P | | V | N | 2043 | SIP-Supported-User-Data-Type | M | P | | V | N | 2044 | SIP-User-Data | M | P | | V | N | 2045 | SIP-User-Data-Type | M | P | | V | N | 2046 | SIP-User-Data-Contents | M | P | | V | N | 2047 | SIP-User-Data-Already-Available | M | P | | V | N | 2048 | SIP-Method | M | P | | V | N | 2049 +---------------------------------+------+------+-----+------+------+ 2051 Table 3: Summary of the new AVPs flags 2053 8.1 SIP-Accounting-Information AVP 2055 The SIP-Accounting-Information (AVP code xx01) [Note to IANA and the 2056 RFC editor: replace xx01 with the actual value allocated to this AVP] 2057 is of type Grouped, and contains the Diameter addresses of those 2058 nodes that are able to collect accounting information. The Grouped 2059 Data field has the following ABNF grammar: 2061 SIP-Accounting-Information :: = < AVP Header: xx01 > 2062 * [ SIP-Accounting-Server-URI ] 2063 * [ SIP-Credit-Control-Server-URI ] 2064 * [ AVP] 2066 [Note to IANA and the RFC editor: replace xx01 with the actual value 2067 allocated to this AVP] 2069 8.1.1 SIP-Accounting-Server-URI AVP 2071 The SIP-Accounting-Server-URI AVP (AVP Code xx02) [Note to IANA and 2072 the RFC editor: replace xx02 with the actual value allocated to this 2073 AVP] is of type DiameterURI. This AVP contains the address of a 2074 Diameter server that is able to receive SIP session related 2075 accounting information. 2077 8.1.2 SIP-Credit-Control-Server-URI AVP 2079 The SIP-Credit-Control-Server-URI AVP (AVP Code xx03) [Note to IANA 2080 and the RFC editor: replace xx03 with the actual value allocated to 2081 this AVP] is of type DiameterURI. This AVP contains the address of 2082 the a Diameter server that is able to authorize real-time credit 2083 control usage. The Diameter Credit Control Application [I-D.ietf- 2084 aaa-diameter-cc] may be used for this purpose. 2086 8.2 SIP-Server-URI AVP 2088 The SIP-Server-URI AVP (AVP Code xx04) [Note to IANA and the RFC 2089 editor: replace xx04 with the actual value allocated to this AVP] is 2090 of type UTF8String. This AVP contains a SIP or SIPS URI (as defined 2091 in RFC 3261 [RFC3261]) that identifies a SIP server. 2093 8.3 SIP-Server-Capabilities AVP 2095 The SIP-Server-Capabilities AVP (AVP Code xx05) [Note to IANA and the 2096 RFC editor: replace xx05 with the actual value allocated to this AVP] 2097 is of type Grouped. The Diameter indicates in this AVP the 2098 requirements for a particular SIP capability, so that the Diameter 2099 client (SIP server) is able to select another appropriate SIP server 2100 to serve the user. 2102 SIP-Server-Capabilities ::= < AVP Header: xx05 > 2103 * [ SIP-Mandatory-Capability ] 2104 * [ SIP-Optional-Capability ] 2105 * [ SIP-Server-URI ] 2106 * [ AVP ] 2108 [Note to IANA and the RFC editor: replace xx05 with the actual value 2109 allocated to this AVP] 2111 8.3.1 SIP-Mandatory-Capability AVP 2113 The SIP-Mandatory-Capability AVP (AVP Code xx06) [Note to IANA and 2114 the RFC editor: replace xx06 with the actual value allocated to this 2115 AVP] is of type Unsigned32. The value represents a certain 2116 capability (or set of capabilities) that the SIP server to be 2117 allocated to the user has to fulfil. 2119 The semantics of the different values are not standardized, as it is 2120 a matter of the administrative network to allocate its own semantics 2121 within its own network. Each value has to represent a single 2122 capability within the administrative network. 2124 8.3.2 SIP-Optional-Capability AVP 2126 The SIP-Optional-Capability AVP (AVP Code xx07) [Note to IANA and the 2127 RFC editor: replace xx07 with the actual value allocated to this AVP] 2128 is of type Unsigned32. The value represents a certain capability (or 2129 set of capabilities) that the SIP server to be allocated may, 2130 optionally, fulfil. 2132 The semantics of the different values are not standardized, as it is 2133 a matter of the administrative network to allocate its own semantics 2134 within its own network. Each value has to represent a single 2135 capability within the administrative network. 2137 8.4 SIP-Server-Assignment-Type AVP 2139 The SIP-Server-Assignment-Type AVP (AVP code xx08) [Note to IANA and 2140 the RFC editor: replace xx08 with the actual value allocated to this 2141 AVP] is of type Enumerated, and indicates the type of server update 2142 being performed in a Diameter Server-Assignment-Request (SAR) 2143 operation. The following values are defined: 2145 o NO_ASSIGNMENT (0) 2146 The Diameter client uses this value to request the user profile of 2147 a SIP AOR, without affecting the registration state of such 2148 identity. 2149 o REGISTRATION (1) 2150 First SIP registration of a SIP AOR. 2151 o RE_REGISTRATION (2) 2152 Subsequent SIP registration of a SIP AOR. 2153 o UNREGISTERED_USER (3) 2154 The SIP server has received a SIP request (e.g., SIP INVITE) 2155 addressed for a SIP AOR that is not registered. 2157 o TIMEOUT_DEREGISTRATION (4) 2158 The SIP registration timer of an identity has expired. 2159 o USER_DEREGISTRATION (5) 2160 The SIP server has received a request to de-register a SIP AOR. 2161 o TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6) 2162 The SIP registration timer of an identity has expired. The SIP 2163 server keeps the user data stored and requests the Diameter server 2164 to store the SIP server address. 2165 o USER_DEREGISTRATION_STORE_SERVER_NAME (7) 2166 The SIP server has received a user initiated de-registration 2167 request. The SIP server keeps the user data stored and requests 2168 the Diameter server to store the SIP server address. 2169 o ADMINISTRATIVE_DEREGISTRATION (8) 2170 The SIP server, due to administrative reasons, has de-registered a 2171 SIP AOR. 2172 o AUTHENTICATION_FAILURE (9) 2173 The authentication of a user has failed. 2174 o AUTHENTICATION_TIMEOUT (10) 2175 The authentication timer has expired. 2176 o DEREGISTRATION_TOO_MUCH_DATA (11) 2177 The SIP server has requested user profile information from the 2178 Diameter server and has received a volume of data higher than it 2179 can accept. 2181 8.5 SIP-Auth-Data-Item AVP 2183 The SIP-Auth-Data-Item (AVP code xx09) [Note to IANA and the RFC 2184 editor: replace xx09 with the actual value allocated to this AVP] is 2185 of type Grouped and contains the authentication and/or authorization 2186 information pertaining to a user. 2188 When the Diameter server uses the grouped SIP-Auth-Data-Item AVP to 2189 include a SIP-Authenticate AVP, the Diameter server MUST send a 2190 maximum of one authentication data item (e.g., in case the SIP 2191 request contained several credentials). Section 10 contains a 2192 detailed discussion and normative text of the case when a SIP request 2193 contains several credentials. 2195 SIP-Auth-Data-Item :: = < AVP Header: xx09 > 2196 { SIP-Authentication-Scheme } 2197 [ SIP-Item-Number ] 2198 [ SIP-Authenticate ] 2199 [ SIP-Authorization ] 2200 [ SIP-Authentication-Info ] 2201 * [ AVP ] 2203 [Note to IANA and the RFC editor: replace xx09 with the actual value 2204 allocated to this AVP] 2206 8.5.1 SIP-Authentication-Scheme AVP 2208 The SIP-Authentication-Scheme AVP (AVP code xx10) [Note to IANA and 2209 the RFC editor: replace xx10 with the actual value allocated to this 2210 AVP] is of type Enumerated and indicates the authentication scheme 2211 used in the authentication of SIP services. RFC 2617 identifies this 2212 value as an "auth-scheme" (see section 1.2 of RFC 2617 [RFC2617]). 2213 The only currently defined value is: 2215 o DIGEST (0) to indicate HTTP Digest authentication as specified in 2216 RFC 2617 [RFC2617] Section 3.2.1. Derivative work is also 2217 considered Digest authentication scheme, as long as the "auth- 2218 scheme" is identified as Digest in the SIP headers carrying the 2219 HTTP authentication. This includes, e.g., the HTTP Digest 2220 authentication using AKA [RFC3310]. 2222 Each HTTP Digest directive (parameter) is transported in a 2223 corresponding AVP, whose name follows the pattern Digest-*. The 2224 Digest-* AVPs are RADIUS attributes imported from the RADIUS 2225 Extension for Digest Authentication [ietf-radext-digest-auth] 2226 namespace, allowing a smooth transition between RADIUS and Diameter 2227 applications supporting SIP. The Diameter SIP application goes a 2228 step further by grouping the Digest-* AVPs into the SIP-Authenticate, 2229 SIP-Authorization, and SIP-Authentication-Info grouped AVPs, that 2230 correspond to the SIP Authenticate/Proxy-Authenticate, Authorization/ 2231 Proxy-authorization and Authentication-Info headers fields, 2232 respectively. 2234 NOTE: Due to the fact that HTTP Digest authentication [RFC2617] is 2235 the only mandatory authentication mechanism in SIP, this memo only 2236 provides support for HTTP Digest authentication and derivative 2237 work such as HTTP Digest authentication using AKA [RFC3310]. 2238 Extensions to this memo can register new values and new AVPs to 2239 provide support for other authentication schemes. 2241 NOTE: Although RFC 2617 [RFC2617] defines the Basic and Digest 2242 schemes for authenticating HTTP requests, RFC 3261 [RFC3261] only 2243 imports HTTP Digest as a mechanism to provide authentication in 2244 SIP. 2246 8.5.2 SIP-Item-Number AVP 2248 The SIP-Item-Number (AVP code xx11) [Note to IANA and the RFC editor: 2249 replace xx11 with the actual value allocated to this AVP] is of type 2250 Unsigned32, and is included in a SIP-Auth-Data-Item grouped AVP in 2251 circumstances where there are multiple occurrences of SIP-Auth-Data- 2252 Item AVPs and the order of processing is relevant. The AVP indicates 2253 the order in which the Grouped SIP-Auth-Data-Item should be 2254 processed. Lower values of the SIP-Item-Number AVP indicate that the 2255 whole SIP-Auth-Data-Item SHOULD be processed before other SIP-Auth- 2256 Data-Item AVP that contain a higher value number in the SIP-Item- 2257 Number AVP. 2259 8.5.3 SIP-Authenticate AVP 2261 The SIP-Authenticate AVP (AVP code xx12) [Note to IANA and the RFC 2262 editor: replace xx12 with the actual value allocated to this AVP] is 2263 of type Grouped and contains a reconstruction of either the SIP WWW- 2264 Authenticate or Proxy-Authenticate header fields specified in RFC 2265 2617 [RFC2617] for the HTTP Digest authentication scheme. 2266 Additionally, the AVP may include a Digest-HA1 AVP that contains 2267 H(A1) (as defined in RFC 2617 [RFC2617]). H(A1) allows the Diameter 2268 client to create an expected response and compare it with the Digest 2269 response received from the SIP UA. 2271 SIP-Authenticate ::= < AVP Header: xx12 > 2272 { Digest-Realm } 2273 { Digest-Nonce } 2274 [ Digest-Domain ] 2275 [ Digest-Opaque ] 2276 [ Digest-Stale ] 2277 [ Digest-Algorithm ] 2278 [ Digest-QoP ] 2279 [ Digest-HA1] 2280 * [ Digest-Auth-Param ] 2281 * [ AVP ] 2283 [Note to IANA and the RFC editor: replace xx12 with the actual value 2284 allocated to this AVP] 2286 8.5.4 SIP-Authorization AVP 2288 The SIP-Authorization AVP (AVP code xx13) [Note to IANA and the RFC 2289 editor: replace xx13 with the actual value allocated to this AVP] is 2290 of type Grouped and contains a reconstruction of either the SIP 2291 Authorization or Proxy-Authorization header fields specified in RFC 2292 2617 [RFC2617] for the HTTP Digest authentication scheme. 2294 SIP-Authorization ::= < AVP Header: xx13 > 2295 { Digest-Username } 2296 { Digest-Realm } 2297 { Digest-Nonce } 2298 { Digest-URI } 2299 { Digest-Response } 2300 [ Digest-Algorithm ] 2301 [ Digest-CNonce ] 2302 [ Digest-Opaque ] 2303 [ Digest-QoP ] 2304 [ Digest-Nonce-Count ] 2305 [ Digest-Method] 2306 [ Digest-Entity-Body-Hash ] 2307 * [ Digest-Auth-Param ] 2308 * [ AVP ] 2310 [Note to IANA and the RFC editor: replace xx13 with the actual value 2311 allocated to this AVP] 2313 8.5.5 SIP-Authentication-Info AVP 2315 The SIP-Authentication-Info AVP (AVP Code xx14) [Note to IANA and the 2316 RFC editor: replace xx14 with the actual value allocated to this AVP] 2317 is of type Grouped and contains a reconstruction of the SIP 2318 Authentication-Info header specified in RFC 2617 [RFC2617] for the 2319 HTTP Digest authentication scheme. 2321 SIP-Authentication-Info ::= < AVP Header: xx14 > 2322 { Digest-Nextnonce } 2323 [ Digest-QoP ] 2324 [ Digest-Response-Auth ] 2325 [ Digest-CNonce ] 2326 [ Digest-Nonce-Count ] 2327 * [ AVP ] 2329 [Note to IANA and the RFC editor: replace xx14 with the actual value 2330 allocated to this AVP] 2332 Note that, in some cases, the Digest-Response-Auth AVP cannot be 2333 calculated at the Diameter server, but has to be calculated at the 2334 Diameter client (SIP server). For example, if the value of the 2335 quality of protection (qop) parameter in Digest is set to "auth-int", 2336 then the response-digest (rspauth parameter value in Digest) is 2337 calculated with the hash of the body of the SIP response, which is 2338 not available at the Diameter server. In this case, the Diameter 2339 client (SIP server) must calculate the response-digest once the body 2340 of the SIP response will be calculated. 2342 Therefore, a value of "auth-int" in the Digest-QoP AVP of the SIP- 2343 Authentication-Info AVP indicates that the Diameter client (SIP 2344 server) MUST compute the Digest "rspauth" parameter value at the 2345 Diameter client (SIP server). 2347 8.5.6 Digest AVPs 2349 The following AVPs are RADIUS attributes defined in the RADIUS 2350 Extension for Digest Authentication [ietf-radext-digest-auth] and 2351 imported by this specification: Digest-AKA-Auts, Digest-Algorithm, 2352 Digest-Auth-Param, Digest-CNonce, Digest-Domain, Digest-Entity-Body- 2353 Hash, Digest-HA1, Digest-Method, Digest-Nextnonce, Digest-Nonce, 2354 Digest-Nonce-Count, Digest-Opaque, Digest-QoP, Digest-Realm, Digest- 2355 Response, Digest-Response-Auth, Digest-URI, Digest-Username, and 2356 Digest-Stale. 2358 8.5.6.1 Considerations about Digest-HA1 AVP 2360 The Digest-HA1 AVP contains the value, pre-calculated at the Diameter 2361 server, of H(A1) as defined in RFC 2617 [RFC2617]. The Diameter 2362 client can use H(A1) to calculate the expected Digest response, 2363 according to this challenge. If the SIP UA is in possession of the 2364 credentials, the calculated expected response and the response sent 2365 from the SIP UA will match. The Diameter server MAY include this AVP 2366 to enable and assist the SIP server in authenticating the SIP UA. 2367 This pre-authentication mechanism is only applicable when the SIP UA 2368 does not use client nonces (see below). 2370 It is up to the Diameter server to include a Digest-HA1 AVP. The 2371 Diameter server calculates the Digest H(A1) with the username, 2372 password, realm, (and nonce and cnonce if applicable), as inputs, and 2373 places the result in the Digest-HA1 AVP value. For more details of 2374 the A1 computation see RFC 2617 [RFC2617] Section 3.2.2.2. The 2375 Diameter client can calculate the Digest expected response with H(A1) 2376 as input, as described in RFC 2617 [RFC2617] Section 3.2.2. 2378 Please note that the expected response calculation does not take into 2379 account any client nonces, since the Diameter server does not have 2380 them at the time of calculation. Therefore, the Diameter client MUST 2381 NOT use the Digest-HA1 AVP if the SIP UA sent a expected response 2382 based on client nonces (e.g., if the "qop" parameter is present in 2383 the Digest header). 2385 Section 10 provide further normative details about the usage of the 2386 Digest-HA1 AVP. 2388 8.5.6.2 Considerations about Digest-Entity-Body-Hash AVP 2390 The Digest-Entity-Body-Hash AVP contains a hash of the entity body 2391 contained in the SIP message. This hash is required by HTTP Digest 2392 with quality of protection set to "auth-int". Diameter clients MUST 2393 use this AVP to transport the hash of the entity body when HTTP 2394 Digest is the authentication mechanism and the Diameter server 2395 requires to verify the integrity of the entity body (e.g., qop 2396 parameter set to "auth-int"). 2398 The clarifications described in Section 22.4 of RFC 3261 [RFC3261] 2399 about the hash of empty entity bodies apply to the Digest-Entity- 2400 Body-Hash AVP. 2402 8.5.6.3 Considerations about Digest-Auth-Param AVP 2404 The Digest-Auth-Param AVP is the mechanism whereby the Diameter 2405 client and Diameter server can exchange possible extension parameters 2406 contained in Digest headers that are not understood by the Diameter 2407 client and for which there are no corresponding stand-alone AVPs. 2408 Unlike the previously listed Digest-* AVPs, the Digest-Auth-Param 2409 contains not only the value, but also the parameter name, since the 2410 parameter name is unknown to the Diameter client. The Diameter node 2411 MUST insert one Digest parameter/value combination per AVP value. If 2412 the Digest header contains several unknown parameters, then the 2413 Diameter implementation MUST repeat this AVP and each instance MUST 2414 contain one different unknown Digest parameter/value combination. 2415 This AVP corresponds to the "auth-param" parameter defined in Section 2416 3.2.1 of RFC 2617 [RFC2617]. 2418 Example: Assume that the Diameter server wants the SIP server to send 2419 a "foo" parameter with the value set to "bar", so that the SIP server 2420 sends that combination in a SIP WWW-Authenticate header field. The 2421 Diameter server builds a grouped SIP-Authenticate AVP that contains a 2422 Digest-Auth-Param whose value is set to foo="bar". Then the SIP 2423 server creates the WWW-Authenticate header field with all the digest 2424 parameters (received in Digest-* AVPs) and adds the foo="bar" 2425 parameter to that header field. 2427 8.6 SIP-Number-Auth-Items AVP 2429 The SIP-Number-Auth-Items AVP (AVP Code xx15) [Note to IANA and the 2430 RFC editor: replace xx15 with the actual value allocated to this 2431 AVP]is of type Unsigned32 and indicates the number of authentication 2432 and/or authorization credentials that the Diameter server included in 2433 a Diameter message. 2435 When the AVP is present in a request, it indicates the number of SIP- 2436 Auth-Data-Items the Diameter client is requesting. This can be used, 2437 for instance, when the SIP server is requesting several pre- 2438 calculated authentication credentials. In the answer message, the 2439 SIP-Number-Auth-Items AVP indicates the actual number of items that 2440 the Diameter server included. 2442 8.7 SIP-Deregistration-Reason AVP 2444 The SIP-Deregistration-Reason AVP (AVP Code xx16) [Note to IANA and 2445 the RFC editor: replace xx16 with the actual value allocated to this 2446 AVP] is of type Grouped, and indicates the reason for a 2447 deregistration operation. 2449 SIP-Deregistration-Reason ::= < AVP Header: xx16 > 2450 { SIP-Reason-Code } 2451 [ SIP-Reason-Info ] 2452 * [ AVP ] 2454 [Note to IANA and the RFC editor: replace xx16 with the actual value 2455 allocated to this AVP] 2457 8.7.1 SIP-Reason-Code AVP 2459 The SIP-Reason-Code AVP (AVP code xx17) [Note to IANA and the RFC 2460 editor: replace xx17 with the actual value allocated to this AVP] is 2461 of type Enumerated, and defines the reason for the network initiated 2462 de-registration. The following values are defined: 2464 o PERMANENT_TERMINATION (0) 2465 o NEW_SIP_SERVER_ASSIGNED (1) 2466 o SIP_SERVER_CHANGE (2) 2467 o REMOVE_SIP_SERVER (3) 2469 8.7.2 SIP-Reason-Info AVP 2471 The SIP-Reason-Info AVP (AVP code xx18) [Note to IANA and the RFC 2472 editor: replace xx18 with the actual value allocated to this AVP] is 2473 of type UTF8String, and contains textual information that can be 2474 rendered to the user, about the reason for a de-registration. 2476 8.8 SIP-AOR AVP 2478 The SIP-AOR AVP is a RADIUS attribute imported from the RADIUS 2479 Extension for Digest Authentication [ietf-radext-digest-auth] 2480 namespace, allowing a smooth transition between RADIUS and Diameter 2481 applications supporting SIP. The SIP-AOR AVP carries the URI of the 2482 intended user related to the SIP request (whose location in SIP may 2483 vary depending on the actual SIP request and whether the SIP server 2484 is acting on Diameter due to a SIP originated or terminating 2485 requests). 2487 The Diameter client (SIP server) uses the value found in a SIP 2488 Request-URI or a header field value of the SIP request to construct 2489 the SIP-AOR AVP. The selection of a Request-URI or a particular 2490 header field to create the value of the SIP-AOR AVP depends on the 2491 semantics of the SIP message and whether the SIP server is acting for 2492 originating or terminating requests. For instance, when the SIP 2493 server receives an INVITE request addressed to the served user (e.g., 2494 the SIP server is receiving a terminating SIP request), it maps the 2495 SIP Request-URI of the SIP request to this AVP. However, when the 2496 SIP server receives an INVITE request originated by the served user, 2497 it can map either the P-Asserted-Identity or the From header field 2498 values to this AVP. If the SIP server is acting as a SIP registrar, 2499 then it maps the To header field of the REGISTER request to the SIP- 2500 AOR AVP. 2502 8.9 SIP-Visited-Network-Id AVP 2504 The SIP-Visited-Network-Id AVP (AVP Code xx19) [Note to IANA and the 2505 RFC editor: replace xx19 with the actual value allocated to this AVP] 2506 is of type UTF8String. This AVP contains an identifier that helps 2507 the home network to identify the visited network (e.g. the visited 2508 network domain name), in order to authorize roaming to such visited 2509 network. 2511 8.10 SIP-User-Authorization-Type AVP 2513 The SIP-User-Authorization-Type AVP (AVP code xx20) [Note to IANA and 2514 the RFC editor: replace xx20 with the actual value allocated to this 2515 AVP] is of type Enumerated, and indicates the type of user 2516 authorization being performed in a User Authorization operation, 2517 i.e., the Diameter User-Authorization-Request (UAR) command. The 2518 following values are defined: 2520 o REGISTRATION (0) 2521 This value is used in case of the initial registration or re- 2522 registration. 2523 This is the default value. 2524 o DE_REGISTRATION (1) 2525 This value is used in case of the de-registration. 2526 o REGISTRATION_AND_CAPABILITIES (2) 2527 This value is used in case of initial registration or re- 2528 registration when the SIP server explicitly requests the Diameter 2529 server to get capability information. This capability information 2530 will help the SIP server to allocate another SIP server to serve 2531 the user. 2533 8.11 SIP-Supported-User-Data-Type AVP 2535 The SIP-Supported-User-Data-Type AVP (AVP Code xx21) [Note to IANA 2536 and the RFC editor: replace xx21 with the actual value allocated to 2537 this AVP] is of type UTF8String, and contains a string that 2538 identifies the type of supported user data (user profile, see SIP- 2539 User-Data AVP (Section 8.12)) supported in the node. The AVP can be 2540 repeated, if the SIP server supports several user data types. In 2541 case of repetition, the Diameter client should order the different 2542 instances of this AVP according to its preferences. 2544 When the Diameter client inserts this AVP in a SAR message, it allows 2545 the Diameter client to provide an indication to the Diameter server 2546 of the types of user data supported by the SIP server. The Diameter 2547 server, upon inspection of these AVPs, will return a suitable SIP- 2548 User-Data AVP (Section 8.12) of the type indicated in the SIP-User- 2549 Data-Type AVP (Section 8.12.1). 2551 8.12 SIP-User-Data AVP 2553 The SIP-User-Data AVP (AVP Code xx22) [Note to IANA and the RFC 2554 editor: replace xx22 with the actual value allocated to this AVP] is 2555 of type Grouped. This AVP allows the Diameter server to transport 2556 user specific data, such as a user profile, to the SIP server (in the 2557 Diameter client). The Diameter server selects a type of user data 2558 that is understood by the SIP server in the Diameter client, and has 2559 been indicated in a SIP-Supported-User-Data-Type AVP. In case the 2560 Diameter client indicated support for several types of user data, the 2561 Diameter server SHOULD choose the first type supported by the client. 2563 The SIP-User-Data grouped AVP contains a SIP-User-Data-Type AVP, that 2564 indicates the type of user data included in the SIP-User-Data- 2565 Contents-AVP. 2567 SIP-User-Data ::= < AVP Header: xx22 > 2568 { SIP-User-Data-Type } 2569 { SIP-User-Data-Contents } 2570 * [ AVP ] 2572 [Note to IANA and the RFC editor: replace xx22 with the actual value 2573 allocated to this AVP] 2575 8.12.1 SIP-User-Data-Type AVP 2577 The SIP-User-Data AVP (AVP Code xx23) [Note to IANA and the RFC 2578 editor: replace xx23 with the actual value allocated to this AVP] is 2579 of type UTF8String, and contains a string that identifies the type of 2580 user data included in the SIP-User-Data AVP (Section 8.12). 2582 This document does not specify a convention to characterize the type 2583 of user data contained in the SIP-User-Data AVP (Section 8.12). It 2584 is believed that in most cases this feature will be used in 2585 environments controlled by a network administrator who can configure 2586 both the client and server to assign the same value type at the 2587 client and server. It is also RECOMMENDED that organizations 2588 developing their own profile of SIP-User-Data AVP (Section 8.12) 2589 allocate a type based on their canonical DNS name. For instance, 2590 organization "example.com" can define several types of SIP-User-Data 2591 and allocate the types "type1.dsa.example.com", 2592 "type2.dsa.example.com", and so on. This convention will avoid a 2593 clash in the allocation of types of SIP-User-Data AVP (Section 8.12). 2595 8.12.2 SIP-User-Data-Contents AVP 2597 The SIP-User-Data-Contents AVP (AVP Code xx24) [Note to IANA and the 2598 RFC editor: replace xx24 with the actual value allocated to this AVP] 2599 is of type OctetString. The Diameter peers do not need to understand 2600 the value of this AVP. 2602 The AVP contains the user profile data required for a SIP server to 2603 give service to the user. 2605 8.13 SIP-User-Data-Already-Available AVP 2607 The SIP-User-Data-Already-Available AVP (AVP code xx25) [Note to IANA 2608 and the RFC editor: replace xx25 with the actual value allocated to 2609 this AVP] is of type Enumerated, and gives an indication to the 2610 Diameter server about whether the Diameter client (SIP server) 2611 already got the portion of the user profile that it needs to serve 2612 the user. The following values are defined: 2614 o USER_DATA_NOT_AVAILABLE (0) 2615 The Diameter client (SIP server) does not have the data that it 2616 needs to serve the user. 2617 o USER_DATA_ALREADY_AVAILABLE (1) 2618 The Diameter client (SIP server) already has got the data that it 2619 needs to serve the user. 2621 8.14 SIP-Method AVP 2623 The SIP-Method-AVP (AVP code xx26) [Note to IANA and the RFC editor: 2624 replace xx26 with the actual value allocated to this AVP] is of type 2625 UTF8String and contains the method of the SIP request that triggered 2626 the Diameter message. The Diameter server MUST use this AVP solely 2627 to for authorization of SIP requests, and MUST NOT use it to compute 2628 the Digest authentication. To compute the Digest authentication, the 2629 Diameter server MUST use the Digest-Method AVP instead. 2631 9. New Values for Existing AVPs 2633 This section defines new values that the Diameter SIP application 2634 extends to already existing AVPs. 2636 9.1 Extension to the Result-Code AVP Values 2638 The Result-Code AVP is already defined in RFC 3588 [RFC3588]. In 2639 addition to the values already defined in RFC 3588 [RFC3588], the 2640 Diameter SIP application defines the following new Result-Code AVP 2641 values: 2643 9.1.1 Success Result-Code AVP Values 2645 A Diameter peer uses Result-Code AVP values that fall into the 2646 success category to inform the remote peer that a request has been 2647 successfully completed. 2649 [Note to IANA and the RFC editor: replace 2xxy with the actual values 2650 allocated to the Result-Code AVP] 2652 o DIAMETER_FIRST_REGISTRATION 2xx1 2653 The user was not previously registered. The Diameter server has 2654 now authorized the registration. 2655 o DIAMETER_SUBSEQUENT_REGISTRATION 2xx2 2656 The user is already registered. The Diameter server has now 2657 authorized the re-registration. 2658 o DIAMETER_UNREGISTERED_SERVICE 2xx3 2659 The user is not currently registered, but the requested service 2660 can still be granted to the user. 2661 o DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2xx4 2662 The request operation was successfully processed. The Diameter 2663 server does not keep a record of the SIP server address assigned 2664 to the user. 2665 o DIAMETER_SERVER_SELECTION 2xx5 2666 The Diameter server has authorized the registration. The user has 2667 already a SIP server assigned, but it may be necessary to select a 2668 new SIP server for the user. 2669 o DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED 2xx6 2670 The requested operation was successfully executed. The Diameter 2671 server is sending a number of authentication credentials in the 2672 answer message. The Diameter server does not keep a record of the 2673 SIP server. 2675 9.1.2 Transient Failures Result-Code AVP Values 2677 A Diameter peer uses a Result-Code AVP value that falls in the 2678 transient failures category to inform the remote peer that a request 2679 could not be satisfied at the time it was received, but MAY be able 2680 to satisfy the request in the future. 2682 [Note to IANA and the RFC editor: replace 4xxy with the actual values 2683 allocated to the Result-Code AVP] 2685 o DIAMETER_USER_NAME_REQUIRED 4xx1 2686 The Diameter request did not contain a User-Name AVP, and it is 2687 required to complete the transaction. The Diameter peer MAY 2688 attempt the request again including a User-Name AVP. 2690 9.1.3 Permanent failures Result-Code AVP Values 2692 A Diameter peer uses a Result-Code AVP value that fall into the 2693 permanent failure category to inform the remote peer that the request 2694 failed and should not be attempted again. 2696 [Note to IANA and the RFC editor: replace 5xxy with the actual values 2697 allocated to the Result-Code AVP] 2699 o DIAMETER_ERROR_USER_UNKNOWN 5xx1 2700 The SIP-AOR AVP value does not belong to a known user in this 2701 realm. 2702 o DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5xx2 2703 The value in one of the SIP-AOR AVPs is not allocated to the user 2704 specified in the User-Name AVP. 2705 o DIAMETER_ERROR_IDENTITY_NOT_REGISTERED 5xx3 2706 A query for location information is received for a SIP AOR that 2707 has not been registered before. The user to which this identity 2708 belongs cannot be given service in this situation. 2709 o DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5xx4 2710 The user is not allowed to roam to the visited network. 2711 o DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5xx5 2712 The identity being registered has already a server assigned and 2713 the registration status does not allow that it is overwritten. 2714 o DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED 5xx6 2715 The authentication scheme indicated in an authentication request 2716 is not supported. 2717 o DIAMETER_ERROR_IN_ASSIGNMENT_TYPE 5xx7 2718 The SIP server address sent in the SIP-Server-URI AVP value of the 2719 Diameter Server-Assignment-Request (SAR) command is the same SIP 2720 server address that is currently assigned, but the SIP-Server- 2721 Assignment-Type AVP is not allowed, e.g., the user is registered 2722 and the Server-Assignment-Request indicates the assignment for an 2723 unregistered user. 2724 o DIAMETER_ERROR_TOO_MUCH_DATA 5xx8 2725 The Diameter peer in the SIP server receives more data than it can 2726 accept. The SIP server cannot overwrite the already stored data. 2728 o DIAMETER_ERROR_NOT SUPPORTED_USER_DATA 5xx9 2729 The SIP server informs Diameter server that the received 2730 subscription data contained information which was not recognized 2731 or supported. 2733 10. Authentication Details 2735 Authenticating a user can occur through various mechanisms. 2736 Currently HTTP Digest authentication is supported. The actual 2737 authentication is performed in either the SIP server or the Diameter 2738 server. 2740 If the Diameter server wants to assure that authentication will take 2741 place in the own Diameter server (as opposed to a delegated 2742 authentication taking place in the SIP server), it MUST NOT include a 2743 Digest-HA1 AVP (part of the grouped SIP-Authenticate AVP which in 2744 turn is part of the SIP-Auth-Data-Item AVP) in a MAA message. The 2745 Diameter server MAY include a pre-calculated Digest-HA1 AVP in the 2746 MAA message if it wants to delegate authentication of the user to the 2747 SIP server. 2749 Note that on systems where the SIP User Agent is using HTTP Digest 2750 authentication [RFC2617] inside of TLS [RFC2246], where only the SIP 2751 proxy server has a certificate, delegating authentication to the SIP 2752 server (by making Digest-HA1 available to the SIP server) might 2753 reduce the load on the Diameter server. 2755 When requesting authentication, the Diameter client indicates in the 2756 SIP-Number-Auth-Items AVP value of a Diameter MAR message how many 2757 authentication credentials are being requested. In the Diameter MAA 2758 message, the Diameter server MAY include more than one SIP-Auth-Data- 2759 Item AVP, but it is only useful for the Diameter client if the the 2760 Digest-QoP AVP was set to 'auth-int' (in the MAR message), and if 2761 future authenticatiosn will have the same realm. On including more 2762 than one SIP-Auth-Data-Item AVP the Diameter server SHOULD indicate 2763 how many instances of SIP-Auth-Data-Item AVPs are present with the 2764 SIP-Number-Auth-Items AVP. This number may be different from the one 2765 requested in the Diameter MAR message. If multiple SIP-Auth-Data- 2766 Item AVPs are present, and their ordering is significant, the 2767 Diameter server MUST include a SIP-Item-Number AVP in each grouping 2768 to indicate the order. The SIP-Authentication-Scheme AVP will 2769 indicate "Digest" and the SIP-Authenticate AVP will contain data 2770 (typically a challenge of some kind) which the user can use for her 2771 authentication. The grouped SIP-Authorization AVP will contain the 2772 AVPs that conform the response which is expected from the user. 2774 If the Diameter server performs the authentication of the user, the 2775 Diameter MAR message that the Diameter client sends to the Diameter 2776 server MUST include all the authentication credentials supplied by 2777 the SIP UA (there might be more than one credential, e.g., different 2778 realms, authentication of proxies, etc.). Each credential is 2779 inserted in a grouped SIP-Authorization AVP (part of the grouped SIP- 2780 Auth-Data-Item AVP). The Diameter client MUST insert a SIP-Number- 2781 Auth-Items AVP with the value set to the number of credentials 2782 enclosed. If necessary, the Digest-Entity-Body-Hash AVP will contain 2783 a hash of the body, needed to perform the authentication. If the 2784 authentication is successful, the Diameter MAA message will contain a 2785 Result-Code AVP indicating success, and if necessary, the Diameter 2786 server MAY include one or more SIP-Auth-Data-Item AVPs to provide 2787 further authentication credentials to the SIP server. If the 2788 authentication is unsuccessful due to missing credentials, the 2789 Diameter MAA message will include an SIP-Auth-Data-Item AVP with the 2790 SIP-Authentication-Scheme and SIP-Authenticate AVPs containing data 2791 (typically a challenge of some kind) that the user can use to 2792 authenticate itself. 2794 There are situations where a SIP request traverses several proxies, 2795 and each of the proxies request to authenticate the SIP UA. In this 2796 situation, it is a valid scenario that a SIP request received at a 2797 SIP server contains several sets of credentials. The 'realm' 2798 directive in HTTP is the key that the Diameter client can use to 2799 determine which credential is applicable. It may happen also that 2800 none of the realms are of interests to the Diameter client, in which 2801 case the Diameter client MUST consider that no credentials (of 2802 interest) were sent. In any case, a Diameter client MUST send zero 2803 or exactly one credential to the Diameter server. The Diameter 2804 client MUST choose the credential based on the 'realm' directive in 2805 the Authorization/Proxy-Authorization header field, and it MUST match 2806 the realm of the Diameter client. 2808 11. IANA Considerations 2810 This document serves as IANA registration request for a number of 2811 items that should be registered in the AAA parameters registry. 2813 11.1 Application Identifier 2815 This document defines a standards-track Application-ID that falls 2816 into the Application Identifier standards-track address space defined 2817 by RFC 3588 [RFC3588] Section 11.3. This Application ID should be 2818 registered in the Application IDs sub-registry of the AAA parameters 2819 registry with the following data: 2821 ID values Name Reference 2822 ----------- ------------------------ --------- 2823 XXX Diameter Session Initiation [RFC YYYY] 2824 Protocol (SIP) Application 2826 [Note to IANA and the RFC Editor: replace XXX with the allocated 2827 number, YYYY with the RFC number of this specification] 2829 11.2 Command Codes 2831 This document defines new standard commands, whose Command Codes are 2832 to be allocated within the standard permanent Command Codes address 2833 space defined in RFC 3588 [RFC3588] Section 11.2.1. These command 2834 codes should be registered in the Command Codes sub-registry of the 2835 AAA parameters registry. 2837 Table 1 in Section 7 contains the detailed list of Command Code names 2838 and values that are part of this Diameter application. 2840 11.3 AVP Codes 2842 This document defines new standard AVPs, whose AVP Codes are to be 2843 allocated within the AVP Codes address space defined in RFC 3588 2844 [RFC3588] Section 11.4. These AVP codes should be registered in the 2845 AVP Codes sub-registry of the AAA parameters registry. 2847 Table 2 in Section 8 contains the detailed list of AVP names and AVP 2848 codes that are part of this Diameter application. 2850 11.4 Additional Values for the Result-Code AVP Value 2852 This document defines new standard Result-Code AVP values to be 2853 allocated within the Result-Code AVP address space defined in RFC 2854 3588 [RFC3588] Section 14.4.1. These values should be listed in the 2855 Result-Code AVP values section of the AVP Specific Values sub- 2856 registry of the AAA parameters registry. 2858 Section 9.1.1 lists the new Result-Code AVP values that fall into the 2859 success category, according to RFC 3588 [RFC3588] Section 7.1.2. 2861 Section 9.1.2 lists the new Result-Code AVP values that fall into the 2862 transient failure category, according to RFC 3588 [RFC3588] Section 2863 7.1.4. 2865 Section 9.1.3 lists the new Result-Code AVP values that fall into the 2866 permanent failures category, according to RFC 3588 [RFC3588] Section 2867 7.1.5. 2869 12. Security Considerations 2871 This memo does not describe a stand-alone protocol, but a particular 2872 application for the Diameter protocol [RFC3588]. Consequently, all 2873 the security considerations applicable to Diameter automatically 2874 apply to this memo. In particular, section 13 of RFC 3588 applies to 2875 this memo. 2877 This Diameter SIP application allows a Diameter client to use the 2878 properties of HTTP Digest authentication [RFC2617] by evaluating or 2879 sending to the Diameter server the credentials supplied by a user. 2880 When Section 4 of RFC 2617 [RFC2617] discusses HTTP Digest 2881 authentication, it is also applicable to this memo. 2883 This Diameter SIP application also allows a Diameter client to use 2884 the properties of HTTP Digest authentication using AKA [RFC3310] by 2885 evaluating or sending to the Diameter server the credentials supplied 2886 by a user. Section 5 of RFC 3310 [RFC3310] is also applicable to 2887 this memo. 2889 13. Contributors 2891 The authors would like to thank the following contributors who made 2892 substantial contributions to this work: 2894 Pete McCann Lucent 2895 Jaako Rajaniemi Nokia 2897 14. Acknowledgements 2899 The authors would like to thank Tony Johansson and Kevin Purser for 2900 their invaluable contribution to the start up of this application and 2901 the continuous progress. The authors would like to thank Daniel 2902 Warren, Jayshree Bharatia, Kuntal Chowdhury, Jari Arkko, Avi Lior, 2903 Wolfgang Beck, Ulrich Wiehe, and Cullen Jennings for their valuable 2904 comments. 2906 The Diameter SIP Application is based on the Diameter Application for 2907 the Cx interface of the 3GPP IP Multimedia Subsystem [3GPP.29.229]. 2908 The authors would like to thank 3GPP Working Group CN4 for this work. 2910 15. Changes With Respect Previous Versions 2912 Note to the RFC editor: Delete this section before publication as 2913 RFC. 2915 15.1 Changes in draft-ietf-aaa-diameter-sip-app-07.txt from -06.txt 2917 o Added Table 3 that includes a summary of all the AVPs defined by 2918 this specification are the AVP flags. 2919 o Title in Section 5.4 is changed to "SIP Server Requests 2920 Authentication and Authorization" 2921 o Fixed typo in Section 7.7 that compared MAR with UAR (about 2922 storing state). The comparison should have been done with SAR. 2923 o Section 8.5 wrongly indicated that the Diameter client could send 2924 a SIP-Authenticate AVP. Actually, the Diameter *** server *** is 2925 the peer that sends SIP-Authenticate AVPs. 2926 o The draft used to speak about "authentication vectors". The 2927 terminology has been replaced by "a number of authentication 2928 credentials", which is more aligned with HTTP Digest. 2929 o On Section 10, a paragraph that used to couple Digest-HA1 with the 2930 qop value has been removed: it was a left over from a previous 2931 version of the document. 2933 15.2 Changes in draft-ietf-aaa-diameter-sip-app-06.txt from -05.txt 2935 o The SIP-AOR AVP is now imported from the RADIUS Extension for 2936 Digest Authentication [ietf-radext-digest-auth]. More information 2937 of how to derive the SIP-AOR from the SIP message is provided. 2938 o The Authentication Details section now tries to clarify the 2939 possibility of delegation of authentication to the SIP server, and 2940 cases where it might unload the Diameter server. 2942 15.3 Changes in draft-ietf-aaa-diameter-sip-app-05.txt from -04.txt 2944 o The Digest-* AVPs are imported from the RADIUS Extension for 2945 Digest Authentication [ietf-radext-digest-auth]. An introduction 2946 paragraph has been added in Section 8.5.1. 2947 o As a side effect of the above change, the SIP-Authentication- 2948 Context disappeared. This was a grouped AVP that only contained a 2949 Digest-Entity-Body-Hash AVP. The latter will remain (in the 2950 RADIUS draft). 2951 o The Digest-Expected-Response was considered not secure enough. 2952 Instead, the Digest-Expected-Response has been replaced by Digest- 2953 HA1, which contains a hash of A1 (see RFC 2617 [RFC2617] Section 2954 3.2.2 for more details. This allows the Diameter server to 2955 delegate the final authentication to the Diameter client in a 2956 secure way. The Digest-HA1 AVP is also imported from RADIUS 2957 Extension for Digest Authentication [ietf-radext-digest-auth]. 2958 o The Digest-Digest-URI has been renamed as Digest-URI, as it is now 2959 imported from RADIUS Extension for Digest Authentication [ietf- 2960 radext-digest-auth]. 2962 o The SIP-Accounting-Information AVP was originally specified in the 2963 SAA command. It has been also added to the PPR command, so that 2964 it is possible that PPR updates the addresses of the accounting 2965 servers. 2966 o It has been clarified that when the Diameter client receives a 2967 answer command that contains the Result-Code AVP set to 2968 DIAMETER_USER_NAME_REQUIRED the SIP server will typically request 2969 authentication. Previously, the description seemed to indicate 2970 that this typical action applied to any Result-Code. 2971 o The TEL URI (RFC 2806bis) is now known as RFC 3966. 2972 o If multiple SIP proxies are authenticating the user, the SIP 2973 request may contain several Proxy-Authorization headers. The 2974 Diameter server cannot send all the credentials, since the 2975 Diameter server may be serving several common realms for which 2976 credentials exist. In this situation the Diameter server will not 2977 known which credentials to use. It has been clarified that the 2978 Diameter client MUST send only one set of credentials at a time, 2979 those belonging to the served realm. 2980 o Reference added to RFC 3588 when a Subscriber Locator Function can 2981 populate the Redirect-Host-Usage with the value ALL_USER. 2982 o The IANA registration section has clarified what are the registry 2983 and sub-registries where IANA needs to take an action. 2985 15.4 Changes in draft-ietf-aaa-diameter-sip-app-04.txt from -03.txt 2987 o DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED and 2988 DIAMETER_SUCCESS_SERVER_NOT_STORED have the same semantics: the 2989 former is kept, the latter is deleted. 2990 o Added a new Digest-Method AVP. This AVP contains the method used 2991 to compute the Digest authentication, and it is independent from 2992 the SIP-Method AVP. It has been clarified that Digest-Method is 2993 used for authentication whereas SIP-Method is used for 2994 authorization. 2995 o SIP-User-Data-Request-Type AVP is removed. Its purpose was to 2996 retrieve a fraction of the user profile. This seems to create 2997 expensive complexity, and we don't seem to have requirements to 2998 support this function anymore. 2999 o Fixed the general section layout. Some sections got, by accident, 3000 buried in deep level section. 3001 o The grouped SIP-Authenticate AVP allowed multiple instances of the 3002 Digest-Expected-Response AVP. However, since there can be only 3003 one expected response computed at the Diameter server, we now 3004 allow a single Digest-Expected-Response. 3005 o A note is added indicating that if Digest-Qop is set to "auth-int" 3006 in the SIP-Authentication-Info AVP, then the Diameter client (SIP 3007 server) is responsible to compute the "rspauth" value in the 3008 Digest Authentication-Info header. 3010 o This version of the draft provides support to identify the type of 3011 user data included in the SIP-User-Data AVP (this can contain a 3012 user profile). The following changes has been made: 3013 o 3014 * Added a new SIP-Supported-User-Data-Type AVP. 3015 * The old SIP-User-Data AVP is now a grouped AVP that contains 3016 two AVPs: SIP-User-Data-Type and SIP-User-Data-Contents. 3017 * Added a new SIP-User-Data-Type AVP. 3018 * Added a new SIP-User-Data-Contents (that contains the profile). 3019 This is equivalent to the old SIP-User-Data AVP. 3020 * All the above AVPs are visible in SAR, SAA, and PPR commands. 3021 * The new SIP-User-Data and SIP-Supported-User-Data-Type allows 3022 repetition (a server could potential send more than one 3023 profile; a client can express support for more than one type of 3024 profile). 3025 o Fixed a typo that defined the SIP-Visited-Network-Id AVP as an 3026 OctetString AVP rather than UTF-8. 3028 15.5 Changes in draft-ietf-aaa-diameter-sip-app-03.txt from -02.txt 3030 o A Diameter Subscriber Locator was either a Diameter Relay or a 3031 Diameter Redirect node. We have removed the Diameter Relay 3032 functionality, since Diameter relays will not relay CER/CEA 3033 messages, thus, a Diameter client will never be able to determine 3034 which Diameter applications are running in a given Diameter 3035 server. So a Diameter Subscriber Locator is implemented as a 3036 Diameter redirect node. 3037 o Section "Registration termination" has been rewritten. Now the 3038 procedures speak about SIP soft state management, rather than SIP 3039 registration, so this procedures are applicable to SIP event 3040 subscriptions as well. A discussion on how to couple Diameter 3041 user sessions with SIP soft states is also added 3042 o Added a new Digest-Expected-Response AVP that allows the Diameter 3043 server to send a pre-calculated expected digest response to the 3044 Diameter client. This is only applicable to the case when the SIP 3045 UA does not use client nonces. 3046 o The Authentication Details Section has been updated with the 3047 latest details of the authentication process. 3049 15.6 Changes in draft-ietf-aaa-diameter-sip-app-02.txt from -01.txt 3051 o We have changed the type of the SIP-Authenticate, SIP- 3052 Authorization, SIP-Authentication-Info AVPs. Now, each is a 3053 grouped AVP and contains one or more AVPs that maps to the 3054 corresponding Digest parameter. This means that the Diameter 3055 server will receive in a different AVP each of the values of the 3056 different parameters contained in the Digest headers. This 3057 approach relieves the Diameter server of implementing a SIP parser 3058 to determine the values of each of the parameters. 3059 o Specifically added support for Digest AKA operation, as per RFC 3060 3310 [RFC3310]. A Digest-AKA-Auts AVP is added. 3061 o List of authors trimmed. Contributors section added. 3062 o The SIP-Entity-Body-Hash is renamed to Digest-Entity-Body-Hash to 3063 be aligned with the rest of the Digest-* AVPs. 3064 o The NAS-Session-Key AVP has been deleted. We never knew why this 3065 AVP was here. 3066 o We have removed the support for key distribution. Specifically we 3067 have removed the Confidentiality-Key and Integrity-Key AVPs. 3069 15.7 Changes in draft-ietf-aaa-diameter-sip-app-01.txt from -00.txt 3071 o The SIP-Authentication-Info AVP was mistakenly typed as 3072 OctetString. We changed it to UTF8String. Since SIP is encoded 3073 in UTF8String, there is no point in having an OctetString AVP 3074 here. 3075 o The SIP-Authentication-Context AVP is changed to be a grouped AVP. 3076 It contains a SIP-Entity-Body-Hash AVP that contains the hash of 3077 the entity body (e.g., the hash of the SDP [RFC2327]). This is 3078 because some authentication mechanisms require to make a hash of 3079 the entity body. Instead of sending the whole entity body to the 3080 Diameter server, it is more efficient to send the hash of the 3081 body. 3082 o Added a descriptive text indicating the intended use/actions of 3083 each command. 3084 o Removed references to PGP since it is deprecated in SIP. 3085 o We have focused on providing support for HTTP Digest 3086 authentication in SIP, since it is the mandatory authentication 3087 mechanism in SIP. Other documents can extend this one adding 3088 support for other authentication mechanisms if that is required in 3089 the future. 3090 o Added a Security Considerations section. 3091 o The scenario "Diameter server authenticates the user" had an 3092 error, because it was assuming that the MAR/MAA commands were used 3093 to download the user profile. However, MAR/MAA do not contain 3094 provisions to download any user profile. The solution is to add a 3095 SAR/SAA commands that allow the SIP server to get the user profile 3096 stored in the Diameter server. 3097 o Added the missing Redirect-Host-Usage and Redirect-Max-Cache-Time 3098 to all the answers. 3100 15.8 Changes in draft-ietf-aaa-diameter-sip-app-00.txt from 3101 draft-belinchon-aaa-diameter-mm-app-01.txt 3103 o Application name changed to Diameter SIP application. 3105 o New Definitions section added. 3106 o New Applicability section added. 3107 o The problem of locating a Diameter server is addressed with the 3108 introduction of a new Diameter Subscriber Locator role. 3109 o Added new scenarios to indicate usage in a more generic Internet 3110 environment. 3111 o A few AVPs have been renamed to accurately reflect the intention 3112 of the AVP. For instance, SIP-Server-Name becomes SIP-Server-URI, 3113 and SIP-Public-User-ID becomes SIP-AOR. 3114 o MAR command can be used more generically. Particularly, it does 3115 not assume a SIP REGISTER message. So we had to add a new SIP- 3116 Method AVP to indicate the SIP method that triggered the MAR 3117 command. 3118 o User-Name is no longer mandatory in requests, as typically a SIP 3119 request will not contain a user name. As a result of this change, 3120 a new transit failure Result-Code AVP value has been added: 3121 DIAMETER_USER_NAME_REQUIRED, to indicate the Diameter client that 3122 the request didn't include a User-Name AVP and it is required to 3123 process it. Typically, SIP servers, upon reception of this 3124 Result-Code AVP value, will generate a SIP 401 (Unauthorized) or 3125 SIP 407 (Proxy Authentication Required) to request the user name 3126 from the user. 3127 o IANA section has been carefully rewritten to give detailed 3128 instructions to IANA on what is required to register. 3130 16. References 3132 16.1 Normative References 3134 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3135 Requirement Levels", BCP 14, RFC 2119, March 1997. 3137 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 3138 Leach, P., Luotonen, A., and L. Stewart, "HTTP 3139 Authentication: Basic and Digest Access Authentication", 3140 RFC 2617, June 1999. 3142 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3143 A., Peterson, J., Sparks, R., Handley, M., and E. 3144 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3145 June 2002. 3147 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 3148 Protocol (HTTP) Digest Authentication Using Authentication 3149 and Key Agreement (AKA)", RFC 3310, September 2002. 3151 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 3152 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3154 [ietf-radext-digest-auth] 3155 Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., 3156 and W. Beck, "RADIUS Extension for Digest Authentication", 3157 December 2004. 3159 16.2 Informational References 3161 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 3162 RFC 2246, January 1999. 3164 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 3165 Protocol", RFC 2327, April 1998. 3167 [I-D.ietf-aaa-diameter-mobileip] 3168 Calhoun, P., Johansson, T., Perkins, C., and T. Hiller, 3169 "Diameter Mobile IPv4 Application", 3170 draft-ietf-aaa-diameter-mobileip-20 (work in progress), 3171 August 2004. 3173 [I-D.ietf-aaa-diameter-nasreq] 3174 Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 3175 "Diameter Network Access Server Application", 3176 draft-ietf-aaa-diameter-nasreq-17 (work in progress), 3177 July 2004. 3179 [I-D.ietf-aaa-diameter-cc] 3180 Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. 3181 Hakala, "Diameter Credit-control Application", 3182 draft-ietf-aaa-diameter-cc-06 (work in progress), 3183 August 2004. 3185 [3GPP.29.229] 3186 3GPP, "Cx and Dx interfaces based on the Diameter 3187 protocol; Protocol details", 3GPP TS 29.229 v6.3.0, 3188 December 2004. 3190 Authors' Addresses 3192 Miguel A. Garcia Martin (editor) 3193 Nokia 3194 P.O. Box 407 3195 NOKIA GROUP, FIN 00045 3196 Finland 3198 Phone: +358 50 480 4586 3199 Email: miguel.an.garcia@nokia.com 3200 Maria-Carmen Belinchon 3201 Ericsson 3202 Via de los Poblados 13 3203 Madrid 28033 3204 Spain 3206 Phone: +34 91 339 3535 3207 Email: maria.carmen.belinchon@ericsson.com 3209 Miguel A. Pallares-Lopez 3210 Ericsson 3211 Via de los Poblados 13 3212 Madrid 28033 3213 Spain 3215 Phone: +34 91 339 4222 3216 Email: miguel-angel.pallares@ericsson.com 3218 Carolina Canales-Valenzuela 3219 Ericsson 3220 Via de los Poblados 13 3221 Madrid 28033 3222 Spain 3224 Phone: +34 91 339 2680 3225 Email: carolina.canales@ericsson.com 3227 Kalle Tammi 3228 Nokia 3229 P.O.Box 785 3230 Tampere 33101 3231 Finland 3233 Phone: +358 40 505 8670 3234 Email: kalle.tammi@nokia.com 3236 Intellectual Property Statement 3238 The IETF takes no position regarding the validity or scope of any 3239 Intellectual Property Rights or other rights that might be claimed to 3240 pertain to the implementation or use of the technology described in 3241 this document or the extent to which any license under such rights 3242 might or might not be available; nor does it represent that it has 3243 made any independent effort to identify any such rights. Information 3244 on the procedures with respect to rights in RFC documents can be 3245 found in BCP 78 and BCP 79. 3247 Copies of IPR disclosures made to the IETF Secretariat and any 3248 assurances of licenses to be made available, or the result of an 3249 attempt made to obtain a general license or permission for the use of 3250 such proprietary rights by implementers or users of this 3251 specification can be obtained from the IETF on-line IPR repository at 3252 http://www.ietf.org/ipr. 3254 The IETF invites any interested party to bring to its attention any 3255 copyrights, patents or patent applications, or other proprietary 3256 rights that may cover technology that may be required to implement 3257 this standard. Please address the information to the IETF at 3258 ietf-ipr@ietf.org. 3260 Disclaimer of Validity 3262 This document and the information contained herein are provided on an 3263 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3264 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3265 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3266 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3267 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3268 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3270 Copyright Statement 3272 Copyright (C) The Internet Society (2005). This document is subject 3273 to the rights, licenses and restrictions contained in BCP 78, and 3274 except as set forth therein, the authors retain all their rights. 3276 Acknowledgment 3278 Funding for the RFC Editor function is currently provided by the 3279 Internet Society.