[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

AAA Working Group                                      Tony Johansson
INTERNET DRAFT                                           Kevin Purser
Category: Standards Track                            Carolina Canales
<draft-johansson-aaa-diameter-mm-app-00.txt>    Miguel-Angel Pallares
                                                             Ericsson
                                                      Peter J. McCann
                                                               Lucent
                                                     Jaakko Rajaniemi
                                                                Nokia
                                                             Jan 2002




                    Diameter Multimedia Application



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:

      http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:

      http://www.ietf.org/shadow.html.

   This document is an individual contribution for consideration by the
   SIP Working Group of the Internet Engineering Task Force. Comments
   should be submitted to the diameter@diameter.org mailing list.

   Distribution of this memo is unlimited.

   Copyright   (C) The Internet Society 2001.  All Rights Reserved.





johansson et al.            expires July 2002                   [Page 1]


INTERNET DRAFT                                                  Jan 2002


Abstract

   This document specifies a Diameter application that allows a Diameter
   server to authenticate, authorize, and collect accounting information
   for Session Initiation Protocol (SIP) services rendered to a client
   node.  This application, combined with the base Diameter protocol and
   appropriate SIP extensions, allows SIP User Agents (UAs) to obtain
   services from SIP servers that are connected to a Diameter
   infrastructure.  When combined with the Inter-Domain capability of
   the base protocol, service may even be obtained from SIP servers that
   belong to foreign domains, as would be encountered by roaming mobile
   nodes.

   Note that the specification defined here may be used independently of
   the authentication technique used for authenticating a node's link-
   layer or network-layer access.  In particular, we do not require that
   the client node was authenticated for access with the use of either
   the Mobile IP [3] or NASREQ [2] Diameter application.

































johansson et al.            expires July 2002                   [Page 2]


INTERNET DRAFT                                                  Jan 2002


Table of Contents

      1.0  Introduction
          1.1  Requirements language
          1.2  Abbreviations
      2.0 Description of a SIP network architecture
          2.1 User Authentication by SSP
          2.2 User Authentication by AAA server
          2.3 Single SIP server
          2.4 Invitation
          2.5 Profile Updating
          2.6 Termination
              2.6.1 User registration termination
      3.0 Command Codes
          3.1 User-Authorization-Request (UAR)
          3.2 User-Authorization-Answer (UAA)
          3.3 Multimedia-Auth-Request (MAR)
          3.4 Multimedia-Auth-Answer (MAA)
          3.5 Profile-Update-Request (PUR)
          3.6 Profile-Update-Answer (PUA)
          3.7 Location-Info-Request (LIR)
          3.8 Location-Info-Answer (LIA)
      4.0 Result Code AVP values
          4.1 Success
          4.2 Permanent failures
      5.0 Diameter AVP values
          5.1 SIP-Server AVP
          5.2 SIP-Server-Name AVP
          5.3 SIP-Server-Capability AVP
          5.4 Public-Identity AVP
          5.5 Visited-Network-Identifier AVP
          5.6 SIP-Feature-Vector AVP
          5.7 Profile-Update-Type AVP
          5.7 SIP-Challenge AVP
          5.8 Authentication-Scheme AVP
          5.9 Authentication-Challenge AVP
          5.10 Authentication-Response AVP
          5.11 Authentication-Context AVP
          5.12 Number-Authentication-Items AVP
          5.13 Authentication-Data-Item AVP
          5.14 Item-Number AVP
          5.15 User-Data AVP
          5.16 NAS-Session-Key AVP
          5.17 NAS-Key-Binding AVP
          5.18 Desired-User-Capabilities AVP
          5.19 SIP-Mandatory-Capability AVP
          5.20 SIP-Optional-Capability AVP
          5.21 Deregistration-Reason AVP



johansson et al.            expires July 2002                   [Page 3]


INTERNET DRAFT                                                  Jan 2002


          5.22 EAP-Payload
      6.0 References
      7.0 Authors' Addresses
      8.0 Full Copyright Statement















































johansson et al.            expires July 2002                   [Page 4]


INTERNET DRAFT                                                  Jan 2002


1.0  Introduction

   This document specifies a Diameter application that allows a Diameter
   server to authenticate, authorize and collect accounting information
   for SIP-based IP multimedia services rendered to a client node.  We
   assume that a client node implements a SIP User Agent (UA) that
   carries out SIP protocol actions with a SIP server, which in turn
   relies on the AAA infrastructure for authenticating the client,
   authorizing it for particular SIP services, and accounting for this
   usage.

   SIP servers can be proxy, redirect, registration, or user agent
   servers.  Additionally, SIP servers may be arranged in arbitrary ways
   according to the inter-service provider relationships involved in
   servicing a given client.  For example, a mobile node may use a SIP
   proxy in the visited network, but its SIP messages may be proxied
   back to a SIP server in the home network that implements call control
   features.  Combined with the Inter-Domain capability of the base
   protocol, this extension would allow such mobile terminals to receive
   service from foreign service providers according to their location
   and subscription profile.  Any or all of the SIP servers may need to
   independently authenticate the client, authorize service, and account
   for usage.

   Authentication must take place at the time the user agent registers
   with the SIP server (or chain of SIP proxies and servers).  The
   particular algorithm used to authenticate a SIP user agent client is
   a matter of policy agreement between the user agent client, the SIP
   server, and the home AAA server.  This document supports an embedding
   of the Extensible Authentication Protocol (EAP) authentication
   method, along with the WWW-Authenticate methods Basic and Digest
   which are supported by SIP.  This is in the expectation that an EAP
   authentication method will be added to SIP.  In addition to
   authenticating the user agent client, such a method could also be
   used to generate or distribute keys for subsequent SIP-layer message
   integrity and privacy.  The specification of such an algorithm, and
   its embedding in SIP, is outside the scope of this document.

   Authorization for SIP services may take many forms.  For example, a
   proxy may need to know that the user agent client is authorized to
   register, but from then on it may simply pass messages through to
   other SIP servers.  However, a SIP server that implements call
   control features may need a richer and more complete description of
   the services to which the user has subscribed.







johansson et al.            expires July 2002                   [Page 5]


INTERNET DRAFT                                                  Jan 2002


   Accounting for SIP services is on a per-call basis.  An accounting
   record contains a SIP Call-ID, any SDP that was exchanged to set up
   the call, the duration of the call, and any resources that were
   consumed on behalf of the call (such as number of bytes exchanged
   between the parties).  Note that accounting for resources may require
   the SIP server to interact with other network entities, such as media
   gateways, for the collection of this information.  Such interaction
   is outside the scope of this document.

   Some example scenarios, inspired by the emerging wireless
   applications of SIP, are given in Section 1.2.  Sections 2, 3 and 4
   address the Diameter Multimedia Application's specific commands,
   result codes, and AVPs, respectively.  Section 5 gives IANA
   considerations.


1.1 Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [3].






























johansson et al.            expires July 2002                   [Page 6]


INTERNET DRAFT                                                  Jan 2002


2.0 Description of a SIP network architecture

                                     Home Realm
                                     +-------+
                         UAR/UAA +-->|  AAA  |<--+ PUR/PUA
                         MAR/MAA |   |xyz.com|   | MAR/MAA
                         LIR/LIA |   +-------+   |
      Local Realm                v               v
       +-------+             +-------+       +-------+
       |  OSP  |<----------->|  HSP  |<----->|  SSP  |
       |abc.com|     SIP     |xyz.com|  SIP  |xyz.com|
       +-------+             +-------+       +-------+
           ^                     ^
           | SIP                 |
           v                     |
       +-------+            SIP  |
       |  UAE  |<----------------+
       +-------+
      bob@xyz.com
                   Figure 1: SIP network infrastructure

   Figure 1 above illustrates the nodes involved in a SIP multimedia
   network architecture as put forth in [1].  The home realm (xyz.com)
   is comprised of a Diameter AAA server, at least one home entry SIP
   proxy (HSP) which is the gateway SIP proxy seen by the rest of the
   world, and any number of serving SIP proxy (SSP) nodes.  These SSP
   nodes may be deployed piecemeal for various reasons such as but not
   limited to load balancing, scalability, and offering distinct,
   separate services.  The mobile node in this scenario (bob@xyz.com)
   may either connect directly to its HSP, or via an outbound SIP server
   (OSP) in the local realm.  In larger networks, registrations MAY be
   routed to different HSPs, potentially even for a subsequent SIP
   registration for the same user, and thus HSPs are usually stateless.

   The next few sections will describe in detail the different modes of
   operation that are available to such an infrastructure.  These
   options may be either administratively configured to suit local
   policies, or determined dynamically by the network.  For the purposes
   of authentication and authorization, the procedures involved when
   using a OSP are a superset of the procedures involved in the absence
   of a OSP, and therefore we will skip a needless explanation of the
   latter scenario.


2.1 User authentication by SSP

   An operator with a large base of installed SIP servers may wish to
   minimize the impact of modifying SIP servers to interact with



johansson et al.            expires July 2002                   [Page 7]


INTERNET DRAFT                                                  Jan 2002


   Diameter AAA servers.  This can be achieved by allowing SIP servers
   to retain the functionality of authentication, rather than exporting
   this capability to the AAA server.  However, it should be noted that
   this mode will not leverage the extensive array of authentication and
   authorization services which will already be present regardless in
   diameter servers.  Below follows an example of a SIP user
   registration using this mode of operation.

             +-------+           +-------+           +-------+
             |  HSP  |           |  AAA  |           |  SSP  |
             +---+---+           +---+---+           +---+---+
                 |                   |                   |
      1. SIP-REG |                   |                   |
      ---------->|     2. UAR        |                   |
                 +------------------>|                   |
                 |     3. UAA        |                   |
                 |<------------------+                   |
                 |                   |    4. SIP-REG     |
                 +-------------------------------------->|
                 |                   |      5. MAR       |
                 |                   |<------------------+
                 |                   |      6. MAA       |
                 |                   +------------------>|
                 |     7. 401 (Unauthorized)             |
      8. 401     |<--------------------------------------+
     <-----------+                   |                   |
      9. SIP-REG |                   |                   |
      ---------->|     10. UAR       |                   |
                 +------------------>|                   |
                 |     11. UAA       |                   |
                 |<------------------+                   |
                 |                   |    12. SIP-REG    |
                 +-------------------------------------->|
                 |                   |      13. PUR      |
                 |                   |<------------------+
                 |                   |      14. PUA      |
                 |                   +------------------>|
                 |     15. 200 (OK)  |                   |
      16. 200    |<--------------------------------------+
     <-----------+                   |                   |
                 |                   |                   |
               Figure 2: Authentication performed by the SSP

   In this scenario, a user sends a SIP registration to the home domain.
   The HSP will contact its local diameter server with a "User-
   Authorization-Request" (UAR) to authorize if this user is allowed to
   receive service and if so, request the identity of a local SIP server
   capable of handling this user.  The diameter server will respond with



johansson et al.            expires July 2002                   [Page 8]


INTERNET DRAFT                                                  Jan 2002


   a "User-Authorization-Answer" (UAA), which will indicate a list of
   capabilities from which the HSP will use to select the SSP. Once it
   forwards the initial SIP registration to the appropriate SSP, the SSP
   will then request authentication parameters from the diameter server
   through a "Multimedia-Auth-Request" (MAR).  This request MAY also
   serve to identify the SSP, so as to return subsequent registration
   requests to the same SSP.  The diameter server will respond with a
   "Multimedia-Auth-Answer" (MAA), which will include all parameters
   necessary for the designated authentication algorithm associated with
   the user.  The SSP will then create the 401 (Unauthorized) message,
   including the authentication material needed by the mobile user to
   prove their identity.

   When the subsequent SIP registration is received from the user, the
   HSP will once again contact the diameter server with a UAR to
   determine to which SSP to forward the registration. The HSP will then
   forward the SIP registration to the SSP node, which will then perform
   the authentication procedure.  Upon completion, the SSP will notify
   the AAA server through a "Profile-Update-Request" (PUR), indicating
   successful registration of the user, and the definitive name of the
   SSP.  After the AAA server responds with a "Profile-Update-Answer"
   (PUA), including user profile information that the SSP will user to
   provide service to the user, the SSP will produce a 200 (OK) message,
   and send it to the HSP. The HSP will then forward the 200 (OK)
   message to the mobile user.

2.2 User authentication by AAA server

   A different approach in deploying SIP networks is to allow the
   Diameter server to perform the actual authentication.  In addition to
   leveraging the robust authentication services offered by the AAA
   server, it will reduce the number of messages sent in the network.



















johansson et al.            expires July 2002                   [Page 9]


INTERNET DRAFT                                                  Jan 2002


             +-------+           +-------+           +-------+
             |  HSP  |           |  AAA  |           |  SSP  |
             +---+---+           +---+---+           +---+---+
                 |                   |                   |
      1. SIP-REG |                   |                   |
      ---------->|     2. UAR        |                   |
                 +------------------>|                   |
                 |     3. UAA        |                   |
                 |<------------------+                   |
                 |                   |    4. SIP-REG     |
                 +-------------------------------------->|
                 |                   |      5. MAR       |
                 |                   |<------------------+
                 |                   |      6. MAA       |
                 |                   +------------------>|
                 |     7. 401 (Unauthorized)             |
      8. 401     |<--------------------------------------+
     <-----------+                   |                   |
      9. SIP-REG |                   |                   |
      ---------->|     10. UAR       |                   |
                 +------------------>|                   |
                 |     11. UAA       |                   |
                 |<------------------+                   |
                 |                   |    12. SIP-REG    |
                 +-------------------------------------->|
                 |                   |      13. MAR      |
                 |                   |<------------------+
                 |                   |      14. MAA      |
                 |                   +------------------>|
                 |     15. 200 (OK)  |                   |
      16. 200    |<--------------------------------------+
     <-----------+                   |                   |
                 |                   |                   |
           Figure 3: Authentication performed by the AAA server

   In this scenario, the user will send a SIP register message to it's
   home domain.  When the HSP receives this request, it will contact its
   local diameter server with a "User-Authorization-Request" (UAR) to
   determine if this user is allowed to receive service and if so,
   request the identity of a local SIP server capable of handling this
   user, as described in the previous section.  The diameter server will
   respond with a "User-Authorization-Answer" (UAA), which will indicate
   a list of capabilities from which the HSP will use to select the SSP.
   Once it forwards the initial SIP registration to the appropriate SSP,
   the SSP will then request user authentication from the Diameter
   server through a "Multimedia-Auth-Request" (MAR).  This request MAY
   also serve to identify the SSP, so as to return subsequent
   registration requests to the same SSP.  The Diameter server will then



johansson et al.            expires July 2002                  [Page 10]


INTERNET DRAFT                                                  Jan 2002


   respond with a "Multimedia-Auth-Answer" (MAA) with Result-Code equal
   to DIAMETER_MULTI_ROUND_AUTH and the challenge information, which the
   SSP will use to map into the WWW-authentication header in the SIP 401
   unauthorized and send back to the HSP.

   When the subsequent SIP registration is received from the user, the
   HSP will once again contact the diameter server with a UAR to
   determine to which SSP to forward the registration. The HSP will then
   forward the SIP registration to the SSP node, which will then extract
   the relevant authentication parameters, and include these in a MAR
   message to the AAA server. This request MAY also serve to identify
   the SSP, so as to return subsequent registration requests to the same
   SSP. At this point, the Diameter server will be able to authenticate
   the user, and upon success, will return a MAA with Result-Code equal
   to DIAMETER_SUCCESS and include user profile information, which the
   SSP will use to give service to the user, the SSP will then produce a
   200 (OK) message and send it to the HSP, which will then forward it
   to the mobile user.

































johansson et al.            expires July 2002                  [Page 11]


INTERNET DRAFT                                                  Jan 2002


2.3 Single SIP server

   Some smaller networks where having more than one SIP server may be
   either cost-prohibitive, or simply unnecessary due a small number of
   services or users may decide to forgo the use of SSP nodes.  In such
   a scenario, the gateway HSP node could provide the desired SIP
   services, using the AAA server as a back-end authentication server.

             +-------+           +-------+
             |  HSP  |           |  AAA  |
             +---+---+           +---+---+
                 |                   |
      1. SIP-REG |                   |
      ---------->|     2. MAR        |
                 +------------------>|
                 |     3. MAA        |
      4. 401     |<------------------+
     <-----------+                   |
      5. SIP-REG |                   |
      ---------->|     6. MAR        |
                 +------------------>|
                 |     7. MAA        |
      8. 200     |<------------------|
     <-----------+                   |
                 |                   |
          Figure 4: Networks with only a single SIP server (HSP)

   Again, steps 1-6 in this mode of operation are almost identical to
   those in section 2.3, with the exception that the MAR in this step 6
   will also indicate that there are no other SIP servers in the
   network.  If the AAA is able to successfully authenticate the user,
   it will then be able to directly associate the user with the HSP, and
   will not send a list of candidate SSPs in the MAA response.  The HSP
   will then produce a 200 (OK) SIP message and send it to the user.

   In networks that deploy SSP nodes as well, this mode of operation may
   also be invoked dynamically as a fail-over mechanism.  For example,
   since the AAA server will maintain connectivity toward all candidate
   SSP nodes in a network, in the event that they all become
   unreachable, the AAA server's MAA response will return zero candidate
   SSP nodes.  This lack of candidate SSP nodes will implicitly indicate
   to the HSP that it should serve the user directly.









johansson et al.            expires July 2002                  [Page 12]


INTERNET DRAFT                                                  Jan 2002


2.4 Invitation

   When a registered user wishes to invite another registered user, it
   will send a SIP Invite request to the home domain (HSP) of the
   invitee.

             +-------+           +-------+           +-------+
             |  HSP  |           |  AAA  |           |  SSP  |
             +---+---+           +---+---+           +---+---+
                 |                   |                   |
      1. SIP-INV |                   |                   |
      ---------->|     2. LIR        |                   |
                 +------------------>|                   |
                 |     3. LIA        |                   |
                 |<------------------+                   |
                 |                   |    4. SIP-INV     |
                 +-------------------------------------->|
                 |                   |                   |

                      Figure 5. A SIP Invite request

   In this scenario, when a user, say Bob, contacts the HSP to invite
   another user, say Mary, the HSP will issue a diameter "Location-Info-
   Request" (LIR) message to the AAA server to request the identity of
   the SSP currently assigned to Mary.  The AAA server will respond with
   a diameter "Location-Info-Answer" (LIA), indicating the appropriate
   SSP, and the HSP will forward the SIP Invite message directly to the
   named SSP.























johansson et al.            expires July 2002                  [Page 13]


INTERNET DRAFT                                                  Jan 2002


2.5 User Profile Updating

   Whenever a modification in the user profile has occurred, the AAA
   server and SSP must synchronize their user profile data.

         +-------+           +-------+
         |  AAA  |           |  SSP  |
         +---+---+           +---+---+
             |                   |
             |     1. PUR        |
             +------------------>|
             |                   |
             |     2. PUA        |
             |<------------------+
             |                   |
           Figure 6. User profile update initiated by AAA server

   The AAA server sends a Profile-Update-Request (PUR) to the serving
   SIP server to which the user is registered. The PUR message contains
   a User-Data AVP, a User-Name AVP, and zero or more Public-Identity
   AVPs.  The presence of the User-Name AVP without any Public-Identity
   AVPs serves to indicate that the entire user profile associated with
   the User-Name AVP should be updated.  A PUR with a User-Name AVP and
   one or more Public-Identity AVPs serves to indicate that the user
   profile data associated with each of the Public-Identity AVPs should
   be updated.

   If the user profile changes in the serving SIP server, the same
   message scheme is used, but is initiated by the serving SIP server
   (instead of the AAA server).

2.6 Termination

2.6.1 User registration termination

   Termination of an entire user registration can be achieved by one of
   two mechanisms.  In the event that NO_STATE_MAINTAINED (i.e NO
   Diameter user session-id is maintained) has been indicated in a prior
   Auth-Session-State AVP, termination is handled with a Profile-Update-
   Request.

   On the other hand, if STATE_MAINTAINED has been indicated in a prior
   Auth-Session-State AVP, the use of Session-Termination-Request (STR)
   and Abort-Session-Request (ASR) messages as defined in the base
   protocol are used to terminate an entire user registration.

   Reasons for terminating a user registration could be due to the
   expiration of the SIP registration timer in the SIP server, a user



johansson et al.            expires July 2002                  [Page 14]


INTERNET DRAFT                                                  Jan 2002


   initiated SIP de-registration, or a AAA-initiated de-registration as
   a result of administrative reasons.

3.0  Command Codes

   This section will define the specific message formats used by this
   diameter application.

3.1 User-Authorization-Request (UAR)

   The User-Authorization-Request (UAR), indicated by the Command-Code
   field set to TBD and the 'R' bit set in the Command Flags field, is
   sent by a HSP node, acting as a Diameter client, to a AAA server in
   order to request authorization of a mobile user.

   Message Format
    < User-Authorization-Request > ::= < Diameter Header: TBD, REQ, PXY>
                                       < Session-ID >
                                       { Auth-Application-Id }
                                       { Auth-Session-State }
                                       { User-Name }
                                       { Destination-Realm }
                                       { Origin-Host }
                                       { Origin-Realm }
                                       [ Public-Identity ]
                                       [ Visited-Network-Identifier ]
                                       [ SIP-Feature-Vector ]
                                       [ Authorization-Lifetime ]
                                       [ Auth-Grace-Period ]
                                       [ Destination-Host ]
                                       [ Origin-State-Id ]
                                     * [ AVP ]
                                     * [ Proxy-Info ]
                                     * [ Route-Record ]


3.2 User-Authorization-Answer (UAA)

   The User-Authorization-Answer (UAA), indicated by the Command-Code
   field set to TBD and the 'R' bit cleared in the Command Flags field,
   is sent by a AAA server in response to the User-Authorization-Request
   command. The Result-Code AVP may contain one of the values defined in
   section 4.0 in addition to the values defined in [2].


   If the user has not previously been authorized, the UAA will make use
   of the Desired-User-Capabilities and SIP-Server AVPs to convey
   information needed by the HSP to select an appropriate SSP.  If the



johansson et al.            expires July 2002                  [Page 15]


INTERNET DRAFT                                                  Jan 2002


   user has already been authorized and a server is already assigned,
   the SIP-Server-Name AVP MUST contain the SIP URL of the server, so
   that the HSP can forward the registration request to it.

   The use of Desired-User-Capabilities and SIP-Server AVPs and a SIP-
   Server-Name AVP are mutually exclusive.


   Message Format
    < User-Authorization-Answer > ::= < Diameter Header: TBD, PXY >
                                      < Session-Id >
                                      { Auth-Application-Id }
                                      { Auth-Session-State }
                                      { Result-Code }
                                      { Origin-Host }
                                      { Origin-Realm }
                                      [ User-Name ]
                                      [ Accounting-Multi-Session-Id ]
                                      [ Authorization-Lifetime ]
                                      [ Auth-Grace-Period ]
                                      [ Error-Message ]
                                      [ Error-Reporting-Host ]
                                      [ Desired-User-Capabilities ]
                                    * [ SIP-Server ]
                                      [ SIP-Server-Name ]
                                    * [ AVP ]
                                    * [ Proxy-Info ]
                                    * [ Route-Record ]


3.3 Multimedia-Auth-Request (MAR)

   The Multimedia-Auth-Request (MAR), indicated by the Command-Code
   field set to TBD and the 'R' bit set in the Command Flags field, is
   sent by a HSP node or SSP node, acting as a Diameter client, to a
   server in order to request the authentication and authorization of a
   mobile user.  The Diameter client uses information found in the SIP
   Request to construct the AVPs that are to be included as part of the
   MAR.

   In addition, local policies as well as the current state of the
   network will determine the options set in the SIP-Feature-Vector AVP.









johansson et al.            expires July 2002                  [Page 16]


INTERNET DRAFT                                                  Jan 2002


   Message Format

    < Multimedia-Auth-Request > ::= < Diameter Header: TBD, REQ, PXY >
                                    < Session-ID >
                                    { Auth-Application-Id }
                                    { Auth-Session-State }
                                    { Destination-Realm }
                                    { Origin-Host }
                                    { Origin-Realm }
                                    { SIP-Feature-Vector }
                                    [ User-Name ]
                                    [ Public-Identity ]
                                    [ Number-Authentication-Items ]
                                    [ Auth-Data-Item ]
                                    [ SIP-Server-Name ]
                                    [ Authorization-Lifetime ]
                                    [ Auth-Grace-Period ]
                                    [ Destination-Host ]
                                    [ Origin-State-Id ]
                                  * [ AVP ]
                                  * [ Proxy-Info ]
                                  * [ Route-Record ]



3.4 Multimedia-Auth-Answer (MAA)

   The Multimedia-Auth-Answer (MAA), indicated by the Command-Code field
   set to TBD and the 'R' bit cleared in the Command Flags field, is
   sent by the server in response to the Multimedia-Auth-Request
   command.




















johansson et al.            expires July 2002                  [Page 17]


INTERNET DRAFT                                                  Jan 2002


   Message Format

    < Multimedia-Auth-Answer > ::= < Diameter Header: TBD, PXY >
                                   < Session-Id >
                                   { Auth-Application-Id }
                                   { Auth-Session-State }
                                   { Result-Code }
                                   { Origin-Host }
                                   { Origin-Realm }
                                   [ User-Data ]
                                   [ User-Name ]
                                   [ Accounting-Multi-Session-Id ]
                                   [ Authorization-Lifetime ]
                                   [ Auth-Grace-Period ]
                                   [ Error-Message ]
                                   [ Error-Reporting-Host ]
                                 * [ SIP-Server ]
                                   [ Number-Authentication-Items ]
                                 * [ Authentication-Data-Item ]
                                   [ Session-Timeout ]
                                   [ Origin-State-Id ]
                                 * [ AVP ]
                                 * [ Proxy-Info ]
                                 * [ Route-Record ]

3.5 Profile-Update-Request

   The Profile-Update-Request (PUR) command, indicated by the Command-
   Code field set to TBD and the 'R' bit set in the Command Flags field,
   is sent in order to update or request the user profile data of a
   registered user.




















johansson et al.            expires July 2002                  [Page 18]


INTERNET DRAFT                                                  Jan 2002


    < Profile-Update-Request > ::= < Diameter Header: TBD, REQ, PXY >
                                   < Session-Id >
                                   { Auth-Application-Id }
                                   { Auth-Session-State }
                                   { Origin-Host }
                                   { Origin-Realm }
                                   { Destination-Realm }
                                   { Profile-Update-Type }
                                   [ Destination-Host ]
                                   [ User-Name ]
                                   [ User-Data ]
                                   [ SIP-Server-Name ]
                                   [ Deregistration-Reason ]
                                 * [ Public-Identity ]
                                 * [ AVP ]
                                 * [ Proxy-Info ]
                                 * [ Route-Record ]

3.6 Profile-Update-Answer

   The Profile-Update-Answer (PUA) command, indicated by the Command-
   Code field set to TBD and the 'R' bit cleared in the Command Flags
   field, is sent in response to the Profile-Update-Request command.
   The Result-Code AVP may contain one of the values defined in section
   4 in addition to the values defined in [2].

    < Profile-Update-Answer > ::= < Diameter Header: TBD, PXY >
                                  < Session-Id >
                                  { Auth-Application-Id }
                                  { Auth-Session-State }
                                  { Result-Code }
                                  { Origin-Host }
                                  { Origin-Realm }
                                  [ User-Data ]
                                  [ User-Name ]
                                * [ AVP ]
                                * [ Proxy-Info ]
                                * [ Route-Record ]













johansson et al.            expires July 2002                  [Page 19]


INTERNET DRAFT                                                  Jan 2002


3.7 Location-Info-Request (LIR)

   The Location-Info-Request (LIR), indicated by the Command-Code field
   set to TBD and the 'R' bit set in the Command Flags field, is sent by
   a HSP node, acting as a Diameter client, to a Diameter server in
   order to request the identity of SIP server currently associated with
   a particular user.

   Message Format
    < Location-Info-Request > ::= < Diameter Header: TBD, REQ, PXY >
                                  < Session-ID >
                                  { Auth-Application-Id }
                                  { Auth-Session-State }
                                  { Destination-Realm }
                                  { Origin-Host }
                                  { Origin-Realm }
                                  [ Destination-Host ]
                                  [ User-Name ]
                                  [ Public-Identity ]
                                * [ AVP ]
                                * [ Proxy-Info ]
                                * [ Route-Record ]

3.8 Location-Info-Answer (LIA)

   The Location-Info-Answer (LIA), indicated by the Command-Code field
   set to TBD and the 'R' bit cleared in the Command Flags field, is
   sent by a Diameter server in response to a Location-Info-Request.  If
   the user in the request is currently registered in the AAA server,
   the answer will include the identity of the SIP server currently
   associated with the user.

   Message Format


















johansson et al.            expires July 2002                  [Page 20]


INTERNET DRAFT                                                  Jan 2002


    < Location-Info-Answer > ::= < Diameter Header: TBD, PXY >
                              < Session-Id >
                              { Auth-Application-Id }
                              { Result-Code }
                              { Origin-Host }
                              { Origin-Realm }
                              [ User-Name ]
                              [ Error-Message ]
                              [ Error-Reporting-Host ]
                              [ Desired-User-Capabilities ]
                            * [ SIP-Server ]
                              [ SIP-Server-Name ]
                            * [ AVP ]
                            * [ Proxy-Info ]
                            * [ Route-Record ]


4.0 Result Code AVP values

   This section defines new Result codes in addition to the values
   defined in [2].

4.1 Success

   Errors that fall within the Success category are used to inform a
   peer that a request has been successfully completed.

     DIAMETER_FIRST_REGISTRATION     2xxx
      The user was not previously registered, and has now been
      authorized by the AAA server.  Information necessary to select an
      appropriate SSP SHOULD be included in the message.

     DIAMETER_SUBSEQUENT_REGISTRATION     2xxx
      The user has been previously registered, and has now been re-
      authorized by the AAA server.  The identity of the SSP to which
      the user is currently registered SHOULD by included in the
      message.

     DIAMETER_UNREGISTERED_SERVICE     2xxx
      The user is not currently registered, but the requested service
      can still be granted to the user.

4.2 Permanent failures

   Errors that fall within the permanent failures category are used to
   inform the peer that the request failed, and should not be attempted
   again.




johansson et al.            expires July 2002                  [Page 21]


INTERNET DRAFT                                                  Jan 2002


     DIAMETER_ERROR_ROAMING_NOT_ALLOWED     5xxx
      This error code is used to inform the user is not allowed to roam
      in the visited network.

     DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED     5xxx
      The identity being registered has already a server assigned and
      the registration status does not allow that it is overwritten.

     DIAMETER_ERROR_IDENTITY_NOT_REGISTERED     5xxx
      This error code is used to inform that the received public
      identity has not been registered before and the user to which this
      identity belongs cannot be given service in this situation.

     DIAMETER_ERROR_IDENTITIES_DONT_MATCH     5xxx
      The value in one of the Public-Identity AVPs does not correspond
      to the user specified in the User-Name AVP.

5.0 Diameter AVP values
   The following sections define the AVPs used in this diameter
   application.

5.1 SIP-Server AVP

   The SIP-Server AVP (AVP code TBD) is of type Grouped. This AVP MAY be
   used by the HSP to assist in the selection of a SSP.

    SIP-Server ::= < AVP Header: TBD >
                   { SIP-Server-Name }
                 * [ SIP-Server-Capability ]
                 * [ AVP ]

5.2 SIP-Server-Name AVP

   The Server-Name AVP (AVP Code TBD) is of type UTF8String.  This AVP
   contains a SIP-URL (as defined in [5] and [6]) used to identify a SIP
   server.

   The HSP MAY include the Server-Name AVP to inform the Diameter server
   which SSP to use for the SIP user or the Server-Name AVP MAY be used
   by the Diameter server to inform the HSP that the SIP UA client is
   assigned at the following SSP server.

5.3 SIP-Server-Capability AVP

   The SIP-Server-Capability AVP (AVP Code TBD) is of type Unsigned32.
   The value indicates a specific SIP capability supported by a SIP
   server.




johansson et al.            expires July 2002                  [Page 22]


INTERNET DRAFT                                                  Jan 2002


5.4 Public-Identity AVP

   The Public-Identity AVP (AVP Code TBD) is of type OctetString,
   encoded in the UTF-8 [9] format.  The syntax of this AVP corresponds
   either to a SIP URL (with the format defined in [5] and [6]) or a TEL
   URL (with the format defined in [7]).

   The Diameter client (HSP or SSP) uses information found in the header
   of the SIP messages (e.g. To: field in REGISTER messages or From:
   field in INVITE messages) to construct the Public-Identity AVP.

5.5 Visited-Network-Identifier AVP

   The Visited-Network-Identifier AVP (AVP Code TBD) is of type
   OctetString. This AVP contains an identifier that helps the home
   network to identify the visited network (e.g. the visited network
   domain name).

5.6 SIP-Feature-Vector AVP

   The SIP-Feature-Vector AVP (AVP Code TBD) is of type Unsigned32 and
   contains a bitmap to indicate options requested by the HSP or SSP.
   The SIP-Feature-Vector AVP MUST be included the in the MAR message
   sent to the AAA server. The flag values are currently defined in a
   bitmap as follows:


   AAA_AUTH             1
   AAA_SSP_SELECTION    2
   SERVING_SIP_SERVER   4
   HSP_CAN_SERVE        8



   If the HSP or SSP requests the AAA server to perform authentication
   and authorization of a user, it sets the AAA_AUTH bit, otherwise this
   bit must be cleared.  If the HSP requests that the AAA server select
   the SSP, the HSP sets the AAA_SSP_SELECTION bit.  If the HSP is
   capable of directly offering services to a particular user, it sets
   the HSP_CAN_SERVE bit.  These options will usually be statically
   configured according to local administrative policy.

   The SERVING_SIP_SERVER bit can be set either dynamically or according
   to local configuration.  In smaller networks where the HSP is the
   only SIP server in the domain, the HSP MUST set the
   SERVING_SIP_SERVER bit.  In larger networks, when the HSP receives a
   SIP request from a user, and decides it should be the SIP server
   assigned to the user based on information in the SIP request, it sets



johansson et al.            expires July 2002                  [Page 23]


INTERNET DRAFT                                                  Jan 2002


   the SERVING_SIP_SERVER bit.

   If the HSP sets the SERVING_SIP_SERVER bit, it MUST set the
   HSP_CAN_SERVE bit.  If the HSP sets the SERVING_SIP_SERVER bit, it
   MUST NOT set the AAA_SSP_SELECTION bit, and vice versa.

5.7 Profile-Update-Type AVP

   The Profile-Update-Type AVP (AVP code TBD) is of type Enumerated, and
   indicates the type of server update being performed in a Profile-
   Update-Request operation.

   The following values are defined:
   NO_ASSIGNMENT                       0
   REGISTRATION                        1
   RE_REGISTRATION                     2
   UNREGISTERED_USER                   3
   TIMEOUT_DEREGISTRATION              4
   USER_DEREGISTRATION                 5
   AUTHENTICATION_FAILURE              6
   UPDATE_PROFILE                      7
   RETRIEVE_PROFILE                    8
   ADMINISTRATIVE_DEREGISTRATION       9

5.8 Authentication-Scheme AVP

   The Authentication-Scheme AVP (AVP code TBD) is of type UTF8String
   and indicates the authentication scheme (auth-scheme in [8] and [9])
   used in the authentication of SIP messages.

5.9 Authentication-Challenge AVP

   The Authentication-Challenge AVP (AVP code TBD) is of type UTF8String
   and contains the challenge (auth-param list) as defined in [8] and
   [9].

5.10 Authentication-Response AVP

   The Authentication-Response AVP (AVP code TBD) is of type UTF8String
   and contains the response (auth-param list) as defined in [8] and
   [9].

5.11 Authentication-Context AVP

   The Authentication-Context AVP (AVP code TBD) is of type
   OctectString, and contains authentication-related information
   relevant for performing the authentication but that is not part of
   the SIP authentication headers.



johansson et al.            expires July 2002                  [Page 24]


INTERNET DRAFT                                                  Jan 2002


   Some mechanisms (e.g. PGP, digest with quality of protection set to
   auth-int [RFC 2617], digest with predictive nonces [7] or sip access
   digest [8]) request that part or the whole SIP request is passed to
   the entity performing the authentication. In such cases the
   Authentication-Context AVP would be carrying such information.

   This AVP can be also needed for authorization purposes.

5.12 Number-Authentication-Items AVP

   The Number-Authentication-Items AVP (AVP Code TBD) is of type
   Unsigned32 and indicates the number of authentication vectors
   provided by the Diameter server.

   When used in request it indicates the number of Authentication-Data-
   Items the SSP is requesting. This can be used, for instance, when the
   SSP is requesting several pre-calculated authentication vectors. In
   the answer message the Number-Authentication-Items AVP indicates the
   actual number of items provided by the Diameter server. The Number-
   Authentication-Items AVP is only used if user authentication is made
   in the SSP.

5.13 Auth-Data-Item AVP

   The Auth-Data-Item (AVP code TDB) is of type Grouped, and contains
   the authentication and/or authorization information for the Diameter
   client.

    Auth-Data-Item :: = < AVP Header : TBD >
                        [ Item-Number ]
                        [ Authentication-Scheme ]
                        [ Authentication-Challenge ]
                        [ Authentication-Response ]
                        [ Authentication-Context ]
                        [ EAP-Payload ]
                      * [ NAS-Session-Key ]
                      * [ AVP ]

5.14 Item-Number AVP

    The Item-Number (AVP code TDB) is of type Unsigned32, and is
    included in a Authentication-Data-Item grouped AVP in circumstances
    where there are multiple occurrences of Authentication-Data-Item
    AVPs, and the order in which they should be processed is
    significant.  In this scenario, Authentication-Data-Item AVPs with a
    low Item-Number value (such as 1) should be processed before
    Authentication-Data-Items AVPs with a high Item-Number value (such
    as 13).



johansson et al.            expires July 2002                  [Page 25]


INTERNET DRAFT                                                  Jan 2002


5.15 User-Data AVP

   The User-Data AVP (AVP Code TBD) is of type FFS. This AVP contains
   the user profile data required to give service to a user.

5.16 NAS-Session-Key AVP

   The NAS-Session-Key AVP is defined in [3].

5.17 NAS-Key-Binding AVP

   The NAS-Key-Binding AVP is defined in [3].

5.18 Desired-User-Capabilities AVP

   The Desired-User-Capabilities AVP (AVP code TBD) is of type Grouped.
   This AVP MAY be used by the HSP to assist in the selection of a SSP.

    Desired-User-Capabilities ::= < AVP Header: TBD >
                                * [ SIP-Mandatory-Capability ]
                                * [ SIP-Optional-Capability ]
                                * [ SIP-Server-Name ]
                                * [ AVP ]

5.19 SIP-Mandatory-Capability AVP

   The SIP-Mandatory-Capability AVP (AVP Code TBD) is of type
   Unsigned32.  The value indicates a specific SIP capability required
   of a server in order to be considered for providing SIP services to a
   user.

5.20 SIP-Optional-Capability AVP

   The SIP-Optional-Capability AVP (AVP Code TBD) is of type Unsigned32.
   The value indicates a specific SIP capability which MAY be supported
   by a server in order to be considered for providing SIP services to a
   user.

5.21 Deregistration-Reason AVP

   The Deregistration-Reason AVP (AVP Code TBD) is of type UTF8String.
   The value indicates the reason for a deregistration operation.

5.22 EAP-Payload AVP

   The EAP-Payload AVP is defined in [3].





johansson et al.            expires July 2002                  [Page 26]


INTERNET DRAFT                                                  Jan 2002


6.0 References


[1]  Basilier, Calhoun, Holdrege, Johansson, Kempf, Rajaniemi, "AAA
     Requirements for IP Telephony/Multimedia", draft-calhoun-sip-aaa-
     reqs-03.txt, IETF work in progress, October 2001

[2]  Calhoun, Akhtar, Arkko, Guttman, Rubens, Zorn, "Diameter Base Pro¡
     tocol", draft-ietf-aaa-diameter-08.txt, IETF work in progress,
     November 2001

[3]  Calhoun, Bulley, Rubens, Haag, Zorn, "Diameter NASREQ Application",
     draft-ietf-aaa-diameter-nasreq-08.txt, IETF work in progress,
     November 2001

[4]  Calhoun, Perkins, "Diameter Mobile IPv4 Application," draft-ietf-
     diameter-mobileip-07.txt, IETF work in progress, November 2001.

[5]  M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Ses¡
     sion Initiation Protocol". RFC 2543, March 1999.

[6]  IETF RFC 2396: "Uniform Resource Identifiers (URI): generic syntax"

[7]  IETF RFC 2806: "URLs for Telephone Calls"

[8]  IETF RFC 2617: "HTTP Authentication: Basic and Digest Access
     Authentication"

[9]  V.Torvinen, J. Arkko, "HTTP Authentication with EAP", draft-ieft-
     torvinen-http-eap-00.txt, IETF work in progress, June 2001.





















johansson et al.            expires July 2002                  [Page 27]


INTERNET DRAFT                                                  Jan 2002


7.0  Authors' Addresses

   Questions about this memo can be directed to:


      Tony Johansson
      Ericsson Inc.
      2100 Shattuck Ave.
      Berkeley, Califonia, 94704
      USA

       Phone:  +1 510-305-6108
       Fax:  +1 510-666-3999
       E-mail:  tony.johansson@ericsson.com

      Kevin Purser
      Ericsson Inc.
      2100 Shattuck Ave.
      Berkeley, Califonia, 94704
      USA

       Phone:  +1 510-305-6100
       Fax:  +1 510-666-3999
       E-mail:  kevin.purser@ericsson.com

      Carolina Canales
      Ericsson Spain
      C/ Ombu, 3
      28045 Madrid
      Spain

       Phone:  +34 913392680
       Fax:    +34 913392538
       E-mail:  carolina.canales-valenzuela@ece.ericsson.se

      Miguel-Angel Pallares
      Ericsson Spain
      C/ Ombu, 3
      28045 Madrid
      Spain

       Phone:  +34 913394222
       Fax:    +34 913392538
       E-mail:  miguel-angel.pallares-lopez@ece.ericsson.se







johansson et al.            expires July 2002                  [Page 28]


INTERNET DRAFT                                                  Jan 2002


      Peter J. McCann
      Lucent Technologies
      Rm 2Z-305
      263 Shuman Blvd
      Naperville, IL  60566-7050
      USA

       Phone: +1 630 713 9359
       Fax: +1 630 713 4982
       E-Mail: mccap@lucent.com

      Jaakko Rajaniemi
      Nokia Networks
      P.O. Box 301
      00045 Nokia Group
      Finland

       Phone:  +358 50 3391387
       Fax:      +358 9 51130163
       E-mail: jaakko.rajaniemi@nokia.com


8.0  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this docu¡
   ment itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop¡
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English. The lim¡
   ited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns. This document
   and the information contained herein is provided on an "AS IS" basis
   and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS¡
   CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
   TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
   FITNESS FOR A PARTICULAR PURPOSE.





johansson et al.            expires July 2002                  [Page 29]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/