idnits 2.17.1 draft-johansson-aaa-diameter-mm-app-02.txt: -(1310): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1313): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1316): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1320): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 9 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 157 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 2617' on line 1029 -- No information found for draft-ietf-sipping-aaa- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-15 -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- No information found for draft-ietf-diameter-mobileip - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2806 (ref. '7') (Obsoleted by RFC 3966) ** Obsolete normative reference: RFC 2617 (ref. '8') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) == Outdated reference: A later version (-01) exists of draft-loughney-aaa-cc-3gpp-00 ** Downref: Normative reference to an Informational draft: draft-loughney-aaa-cc-3gpp (ref. '9') Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Maria-Carmen Belinchon 3 INTERNET-DRAFT Miguel-Angel Pallares 4 Category: Standards Track Carolina Canales 5 Expires: May 2003 Ericsson 6 Peter J. McCann 7 Lucent 8 Jaakko Rajaniemi 9 Nokia 11 November, 2002 13 Diameter Multimedia Application 14 16 Status of this memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is an individual submission to the IETF. Comments 37 should be directed to the authors. 39 Abstract 41 This document specifies a Diameter application that allows to perform 42 the authentication, authorization, and collection of accounting 43 information for Session Initiation Protocol (SIP) services rendered 44 to a client node. This application, combined with the base Diameter 45 protocol and appropriate SIP extensions, allows SIP User Agents (UAs) 46 to obtain services from SIP servers that are connected to a Diameter 47 infrastructure. When combined with the Inter-Domain capability of 48 the base protocol, service may even be obtained from SIP servers that 49 belong to foreign domains, as would be encountered by roaming mobile 50 nodes. 52 Note that the specification defined here may be used independently of 53 the authentication technique used for authenticating a node's link 54 layer or network-layer access. In particular, we do not require that 55 the client node was authenticated for access with the use of either 56 the Mobile IP [4] or NASREQ [3] Diameter application. 58 TABLE OF CONTENTS 60 1. Introduction.....................................................3 61 1.1 Requirements language...........................................4 62 2 Description of a SIP network architecture.........................4 63 2.1 User authentication by SSP......................................5 64 2.2 User authentication by AAA server...............................7 65 2.3 Invitation......................................................9 66 2.4 User Profile Updating...........................................9 67 2.5 User registration termination..................................10 68 3 Command Codes...................................................10 69 3.1 User-Authorization-Request (UAR) Command.......................10 70 3.2 User-Authorization-Answer (UAA) Command........................11 71 3.3 Server-Assignment-Request (SAR) Command........................11 72 3.4 Server-Assignment-Answer (SAA) Command.........................12 73 3.5 Location-Info-Request (LIR) Command............................13 74 3.6 Location-Info-Answer (LIA) Command.............................13 75 3.7 Multimedia-Auth-Request (MAR) Command..........................14 76 3.8 Multimedia-Auth-Answer (MAA) Command...........................14 77 3.9 Registration-Termination-Request (RTR) Command.................15 78 3.10 Registration-Termination-Answer (RTA) Command.................15 79 3.11 Push-Profile-Request (PPR) Command............................16 80 3.12 Push-Profile-Answer (PPA) Command.............................16 81 4 Result Code AVP values...........................................17 82 4.1 Success........................................................17 83 4.2 Permanent failures.............................................17 84 5 Diameter AVP values..............................................18 85 5.1 SIP-Server AVP.................................................18 86 5.1.1 SIP-Server-Name AVP..........................................18 87 5.1.2 SIP-Server-Capability AVP....................................18 88 5.1.2.1 Mandatory-Capability AVP...................................18 89 5.1.2.2 Optional -Capability AVP...................................19 90 5.2 SIP-Public-Identity AVP........................................19 91 5.3 SIP-Visited-Network-Identifier AVP.............................19 92 5.4 SIP-Server-Assignment-Type AVP.................................19 93 5.5 SIP-Auth-Data-Item AVP.........................................20 94 5.5.1 SIP-Item-Number AVP..........................................21 95 5.5.2 SIP-Authentication-Scheme AVP................................21 96 5.5.3 SIP-Authenticate AVP.........................................21 97 5.5.4 SIP-Authorization AVP........................................21 98 5.5.5 SIP-Authentication-Info AVP..................................21 99 5.5.6 SIP-Authentication-Context AVP...............................21 100 5.6 SIP-Number-Auth-Items AVP......................................22 101 5.7 SIP-User-Data AVP..............................................22 102 5.8 NAS-Session-Key AVP............................................22 103 5.9 NAS-Key-Binding AVP............................................22 104 5.10 SIP-Deregistration-Reason AVP.................................22 105 5.10.1 Reason-Code AVP.............................................22 106 5.10.2 Reason-Info AVP.............................................23 107 5.11 Charging-Information AVP......................................23 108 5.11.1 Primary-Event-Charging-Function-Name AVP....................23 109 5.11.2 Secondary -Event-Charging-Function-Name AVP.................23 110 5.11.3 Primary-Charging-Collection-Function-Name AVP...............23 111 5.11.4 Secondary -Charging-Collection-Function-Name AVP............23 112 5.12 User-Authorization-Type AVP...................................23 113 5.13 User-Data-Request-Type AVP....................................24 114 5.14 User-Data-Already-Available AVP...............................24 115 6. Authentication Details..........................................25 116 7. IANA Considerations.............................................25 117 8 References.......................................................25 118 9 Authors' Addresses...............................................26 119 10. Full Copyright Statement.......................................27 121 1. Introduction 123 This document specifies a Diameter application that allows to perform 124 the authentication, authorization and collection of accounting 125 information for SIP-based IP multimedia services rendered to a client 126 node. We assume that a client node implements a SIP User Agent (UA) 127 that carries out SIP protocol actions with a SIP server, which in 128 turn relies on the AAA infrastructure for authenticating the client, 129 authorizing it for particular SIP services, and accounting for this 130 usage. 132 SIP servers can be proxy, redirect, registration, or user agent 133 servers. Additionally, SIP servers may be arranged in arbitrary ways 134 according to the inter-service provider relationships involved in 135 servicing a given client. For example, a mobile node may use a SIP 136 proxy in the visited network, but its SIP messages may be proxied 137 back to a SIP server in the home network that implements call control 138 features. Combined with the Inter-Domain capability of the base 139 protocol, this extension would allow such mobile terminals to receive 140 service from foreign service providers according to their location 141 and subscription profile. Any or all of the SIP servers may need to 142 independently authenticate the client, authorize service, and account 143 for usage. 145 Authentication must take place at the time the user agent registers 146 with the SIP server (or chain of SIP proxies and servers) or at any 147 other moment agreed by the entities involved in the authentication 148 (e.g., at SIP session initiation). The particular algorithm used to 149 authenticate a SIP user agent client is a matter of policy agreement 150 between the user agent client, the SIP server, and the home AAA 151 server. This document supports the WWW-Authenticate methods Basic 152 and Digest, which are supported by SIP. In addition to 153 authenticating the user agent client, such a method could also be 154 used to generate or distribute keys for subsequent SIP-layer message 155 integrity and privacy. The specification of such an algorithm, and 156 its embedding in SIP, is outside the scope of this document. 158 Authorization for SIP services may take many forms. For example, a 159 proxy may need to know that the user agent client is authorized to 160 register, but from then on it may simply pass messages through to 161 other SIP servers. However, a SIP server that implements call 162 control features may need a richer and more complete description of 163 the services to which the user has subscribed. 165 Accounting for SIP services is on a per-call basis. An accounting 166 record contains a SIP Call-ID, any SDP that was exchanged to set up 167 the call, the duration of the call, and any resources that were 168 consumed on behalf of the call (such as number of bytes exchanged 169 between the parties). Note that accounting for resources may require 170 the SIP server to interact with other network entities, such as media 171 gateways, for the collection of this information. Such interaction 172 is outside the scope of this document. Some example scenarios, 173 inspired by the emerging wireless applications of SIP, are given in 174 Section 2. Sections 3, 4 and 5 address the Diameter Multimedia 175 Application's specific commands, result codes, and AVPs, 176 respectively. Section 7 gives IANA considerations. 178 1.1 Requirements language 180 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 181 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 182 described in [10]. 184 2 Description of a SIP network architecture 186 Home Realm 187 +-------+ 188 UAR/UAA +-->| AAA |<--+ PPR/PPA 189 LIR/LIA | |xyz.com| | MAR/MAA 190 | | | | SAR/SAA 191 | +-------+ | RTR/RTA 192 Local Realm v v 193 +-------+ +-------+ +-------+ 194 | OSP |<----------->| HSP |<----->| SSP | 195 |abc.com| SIP |xyz.com| SIP |xyz.com| 196 +-------+ +-------+ +-------+ 197 ^ ^ 198 | SIP | 199 v | 200 +-------+ SIP | 201 | UAE |<----------------+ 202 +-------+ 203 bob@xyz.com 204 Figure 1: SIP network infrastructure 206 Figure 1 above illustrates the nodes involved in a SIP multimedia 207 network architecture, according to the requirements in [1]. The home 208 realm (xyz.com) is comprised of a Diameter AAA server, at least one 209 home entry SIP proxy (HSP) which is the gateway SIP proxy seen by the 210 rest of the world, and any number of serving SIP proxy (SSP) nodes. 211 These SSP nodes may be deployed piecemeal for various reasons such as 212 but not limited to load balancing, scalability, and offering 213 distinct, separate services. 215 The mobile node in this scenario (bob@xyz.com) may either connect 216 directly to its HSP, or via an outbound SIP server (OSP) in the local 217 realm. In larger networks, registrations MAY be routed to different 218 HSPs, potentially even for a subsequent SIP registration for the same 219 user, and thus HSPs are usually stateless. 221 The next few sections will describe in detail the different modes of 222 operation that are available to such an infrastructure. These 223 options may be either administratively configured to suit local 224 policies, or determined dynamically by the network. For the purposes 225 of authentication and authorization, the procedures involved when 226 using a OSP are a superset of the procedures involved in the absence 227 of a OSP, and therefore we will skip a needless explanation of the 228 latter scenario. 230 2.1 User authentication by SSP 232 An operator with a large base of installed SIP servers may wish to 233 minimize the impact of modifying SIP servers to interact with 234 Diameter AAA servers. This can be achieved by allowing SIP servers 235 to retain the functionality of authentication, rather than exporting 236 this capability to the AAA server. However, it should be noted that 237 this mode will not leverage the extensive array of authentication and 238 authorization services which will already be present regardless in 239 diameter servers. Below follows an example of a SIP user 240 registration using the SSP authentication mode. 242 +-------+ +-------+ +-------+ 243 | HSP | | AAA | | SSP | 244 +---+---+ +---+---+ +---+---+ 245 | | | 246 1. SIP-REG | | | 247 ---------->| 2. UAR | | 248 +------------------>| | 249 | 3. UAA | | 250 |<------------------+ | 251 | 4. SIP-REG | | 252 +-------------------------------------->| 253 | | 5. MAR | 254 | |<------------------+ 255 | | 6. MAA | 256 | +------------------>| 257 | 7. 401 (Unauthorized) | 258 8. 401 |<--------------------------------------+ 259 <-----------+ | | 260 9. SIP-REG | | | 261 ---------->| 10. UAR | | 262 +------------------>| | 263 | 11. UAA | | 264 |<------------------+ | 265 | | 12. SIP-REG | 266 +-------------------------------------->| 267 | | 13. SAR | 268 | |<------------------+ 269 | | 14. SAA | 270 | +------------------>| 271 | 15. 200 (OK) | | 272 16. 200 |<--------------------------------------+ 273 <-----------+ | | 274 | | | 275 Figure 2: Authentication performed by the SSP 277 In this scenario, a user sends a SIP registration to the home domain. 278 The HSP will contact its local diameter server with a "User- 279 Authorization-Request" (UAR) to authorize if this user is allowed to 280 receive service, and if so, request the identity of a local SIP 281 server capable of handling this user. The diameter server will 282 respond with a "User-Authorization-Answer" (UAA), which will inform 283 about the result of the user authorization request in the Result-Code 284 AVP. The result values are defined in section 4 in addition to the 285 values defined in [2]. When the authorization successes, the UAA will 286 indicate either the identity of a local SIP server or a list of 287 capabilities from which the HSP will select the SSP. 289 If the result falls into the success category, then the HSP will 290 forward the registration request to the appropriate SSP. The SSP will 291 then request authentication parameters from the diameter server 292 through a "Multimedia-Auth-Request" (MAR). This request MAY also 293 serve to identify the SSP, so as to return subsequent registration 294 requests of the same user to the same SSP. The diameter server will 295 respond with a "Multimedia-Auth-Answer" (MAA), which will include all 296 parameters necessary for the designated authentication algorithm 297 associated with the user. The SSP will then create the 401 298 (Unauthorized) message, including the authentication material needed 299 by the mobile user to prove his/her identity. 301 When the subsequent SIP registration is received from the user, the 302 HSP (assumed to be stateless) will once again contact the diameter 303 server with a UAR to determine to which SSP to forward the 304 registration. The HSP will then forward the SIP registration to the 305 SSP node. The SSP node performed the authentication in the previous 306 registration request by means of MAR/MAA, so at this point it is not 307 necessary to ask for it again, instead, it will contact the AAA 308 server by means of a Server-Assignment-Request (SAR) requesting it to 309 store the name of the server that is currently serving the user. 311 The AAA server will respond with a "Server-Assignment-Answer" (SAA). 312 If the Result-Code does not inform about an error, the User-Data AVP 313 shall contain the information that the SSP needs to give service to 314 the user. 316 The SSP will produce then a 200 (OK) message, and send it to the HSP. 317 The HSP will then forward the 200 (OK) message towards the mobile 318 user. 320 2.2 User authentication by AAA server 322 A different approach in deploying SIP networks is to allow the 323 Diameter server to perform the actual authentication. In addition to 324 leveraging the robust authentication services offered by the AAA 325 server, it will reduce the number of messages sent in the network. 327 +-------+ +-------+ +-------+ 328 | HSP | | AAA | | SSP | 329 +---+---+ +---+---+ +---+---+ 330 | | | 331 1. SIP-REG | | | 332 ---------->| 2. UAR | | 333 +------------------>| | 334 | 3. UAA | | 335 |<------------------+ | 336 | | 4. SIP-REG | 337 +-------------------------------------->| 338 | | 5. MAR | 339 | |<------------------+ 340 | | 6. MAA | 341 | +------------------>| 342 | 7. 401 (Unauthorized) | 343 8. 401 |<--------------------------------------+ 344 <-----------+ | | 345 9. SIP-REG | | | 346 ---------->| 10. UAR | | 347 +------------------>| | 348 | 11. UAA | | 349 |<------------------+ | 350 | | 12. SIP-REG | 351 +-------------------------------------->| 352 | | 13. MAR | 353 | |<------------------+ 354 | | 14. MAA | 355 | +------------------>| 356 | 15. 200 (OK) | | 357 16. 200 |<--------------------------------------+ 358 <-----------+ | | 359 | | | 360 Figure 3: Authentication performed by the AAA server 362 In this scenario, the user will send a SIP register message to it's 363 home domain. When the HSP receives this request, it will contact its 364 local diameter server with a "User-Authorization-Request" (UAR) to 365 determine if this user is allowed to receive service and if so, 366 request the identity of a local SIP server capable of handling this 367 user, as described in the previous section. The diameter server will 368 respond with a "User-Authorization-Answer" (UAA), which will indicate 369 a list of capabilities from which the HSP will use to select the SSP. 371 Once it forwards the initial SIP registration to the appropriate SSP, 372 the SSP will then request user authentication from the Diameter 373 server through a "Multimedia-Auth-Request" (MAR). This request MAY 374 also serve to identify the SSP, so as to return subsequent 375 registration requests to the same SSP. The Diameter server will then 376 respond with a "Multimedia-Auth-Answer" (MAA) with Result-Code equal 377 to DIAMETER_MULTI_ROUND_AUTH and the challenge information, which the 378 SSP will use to map into the WWW-authentication header in the SIP 401 379 unauthorized and send back to the HSP. 381 When the subsequent SIP registration is received from the user, the 382 HSP will once again contact the diameter server with a UAR to 383 determine to which SSP to forward the registration. The HSP will then 384 forward the SIP registration to the SSP node, which will then extract 385 the relevant authentication parameters, and include these in a MAR 386 message to the AAA server. This request MAY also serve to identify 387 the SSP, so as to return subsequent registration requests to the same 388 SSP. At this point, the Diameter server will be able to authenticate 389 the user, and upon success, will return a MAA with Result-Code equal 390 to DIAMETER_SUCCESS and include user profile information, which the 391 SSP will use to give service to the user, the SSP will then produce a 392 200 (OK) message and send it to the HSP, which will then forward it 393 to the mobile user. 395 2.3 Invitation 397 When a registered user wishes to invite another registered user, it 398 will send a SIP Invite request to the home domain (HSP) of the 399 invitee. 401 +-------+ +-------+ +-------+ 402 | HSP | | AAA | | SSP | 403 +---+---+ +---+---+ +---+---+ 404 | | | 405 1. SIP-INV | | | 406 ---------->| 2. LIR | | 407 +------------------>| | 408 | 3. LIA | | 409 |<------------------+ | 410 | | 4. SIP-INV | 411 +-------------------------------------->| 412 | | | 414 Figure 5. A SIP Invite request 416 In this scenario, when a user, say Bob, contacts the HSP to invite 417 another user, say Mary, the Mary�s HSP will issue a diameter 418 "Location-Info- Request" (LIR) message to the AAA server to request 419 the identity of the SSP currently assigned to Mary. The AAA server 420 will respond with a diameter "Location-Info-Answer" (LIA), indicating 421 the appropriate SSP, and the HSP will forward the SIP Invite message 422 directly to the named SSP. 424 2.4 User Profile Updating 426 Whenever a modification in the user profile has occurred, the AAA 427 server and SSP must synchronize their user profile data. 429 +-------+ +-------+ 430 | AAA | | SSP | 431 +---+---+ +---+---+ 432 | | 433 | 1. PPR | 434 +------------------>| 435 | | 436 | 2. PPA | 437 |<------------------+ 438 | | 439 Figure 6. User profile update initiated by AAA server 441 The AAA server sends a Push-Profile-Request (PPR) to the serving SIP 442 server to which the user is registered. The PPR message contains a 443 SIP-User-Data AVP, a SIP-User-Name AVP, and zero or more SIP-Public- 444 Identity AVPs. The presence of the SIP-User-Name AVP without any 445 SIP- Public-Identity AVPs serves to indicate that the entire user 446 profile associated with the SIP-User-Name AVP should be updated. A 447 PPR with a SIP-User-Name AVP and one or more SIP-Public-Identity AVPs 448 serves to indicate that the user profile data associated with each of 449 the SIP- Public-Identity AVPs should be updated. 451 2.5 User registration termination 453 Termination of an entire user registration can be achieved by one of 454 two mechanisms. In the event that NO_STATE_MAINTAINED (i.e NO 455 Diameter user session-id is maintained) has been indicated in a prior 456 Auth-Session-State AVP, termination is handled with a Session- 457 Termination-Request (if it is initiated by the SSP/HSP) or with a 458 Registration-Termination-Request (if it is initiated by the AAA). 460 On the other hand, if STATE_MAINTAINED has been indicated in a prior 461 Auth-Session-State AVP, the use of Session-Termination-Request (STR) 462 and Abort-Session-Request (ASR) messages as defined in the base 463 protocol are used to terminate an entire user registration. 465 Reasons for terminating a user registration could be due to the 466 expiration of the SIP registration timer in the SIP server, a user 467 initiated SIP de-registration, or a AAA-initiated de-registration as 468 a result of administrative reasons. 470 3 Command Codes 472 This section will define the specific message formats used by this 473 diameter application. 475 3.1 User-Authorization-Request (UAR) Command 477 The User-Authorization-Request (UAR), indicated by the Command-Code 478 field set to TBD and the 'R' bit set in the Command Flags field, is 479 sent by an HSP node, acting as a Diameter client, to a AAA server in 480 order to request authorization of a mobile user. 482 Message Format 483 < User-Authorization-Request > ::= Diameter Header: TBD: REQ, PXY > 484 < Session-ID > 485 < Auth-Application-Id > 486 { Auth-Session-State } 487 { Origin-Host } 488 { Origin-Realm } 489 [ Destination-Host ] 490 { Destination-Realm } 491 { SIP-User-Name } 492 { SIP-Public-Identity } 493 { Visited-Network-Identifier } 494 [ User-Authorization-Type ] 495 * [ AVP ] 496 * [ Proxy-Info ] 497 * [ Route-Record ] 499 3.2 User-Authorization-Answer (UAA) Command 501 The User-Authorization-Answer (UAA), indicated by the Command-Code 502 field set to TBD and the 'R' bit cleared in the Command Flags field, 503 is sent by a AAA server in response to the User-Authorization-Request 504 command. The Result-Code AVP may contain one of the values defined in 505 section 4 in addition to the values defined in [2]. 507 If the user has not previously been authorized, the UAA will make use 508 of the Server-Capabilities AVP to convey information needed by the 509 HSP to select an appropriate SSP. 511 If the user has already been authorized and a server has already been 512 assigned which is still valid for the user's service profile, the 513 SIP-Server-Name AVP MUST be present which contains the SIP URL of the 514 currently assigned server, so that the HSP can forward the 515 registration request to it. 517 If the user has already been authorized, and a server has already 518 been assigned which may not be valid for the user's service profile, 519 two pieces of information must be returned to allow the HSP to decide 520 what action to take. First, the Server-Name AVP MUST be present 521 which contains the SIP URL of the currently assigned server. Second, 522 the Server-Capabilities AVP MUST present which contains information 523 to allow the HSP to select an appropriate SIP server. 525 Message Format 526 < User-Authorization-Answer > ::= < Diameter Header: TBD: PXY > 527 < Session-Id > 528 { Auth-Application-Id } 529 { Auth-Session-State } 530 [ Result-Code ] 531 { Origin-Host } 532 { Origin-Realm } 533 [ SIP-Server] 534 [ Authorization-Lifetime ] 535 [ Auth-Grace-Period ] 536 *[ AVP ] 537 *[ Proxy-Info ] 538 *[ Route-Record ] 540 3.3 Server-Assignment-Request (SAR) Command 541 The Server-Assignment-Request (SAR) command, indicated by the 542 Command-Code field set to TBD and the 'R' bit set in the Command 543 Flags field, is sent by a Diameter Multimedia client to a Diameter 544 Multimedia server in order to request it to store the name of the 545 server that is currently serving the user. 547 Message Format 548 ::= < Diameter Header: TBD, REQ, PXY> 549 < Session-Id > 550 { Auth-Application-Id } 551 { Auth-Session-State } 552 { Origin-Host } 553 { Origin-Realm } 554 [ Destination-Host ] 555 { Destination-Realm } 556 [ SIP-User-Name ] 557 *[ SIP-Public-Identity ] 558 [ SIP-Server ] 559 { SIP-Server-Assignment-Type } 560 { User-Data-Request-Type } 561 { User-Data-Already-Available } 562 *[ AVP ] 563 *[ Proxy-Info ] 564 *[ Route-Record ] 566 3.4 Server-Assignment-Answer (SAA) Command 568 The Server-Assignment-Answer (SAA) command, indicated by the Command- 569 Code field set to TBD and the 'R' bit cleared in the Command Flags 570 field, is sent by a server in response to the Server-Assignment- 571 Request command. The Result-Code AVP may contain one of the values 572 defined in section 4 in addition to the values defined in [2]. If 573 Result-Code does not inform about an error, the User-Data AVP shall 574 contain the information that the S-CSCF needs to give service to the 575 user. 577 Message Format 578 ::= < Diameter Header: TBD: PXY > 579 < Session-Id > 580 { Auth-Application-Id } 581 [ Result-Code ] 582 { Auth-Session-State } 583 { Origin-Host } 584 { Origin-Realm } 585 [ SIP-User-Data ] 586 [ Charging-Information ] 587 [ Auth-Grace-Period ] 588 [ Authorization-Lifetime ] 589 *[ AVP ] 590 *[ Proxy-Info ] 591 *[ Route-Record ] 593 3.5 Location-Info-Request (LIR) Command 595 The Location-Info-Request (LIR), indicated by the Command-Code field 596 set to TBD and the 'R' bit set in the Command Flags field, is sent by 597 a HSP node, acting as a Diameter client, to a Diameter server in 598 order to request the identity of SIP server currently associated with 599 a particular user. 601 Message Format 602 < Location-Info-Request > ::= < Diameter Header: TBD, REQ, PXY > 603 < Session-Id > 604 { Auth-Application-Id } 605 { Auth-Session-State } 606 { Origin-Host } 607 { Origin-Realm } 608 [ Destination-Host ] 609 { Destination-Realm } 610 { SIP-Public-Identity } 611 *[ AVP ] 612 *[ Proxy-Info ] 613 *[ Route-Record ] 615 3.6 Location-Info-Answer (LIA) Command 617 The Location-Info-Answer (LIA), indicated by the Command-Code field 618 set to TBD and the 'R' bit cleared in the Command Flags field, is 619 sent by a Diameter server in response to a Location-Info-Request. If 620 the user in the request is currently registered in the AAA server, 621 the answer will include the identity of the SIP server currently 622 associated with the user. The Result-Code AVP may contain one of the 623 values defined in section 4 in addition to the values defined in [2]. 625 Message Format 626 < Location-Info-Answer > ::= < Diameter Header: TBD: PXY > 627 < Session-Id > 628 { Auth-Application-Id } 629 [ Result-Code ] 630 { Auth-Session-State } 631 { Origin-Host } 632 { Origin-Realm } 633 [ SIP-Server ] 634 [ Auth-Grace-Period ] 635 [ Authorization-Lifetime ] 636 *[ AVP ] 637 *[ Proxy-Info ] 638 *[ Route-Record ] 640 3.7 Multimedia-Auth-Request (MAR) Command 642 The Multimedia-Auth-Request (MAR), indicated by the Command-Code 643 field set to TBD and the 'R' bit set in the Command Flags field, is 644 sent by an SSP node, acting as a Diameter client, to a server in 645 order to request the authentication of a mobile user. The Diameter 646 client uses information found in the SIP Request to construct the 647 AVPs that are to be included as part of the MAR. 649 Message Format 650 < Multimedia-Auth-Request > ::= < Diameter Header: TBD, REQ, PXY > 651 < Session-ID > 652 { Auth-Application-Id } 653 { Auth-Session-State } 654 { Origin-Host } 655 { Origin-Realm } 656 { Destination-Realm } 657 [ Destination-Host ] 658 { SIP-User-Name } 659 [ SIP-Public-Identity }] 660 [ SIP-Auth-Data-Item ] 661 [ SIP-Number-Auth-Items ] 662 [ SIP-Server ] 663 * [ AVP ] 664 * [ Proxy-Info ] 665 * [ Route-Record ] 667 3.8 Multimedia-Auth-Answer (MAA) Command 669 The Multimedia-Auth-Answer (MAA), indicated by the Command-Code field 670 set to TBD and the 'R' bit cleared in the Command Flags field, is 671 sent by the server in response to the Multimedia-Auth-Request 672 command. The Result-Code AVP may contain one of the values defined in 673 section 4 in addition to the values defined in [2]. 675 Message Format 676 < Multimedia-Auth-Answer > ::= < Diameter Header: TBD, PXY > 677 < Session-Id > 678 { Auth-Application-Id } 679 [ Result-Code ] 680 { Auth-Session-State } 681 { Origin-Host } 682 { Origin-Realm } 683 [ SIP-User-Name ] 684 [ SIP-Public-Identity ] 685 [ SIP-Number-Auth-Items ] 686 * [ SIP-Auth-Data-Item ] 687 [ SIP-User-Data ] 689 [ Authorization-Lifetime ] 690 [ Auth-Grace-Period ] 691 * [ AVP ] 692 * [ Proxy-Info ] 693 * [ Route-Record ] 695 3.9 Registration-Termination-Request (RTR) Command 697 The Registration-Termination-Request (RTR) command, indicated by the 698 Command-Code field set to TBD and the 'R' bit set in the Command 699 Flags field, is sent by a Diameter Multimedia server to a Diameter 700 Multimedia client in order to request the de-registration of a user. 701 Message Format 703 ::= < Diameter Header: TBD, REQ, 704 PXY > 705 < Session-Id > 706 { Auth-Application-Id } 707 { Auth-Session-State } 708 { Origin-Host } 709 { Origin-Realm } 710 { Destination-Host } 711 { Destination-Realm } 712 { SIP-User-Name } 713 *[ SIP-Public-Identity ] 714 { DeRegistration-Reason } 715 *[ AVP ] 716 *[ Proxy-Info ] 717 *[ Route-Record ] 719 3.10 Registration-Termination-Answer (RTA) Command 721 The Registration-Termination-Answer (RTA) command, indicated by the 722 Command-Code field set to TBD and the 'R' bit cleared in the Command 723 Flags field, is sent by a client in response to the Registration- 724 Termination-Request command. The Result-Code AVP may contain one of 725 the values defined in section 4 in addition to the values defined in 726 [2]. 728 Message Format 729 ::= < Diameter Header: TBD, PXY > 730 < Session-Id > 731 { Auth-Application-Id } 732 [ Result-Code ] 733 { Auth-Session-State } 734 { Origin-Host } 735 { Origin-Realm } 736 [ Auth-Grace-Period ] 737 [ Authorization-Lifetime ] 738 *[ AVP ] 739 *[ Proxy-Info ] 740 *[ Route-Record ] 742 3.11 Push-Profile-Request (PPR) Command 744 The Push-Profile-Request (PPR) command, indicated by the Command-Code 745 field set to TBD and the 'R' bit set in the Command Flags field, is 746 sent by a Diameter Multimedia server to a Diameter Multimedia client 747 in order to update the subscription data of a multimedia user in the 748 Diameter Multimedia client whenever a modification has occurred in 749 the subscription data that constitutes the data used by the client. 751 Message Format 752 < Push-Profile-Request > ::= < Diameter Header: TBD, REQ, PXY > 753 < Session-Id > 754 { Auth-Application-Id } 755 { Auth-Session-State } 756 { Origin-Host } 757 { Origin-Realm } 758 { Destination-Host } 759 { Destination-Realm } 760 { SIP-User-Name } 761 { SIP-User-Data } 762 *[ SIP-Public-Identity ] 763 [ Authorization-Lifetime ] 764 [ Auth-Grace-Period ] 765 *[ AVP ] 766 *[ Proxy-Info ] 767 *[ Route-Record ] 769 3.12 Push-Profile-Answer (PPA) Command 771 The Push-Profile-Answer (PPA) command, indicated by the Command-Code 772 field set to TBD and the 'R' bit cleared in the Command Flags field, 773 is sent by a client in response to the Push-Profile-Request command. 774 The Result-Code AVP may contain one of the values defined in section 775 4 in addition to the values defined in [2]. 777 Message Format 778 < Push-Profile-Answer > ::=< Diameter Header: 10415: 305 > 779 < Session-Id > 780 { Auth-Application-Id } 781 [Result-Code ] 782 { Auth-Session-State } 783 { Origin-Host } 784 { Origin-Realm } 785 *[ AVP ] 786 *[ Proxy-Info ] 787 *[ Route-Record ] 789 4 Result Code AVP values 791 This section defines new Result codes in addition to the values 792 defined in [2]. 794 4.1 Success 796 Errors that fall within the Success category are used to inform a 797 peer that a request has been successfully completed. 799 DIAMETER_FIRST_REGISTRATION 2xxx 800 The user was not previously registered, and has now been authorized 801 by the AAA server. Information necessary to select an appropriate 802 SSP SHOULD be included in the message. 804 DIAMETER_SUBSEQUENT_REGISTRATION 2xxx 805 The user has been previously registered, and has now been re- 806 authorized by the AAA server. The identity of the SSP to which the 807 user is currently registered SHOULD be included in the message. 809 DIAMETER_SEPARATE_REGISTRATION 2xxx 810 The user has been previously registered, but with a different public 811 identifier (and associated service profile). The identity of the SSP 812 to which the user is currently registered MUST be included in the 813 message, and in the event a new SSP must be assigned (based on the 814 new service profile), information necessary to select an appropriate 815 SSP MUST be included in the message as well. 817 DIAMETER_UNREGISTERED_SERVICE 2xxx 818 The user is not currently registered, but the requested service can 819 still be granted to the user. 821 4.2 Permanent failures 823 Errors that fall within the permanent failures category are used to 824 inform the peer that the request failed, and should not be attempted 825 again. 827 DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5xxx 828 This error code is used to indicate that there is no multimedia 829 roaming agreement between the home and visited networks. 831 DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5xxx 832 The identity being registered has already a server assigned and the 833 registration status does not allow that it is overwritten. 835 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED 5xxx 836 This error code is used to inform that the received public identity 837 has not been registered before and the user to which this identity 838 belongs cannot be given service in this situation. 840 DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5xxx 841 The value in one of the Public-Identity AVPs does not correspond to 842 the user specified in the SIP-User-Name AVP. 844 5 Diameter AVP values 846 The following sections define the AVPs used in this diameter 847 application. 849 5.1 SIP-Server AVP 851 The SIP-Server AVP (AVP code TBD) is of type Grouped. This AVP MAY be 852 used by the HSP to assist in the selection of a SSP. 854 SIP-Server ::= < AVP Header: TBD > 855 { SIP-Server-Name } 856 * [ SIP-Server-Capability ] 857 * [ AVP ] 859 5.1.1 SIP-Server-Name AVP 861 The SIP-Server-Name AVP (AVP Code TBD) is of type UTF8String. This 862 AVP contains a SIP-URL (as defined in [5] and [6]) used to identify a 863 SIP server. 865 The HSP MAY include the SIP-Server-Name AVP to inform the Diameter 866 server which SSP to use for the SIP user or the SIP-Server-Name AVP 867 MAY be used by the Diameter server to inform the HSP that the SIP UA 868 client is assigned at the following SSP server. 870 5.1.2 SIP-Server-Capability AVP 872 The SIP-Capability AVP (AVP Code TBD) is of type Grouped. This AVP 873 is used to indicate support for particular SIP capability, and 874 contains the information to assist the HSP in the selection of an 875 SSP. 877 SIP-Capability ::= < AVP Header: TBD > 878 *[ Mandatory-Capability ] 879 *[ Optional-Capability ] 880 *[ AVP ] 882 5.1.2.1 Mandatory-Capability AVP 883 The Mandatory-Capability AVP (AVP Code TBD) is of type Unsigned32. 884 The value included in this AVP can be used to represent a single 885 determined mandatory capability of an SSP. Each mandatory capability 886 available in an individual operator�s network shall be allocated a 887 unique value. The allocation of these values to individual 888 capabilities is an operator issue. 890 5.1.2.2 Optional -Capability AVP 892 The Optional-Capability AVP (AVP Code TBD) is of type Unsigned32. The 893 value included in this AVP can be used to represent a single 894 determined optional capability of an SSP. Each optional capability 895 available in an individual operator�s network shall be allocated a 896 unique value. The allocation of these values to individual 897 capabilities is an operator issue. 899 5.2 SIP-Public-Identity AVP 901 The SIP-Public-Identity AVP (AVP Code TBD) is of type OctetString, 902 encoded in the UTF-8 format. The syntax of this AVP corresponds 903 either to a SIP URL (with the format defined in [5] and [6]) or a TEL 904 URL (with the format defined in [7]). 906 This AVP contains the SIP public identity of a user in the IMS. 908 The Diameter client (HSP or SSP) uses information found in the header 909 of the SIP messages (e.g. To: field in REGISTER messages or From: 910 field in INVITE messages) to construct the SIP-Public-Identity AVP. 912 5.3 SIP-Visited-Network-Identifier AVP 914 The SIP-Visited-Network-Identifier AVP (AVP Code TBD) is of type 915 OctetString. This AVP contains an identifier that helps the home 916 network to identify the visited network (e.g. the visited network 917 domain name). 919 5.4 SIP-Server-Assignment-Type AVP 921 The Server-Assignment-Type AVP (AVP code TBD) is of type Enumerated, 922 and indicates the type of server update being performed in a Server- 923 Assignment-Request operation. The following values are defined: 925 NO_ASSIGNMENT (0) 926 This value is used to request from AAA the user profile assigned to 927 one or more public identities, without affecting the registration 928 state of those identities. 930 REGISTRATION (1) 931 The request is generated as a consequence of a first registration of 932 an identity. 934 RE_REGISTRATION (2) 935 The request corresponds to the re-registration of an identity. 937 UNREGISTERED_USER (3) 938 The request is generated because the SSP received an INVITE for a 939 public identity that is not registered. 941 TIMEOUT_DEREGISTRATION (4) 942 The SIP registration timer of an identity has expired. 944 USER_DEREGISTRATION (5) 945 The SSP has received a user initiated de-registration request. 947 TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6) 948 The SIP registration timer of an identity has expired. The S-CSCF 949 keeps the user data stored in the SSP and requests AAA to store the 950 SSP name. 952 USER_DEREGISTRATION_STORE_SERVER_NAME (7) 953 The SSP has received a user initiated de-registration request. The 954 SSP keeps the user data stored in the SSP and requests AAA to store 955 the SSP name. 957 ADMINISTRATIVE_DEREGISTRATION (8) 958 The SSP, due to administrative reasons, has performed the de- 959 registration of an identity. 961 AUTHENTICATION_FAILURE (9) 962 The authentication of a user has failed. 964 AUTHENTICATION_TIMEOUT (10) 965 The authentication timeout has expired. 967 5.5 SIP-Auth-Data-Item AVP 969 The SIP-Auth-Data-Item (AVP code TDB) is of type Grouped, and 970 contains the authentication and/or authorization information for the 971 Diameter client. 973 SIP-Auth-Data-Item :: = < AVP Header : TBD > 974 [ SIP-Item-Number ] 975 [ SIP-Authentication-Scheme ] 976 [ SIP-Authenticate ] 977 [ SIP-Authorization ] 978 [ SIP-Authentication-Info ] 979 [ SIP-Authentication-Context ] 980 * [ NAS-Session-Key ] 981 * [ AVP ] 983 5.5.1 SIP-Item-Number AVP 985 The SIP-Item-Number (AVP code TDB) is of type Unsigned32, and is 986 included in a SIP-Auth-Data-Item grouped AVP in circumstances where 987 there are multiple occurrences of SIP-Auth-Data-Item AVPs, and the 988 order in which they should be processed is significant. In this 989 scenario, SIP-Auth-Data-Item AVPs with a low SIP-Item-Number value 990 (such as 1) should be processed before SIP-Auth-Data-Items AVPs with 991 a high SIP-Item-Number value (such as 13). 993 5.5.2 SIP-Authentication-Scheme AVP 995 The SIP-Authentication-Scheme AVP (AVP code TBD) is of type 996 UTF8String and indicates the authentication scheme used in the 997 authentication of SIP messages. Current values are "Basic" and 998 "Digest", defined in [8]. 1000 5.5.3 SIP-Authenticate AVP 1002 The SIP-Authenticate AVP (AVP code TBD) is of type UTF8String and 1003 contains the data portion of the WWW-Authenticate or Proxy- 1004 Authenticate SIP headers if present in a SIP response. 1006 5.5.4 SIP-Authorization AVP 1008 The SIP-Authorization AVP (AVP code TBD) is of type UTF8String and 1009 contains the data portion of the Authorization or Proxy-Authorization 1010 SIP headers if present in a SIP request. 1012 5.5.5 SIP-Authentication-Info AVP 1014 The SIP-Authentication-Info AVP (AVP Code TBD) is of type OctetString 1015 and contains additional authentication information sent by the AAA 1016 server in case of Digest authentication. It follows the format 1017 defined in RFC2617 for the Authentication-Info Header (sect 3.2.3). 1018 The content of this AVP is to be mapped to the SIP Authentication- 1019 Info header upon reception by the SIP server. 1021 5.5.6 SIP-Authentication-Context AVP 1023 The SIP-Authentication-Context AVP (AVP code TBD) is of type 1024 OctectString, and contains authentication-related information 1025 relevant for performing the authentication but that is not part of 1026 the SIP authentication headers. 1028 Some mechanisms (e.g. PGP, digest with quality of protection set to 1029 auth-int [RFC 2617], digest with predictive nonces [7] or sip access 1030 digest [8]) request that part or the whole SIP request is passed to 1031 the entity performing the authentication. In such cases the SIP- 1032 Authentication-Context AVP would be carrying such information. 1034 5.6 SIP-Number-Auth-Items AVP 1036 The SIP-Number-Auth-Items AVP (AVP Code TBD) is of type Unsigned32 1037 and indicates the number of authentication and/or authorization 1038 vectors provided by the Diameter server. 1040 When used in a request, it indicates the number of SIP-Auth-Data- 1041 Items the SSP is requesting. This can be used, for instance, when the 1042 SSP is requesting several pre-calculated authentication vectors. In 1043 the answer message the SIP-Number-Auth-Items AVP indicates the actual 1044 number of items provided by the Diameter server. 1046 5.7 SIP-User-Data AVP 1048 The SIP-User-Data AVP (AVP Code TBD) is of type OctetString, and MUST 1049 NOT be interpreted by the Diameter protocol. This AVP contains the 1050 user profile data required for a SIP server to give service to a 1051 user. 1053 5.8 NAS-Session-Key AVP 1055 The NAS-Session-Key AVP is defined in [3]. 1057 5.9 NAS-Key-Binding AVP 1059 The NAS-Key-Binding AVP is defined in [3]. 1061 5.10 SIP-Deregistration-Reason AVP 1063 The SIP-Deregistration-Reason AVP (AVP Code TBD) is of type Grouped, 1064 and indicates the reason for a deregistration operation. 1066 Message format 1068 SIP-Deregistration-Reason::= < AVP Header: TBD > 1069 { SIP-Reason-Code } 1070 [ SIP-Reason-Info ] 1071 * [ AVP ] 1073 5.10.1 Reason-Code AVP 1075 The Reason-Code AVP (AVP code TBD) is of type Enumerated, and defines 1076 the reason for the network initiated de-registration. The following 1077 values are defined: 1079 PERMANENT_TERMINATION (0) 1080 NEW_SERVER_ASSIGNED (1) 1081 SERVER_CHANGE (2) 1082 REMOVE_SSP (3) 1084 5.10.2 Reason-Info AVP 1086 The Reason-Info AVP (AVP code TBD) is of type UTF8String, and 1087 contains textual information to inform the user about the reason for 1088 a de-registration. 1090 5.11 Charging-Information AVP 1092 The Charging-Information (AVP code TBD) is of type Grouped, and 1093 contains the addresses of the charging functions. 1095 AVP format 1096 Charging-Information :: = < AVP Header : TBD > 1097 [ Primary-Event-Charging-Function-Name ] 1098 [ Secondary-Event-Charging-Function-Name ] 1099 [ Primary-Charging-Collection-Function-Name ] 1100 [ Secondary-Charging-Collection-Function-Name ] 1101 *[ AVP] 1103 5.11.1 Primary-Event-Charging-Function-Name AVP 1105 The Primary-Event-Charging-Function-Name AVP (AVP Code TBD) is of 1106 type DiameterURI. This AVP contains the address of the Primary Event 1107 Charging Function. 1109 5.11.2 Secondary -Event-Charging-Function-Name AVP 1111 The Secondary-Event-Charging-Function-Name AVP (AVP Code TBD) is of 1112 type DiameterURI. This AVP contains the address of the Secondary 1113 Event Charging Function. 1115 5.11.3 Primary-Charging-Collection-Function-Name AVP 1116 The Primary-Charging-Collection-Function-Name AVP (AVP Code 22) is of 1117 type DiameterURI. This AVP contains the address of the Primary 1118 Charging Collection Function. 1120 5.11.4 Secondary -Charging-Collection-Function-Name AVP 1122 The Secondary-Charging-Collection-Function-Name AVP (AVP Code 23) is 1123 of type DiameterURI. This AVP contains the address of the Secondary 1124 Charging Collection Function. 1126 5.12 User-Authorization-Type AVP 1128 The User-Authorization-Type AVP (AVP code 24) is of type Enumerated, 1129 and indicates the type of user authorization being performed in a 1130 User Authorization operation, i.e. UAR command. The following values 1131 are defined: 1133 REGISTRATION (0) 1134 This value is used in case of the initial registration or re- 1135 registration. HSP determines this from the Expires field in the SIP 1136 REGISTER method if it is not equal to zero. 1137 This is the default value. 1139 DE_REGISTRATION (1) 1140 This value is used in case of the de-registration. HSP determines 1141 this from the Expires field in the SIP REGISTER method if it is equal 1142 to zero. 1144 REGISTRATION_AND_CAPABILITIES (3) 1145 This value is used in case of initial registration or re-registration 1146 and when the HSP explicitly requests SSP capability information from 1147 the AAA. 1149 5.13 User-Data-Request-Type AVP 1151 The User-Data-Request-Type AVP (AVP code TBD) is of type Enumerated, 1152 and indicates the type of user profile the SSP is requesting from the 1153 HSS. The following values are defined: 1155 COMPLETE_PROFILE (0) 1156 This value is used to request from the AAA the complete user profile 1157 corresponding to one or more public identities. 1159 REGISTERED_PROFILE (1) 1160 This value is used to request from the AAA the registered part of the 1161 user profile corresponding to one or more public identities. 1163 UNREGISTERED_PROFILE (2) 1164 This value is used to request from the AAA the unregistered part of 1165 the user profile corresponding to one or more public identities. 1167 5.14 User-Data-Already-Available AVP 1169 The User-Data-Already-Available AVP (AVP code TBD) is of type 1170 Enumerated, and indicates to the HSS whether or not the SSP already 1171 has the part of the user profile that it needs to serve the user. The 1172 following values are defined: 1174 USER_DATA_NOT_AVAILABLE (0) 1175 The SSP does not have the data that it needs to serve the user. 1177 USER_DATA_ALREADY_AVAILABLE (1) 1178 The SSP already has the data that it needs to serve the user. 1180 6. Authentication Details 1182 Authenticating a mobile user can occur through various mechanisms 1183 (http basic or digest authentication have currently been prescribed), 1184 with the actual authentication being performed in either the SIP 1185 server or the AAA server. The choice of the server will determine 1186 the AVPs to be utilized in the SIP-Auth-Data-Item grouped AVP, as 1187 well as a few AVPs in the MAR/MAA. 1189 In the event that the SIP server performs the authentication of a 1190 mobile user, the MAR from the SIP server to the AAA server will 1191 include the SIP-User-Name and SIP-Public-Identity AVPs as necessary, 1192 as well a SIP-Number-Auth-Items AVP to indicate how many 1193 authentication vectors (the actual contents of the vector are 1194 dependent upon the authentication method) are being requested. In 1195 the MAA, the AAA server SHOULD indicate how many SIP-Auth-Data-Item 1196 AVPs are present with the Number-Auth-Items AVP, and may be different 1197 from the amount requested in the MAR. If multiple SIP-Auth-Data-Item 1198 AVPs are present, and their ordering is significant, the Item-Number 1199 MUST be included in each grouping. The Authentication-Scheme and 1200 SIP- Authenticate AVPs will contain data (typically a challenge of 1201 some kind) to be used by the mobile user to authenticate itself. The 1202 SIP- Authorization AVP will contain the response which is expected 1203 from the user. In order to support some auth methods which combine 1204 key distribution with authentication, NAS-Session-Key AVPs may be 1205 included in the event they were requested by including "SIP crypto 1206 node" as one of the Server-Type AVPs in the MAR. 1208 In the event that the AAA server performs the authentication of a 1209 mobile user, the MAR from the SIP server will include a single SIP- 1210 Auth-Data-Item AVP. The SIP-Authentication-Scheme and SIP 1211 Authorization AVPs will contain the relevant parameters from the SIP 1212 message if present, and if necessary, the SIP-Authentication-Context 1213 AVP will contain any additional information needed to perform the 1214 authentication. If the authentication is successful, the MAA will 1215 contain a result code indicating success, and if necessary, the SIP- 1216 Auth-Data-Item AVP may be included to carry session keys back to the 1217 SIP server. If the authentication is unsuccessful due to missing 1218 credentials, the MAA will include an SIP-Auth-Data-Item with the SIP- 1219 Authentication-Scheme and SIP-Authenticate AVPs containing data 1220 (typically a challenge of some kind) to be used by the mobile user to 1221 authenticate itself. 1223 7. IANA Considerations 1225 Command Code values are assigned according to the reference [9]. 1227 8 References 1229 [1] Loughney, Camarillo, Authentication, Authorization and 1230 Accounting Requirements ", draft-ietf-sipping-aaa- req-00.txt, IETF 1231 work in progress, August 2002 1233 [2] Calhoun, Akhtar, Arkko, Guttman, Rubens, Zorn, "Diameter Base 1234 Pro�tocol", draft-ietf-aaa-diameter-15.txt, IETF work in progress, 1235 October 2002 1237 [3] Calhoun, Bulley, Rubens, Haag, Zorn, "Diameter NASREQ 1238 Application", daft-ietf-aaa-diameter-nasreq-09.txt, IETF work in 1239 progress, March 2002 1241 [4] Calhoun, Johansson, Perkins, "Diameter Mobile IPv4 Application," 1242 draft-ietf-diameter-mobileip-13.txt, IETF work in progress, October 1243 2002 1245 [5] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: 1246 Ses�sion Initiation Protocol". RFC 3261, June 2002 1248 [6] IETF RFC 2396: "Uniform Resource Identifiers (URI): generic 1249 syntax" 1251 [7] IETF RFC 2806: "URLs for Telephone Calls" 1253 [8] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access 1254 Authentication" 1256 [9] J. Loughney, "Provisional Diameter Command Codes for 3GPP", 1257 draft-loughney-aaa-cc-3gpp-00.txt, IETF work in progress, October 1258 2002 1260 [10] IETF RFC 2119: "Key words for use in RFCs to Indicate 1261 Requirement Levels" 1263 9 Authors' Addresses 1265 Carolina Canales Phone: +34 913392680 1266 Ericsson Spain Fax: +34 913392538 1267 Via de los Poblados, 13 1268 28033 Madrid 1269 Spain 1270 E-mail: carolina.canales-valenzuela@ece.ericsson.se 1272 Miguel-Angel Pallares Phone: +34 913394222 1273 Ericsson Spain Fax: +34 913392538 1274 Via de los Poblados, 13 1275 28033 Madrid 1276 Spain 1277 E-mail: miguel-angel.pallares-lopez@ece.ericsson.se 1279 Maria-Carmen Belinchon Phone: +34 913393535 1280 Ericsson Spain Fax: +34 913392906 1281 Via de los Poblados, 13 1282 28033 Madrid 1283 Spain 1284 E-mail: maria.c.belinchon@ericsson.com 1286 Peter J. McCann Phone: +1 630 713 9359 1287 Lucent Technologies Fax: +1 630 713 4982 1288 Rm 2Z-305 1289 263 Shuman Blvd 1290 Naperville, IL 60566-7050 1291 USA 1292 E-Mail: mccap@lucent.com 1294 Jaakko Rajaniemi Phone: +358 50 3391387 1295 Nokia Networks Fax: +358 9 51130163 1296 P.O. Box 301 1297 00045 Nokia Group 1298 Finland 1299 E-mail: jaakko.rajaniemi@nokia.com 1301 10. Full Copyright Statement 1303 Copyright (C) The Internet Society (2001). All Rights Reserved. 1305 This document and translations of it may be copied and furnished to 1306 others, and derivative works that comment on or otherwise explain it 1307 or assist in its implementation may be prepared, copied, published 1308 and distributed, in whole or in part, without restriction of any 1309 kind, provided that the above copyright notice and this paragraph are 1310 included on all such copies and derivative works. However, this docu� 1311 ment itself may not be modified in any way, such as by removing the 1312 copyright notice or references to the Internet Society or other 1313 Internet organizations, except as needed for the purpose of develop� 1314 ing Internet standards in which case the procedures for copyrights 1315 defined in the Internet Standards process must be followed, or as 1316 required to translate it into languages other than English. The lim� 1317 ited permissions granted above are perpetual and will not be revoked 1318 by the Internet Society or its successors or assigns. This document 1319 and the information contained herein is provided on an "AS IS" basis 1320 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS� 1321 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1322 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1323 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1324 FITNESS FOR A PARTICULAR PURPOSE.