[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [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-01.txt> Miguel-Angel Pallares
Ericsson
Peter J. McCann
Lucent
Jaakko Rajaniemi
Nokia
Feb 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 August 2002 [Page 1]
INTERNET DRAFT Feb 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 August 2002 [Page 2]
INTERNET DRAFT Feb 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
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 Authentication Details
5.0 Result Code AVP values
5.1 Success
5.2 Permanent failures
6.0 Diameter AVP values
6.1 SIP-Server AVP
6.2 SIP-Server-Name AVP
6.3 SIP-Capability AVP
6.4 SIP-Public-Identity AVP
6.5 SIP-Visited-Network-Identifier AVP
6.6 SIP-Profile-Update-Type AVP
6.7 SIP-Server-Type AVP
6.8 SIP-Authentication-Scheme AVP
6.9 SIP-Authenticate AVP
6.10 SIP-Authorization AVP
6.11 SIP-Authentication-Context AVP
6.12 SIP-Number-Auth-Items AVP
6.13 SIP-Auth-Data-Item AVP
6.14 SIP-Item-Number AVP
6.15 SIP-User-Data AVP
6.16 NAS-Session-Key AVP
6.17 NAS-Key-Binding AVP
6.18 SIP-User-Service-Info AVP
6.19 SIP-Deregistration-Reason AVP
6.20 SIP-Capability AVP
6.21 SIP-Version-Number AVP
6.22 SIP-Vendor-ID AVP
johansson et al. expires August 2002 [Page 3]
INTERNET DRAFT Feb 2002
6.23 SIP-Optional-Parameter AVP
6.24 SIP-Capability-Type AVP
6.25 SIP-Reason AVP
6.26 SIP-Server-Behavior AVP
7.0 References
8.0 Authors' Addresses
9.0 Full Copyright Statement
johansson et al. expires August 2002 [Page 4]
INTERNET DRAFT Feb 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 August 2002 [Page 5]
INTERNET DRAFT Feb 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 August 2002 [Page 6]
INTERNET DRAFT Feb 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 August 2002 [Page 7]
INTERNET DRAFT Feb 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 August 2002 [Page 8]
INTERNET DRAFT Feb 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 use 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 August 2002 [Page 9]
INTERNET DRAFT Feb 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 August 2002 [Page 10]
INTERNET DRAFT Feb 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 August 2002 [Page 11]
INTERNET DRAFT Feb 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.
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.
johansson et al. expires August 2002 [Page 12]
INTERNET DRAFT Feb 2002
+-------+ +-------+ +-------+
| 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 August 2002 [Page 13]
INTERNET DRAFT Feb 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 SIP-User-Data AVP, a User-Name AVP, and zero or more SIP-Public-
Identity AVPs. The presence of the User-Name AVP without any SIP-
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 SIP-Public-Identity AVPs serves to
indicate that the user profile data associated with each of the SIP-
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 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
initiated SIP de-registration, or a AAA-initiated de-registration as
a result of administrative reasons.
johansson et al. expires August 2002 [Page 14]
INTERNET DRAFT Feb 2002
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 }
{ SIP-Server }
[ SIP-Public-Identity ]
[ SIP-Visited-Network-Identifier
]
[ 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 SIP-User-Service-Info and SIP-Server AVPs to convey
information needed by the HSP to select an appropriate SSP.
If the user has already been authorized and a server has already been
assigned which is still valid for the user's service profile, the
johansson et al. expires August 2002 [Page 15]
INTERNET DRAFT Feb 2002
SIP-Server AVP MUST be present which contains the SIP URL of the
currently assigned server, so that the HSP can forward the
registration request to it.
If the user has already been authorized, and a server has already
been assigned which may not be valid for the user's service profile,
two pieces of information must be returned to allow the HSP to decide
what action to take. First, the SIP-Server AVP MUST be present which
contains the SIP URL of the currently assigned server. Second, the
SIP-User-Service-Info AVP MUST present which contains information to
allow the HSP to select an appropriate SIP server.
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 ]
[ SIP-User-Service-Info ]
* [ SIP-Server ]
* [ 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.
Message Format
johansson et al. expires August 2002 [Page 16]
INTERNET DRAFT Feb 2002
< Multimedia-Auth-Request > ::= < Diameter Header: TBD, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ SIP-Server }
[ User-Name ]
[ SIP-Public-Identity ]
[ SIP-Number-Auth-Items ]
[ SIP-Auth-Data-Item ]
[ 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 August 2002 [Page 17]
INTERNET DRAFT Feb 2002
Message Format
< Multimedia-Auth-Answer > ::= < Diameter Header: TBD, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ SIP-User-Data ]
[ User-Name ]
[ Accounting-Multi-Session-Id ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ SIP-Server ]
[ SIP-Number-Auth-Items ]
* [ SIP-Auth-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 August 2002 [Page 18]
INTERNET DRAFT Feb 2002
< Profile-Update-Request > ::= < Diameter Header: TBD, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ SIP-Profile-Update-Type }
[ Destination-Host ]
[ User-Name ]
[ SIP-User-Data ]
[ SIP-Server ]
[ SIP-Deregistration-Reason ]
* [ SIP-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 }
[ SIP-User-Data ]
[ User-Name ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
johansson et al. expires August 2002 [Page 19]
INTERNET DRAFT Feb 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 }
{ SIP-Server }
[ Destination-Host ]
[ User-Name ]
[ SIP-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 August 2002 [Page 20]
INTERNET DRAFT Feb 2002
< Location-Info-Answer > ::= < Diameter Header: TBD, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ SIP-User-Service-Info ]
* [ SIP-Server ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
4.0 Authentication Details
Authenticating a mobile user can occur through various mechansims
(http basic or digest authentication have currently been prescribed),
with the actual authentication being performed in either the SIP
server or the AAA server. The choice of which server will determine
which AVPs will be utilized in the SIP-Auth-Data-Item grouped AVP, as
well as a few AVPs in the MAR/MAA.
In the event that the SIP server performs the authentication of a
mobile user, the MAR from the SIP server to the AAA server will
include the User-Name and SIP-Public-Identity AVPs as necessary, as
well a SIP-Number-Auth-Items AVP to indicate how many authentication
vectors (the actual contents of the vector are dependent upon the
authentication method) are being requested. In the MAA, the AAA
server SHOULD indicate how many SIP-Auth-Data-Item AVPs are present
with the Number-Auth-Items AVP, and may be different from the amount
requested in the MAR. If multiple SIP-Auth-Data-Item AVPs are
present, and their ordering is significant, the Item-Number MUST be
included in each grouping. The Authentication-Scheme and SIP-
Authenticate AVPs will contain data (typically a challenge of some
kind) to be used by the mobile user to authenticate itself. The SIP-
Authorization AVP will contain the response which is expected from
the user. In order to support some auth methods which combine key
distribution with authentication, NAS-Session-Key AVPs may be
included in the event they were requested by including "SIP crypto
node" as one of the Server-Type AVPs in the MAR.
In the event that the AAA server performs the authentication of a
mobile user, the MAR from the SIP server will include a single SIP-
Auth-Data-Item AVP. The SIP-Authentication-Scheme and SIP-
johansson et al. expires August 2002 [Page 21]
INTERNET DRAFT Feb 2002
Authorization AVPs will contain the relevant parameters from the SIP
message if present, and if necessary, the SIP-Authentication-Context
AVP will contain any additional information needed to perform the
authentication. If the authentication is successful, the MAA will
contain a result code indicating success, and if necessary, the SIP-
Auth-Data-Item AVP may be included to carry session keys back to the
SIP server. If the authentication is unsuccessful due to missing
credentials, the MAA will include an SIP-Auth-Data-Item with the SIP-
Authentication-Scheme and SIP-Authenticate AVPs containing data
(typically a challenge of some kind) to be used by the mobile user to
authenticate itself.
5.0 Result Code AVP values
This section defines new Result codes in addition to the values
defined in [2].
5.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_SEPARATE_REGISTRATION 2xxx
The user has been previously registered, but with a different
public identifier (and associated service profile). The identity
of the SSP to which the user is currently registered MUST be
included in the message, and in the event a new SSP must be
assigned (based on the new service profile), information necessary
to select an appropriate SSP MUST be included in the message as
well.
DIAMETER_UNREGISTERED_SERVICE 2xxx
The user is not currently registered, but the requested service
can still be granted to the user.
5.2 Permanent failures
johansson et al. expires August 2002 [Page 22]
INTERNET DRAFT Feb 2002
Errors that fall within the permanent failures category are used to
inform the peer that the request failed, and should not be attempted
again.
DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5xxx
This error code is used to indicate that there is no multimedia
roaming agreement between the home and visited networks.
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.
6.0 Diameter AVP values
The following sections define the AVPs used in this diameter
application.
6.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-Type ]
* [ SIP-Capability ]
* [ AVP ]
6.2 SIP-Server-Name AVP
The SIP-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 SIP-Server-Name AVP to inform the Diameter
server which SSP to use for the SIP user or the SIP-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.
johansson et al. expires August 2002 [Page 23]
INTERNET DRAFT Feb 2002
6.3 SIP-Capability AVP
The SIP-Capability AVP (AVP Code TBD) is of type Grouped. This AVP
is used to indicate support for particular SIP capability.
SIP-Capability ::= < AVP Header: TBD >
{ SIP-Capability }
{ SIP-Capability-Type }
[ Vendor-ID ]
[ SIP-Version-Number ]
* [ SIP-Optional-Parameter ]
* [ AVP ]
A Vendor-ID value of 0, or the absence of a Vendor-ID AVP implies
that the value indicated by the SIP-Capability AVP has been assigned
by IANA to represent a non-vendor specific capability. Otherwise,
the value indicated by the SIP-Capability AVP is defined entirely by
the vendor/operator.
6.4 SIP-Public-Identity AVP
The SIP-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 SIP-Public-Identity AVP.
6.5 SIP-Visited-Network-Identifier AVP
The SIP-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).
6.6 SIP-Profile-Update-Type AVP
The SIP-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
johansson et al. expires August 2002 [Page 24]
INTERNET DRAFT Feb 2002
USER_DEREGISTRATION 5
AUTHENTICATION_FAILURE 6
UPDATE_PROFILE 7
RETRIEVE_PROFILE 8
ADMINISTRATIVE_DEREGISTRATION 9
6.7 SIP-Server-Type AVP
The SIP-Server-Type AVP (AVP Code TBD) is of type Enumerated, and the
value is used to identify a particular type of SIP server. The
following values have currently been defined.
Stateless proxy 0
This SIP server is a stateless proxy (e.g., HSP), and is only
interested in routing the SIP method to the proper SSP. It will
not participate in authentication, but may also use e.g., 4 below.
Registrar 1
This SIP server is a registrar (e.g., SSP or in some cases HSP).
It wants to run authentication, but will use the AAA server to
check authenticated results (no secrets given to SSP).
Authenticating registrar 2
This SIP server is a registrar, and wants to run authentication,
including performing the check of authenticated results itself
(values such as challenges and expected responses are given to the
SSP).
SIP hub 3
This SIP server wants to download a set of filter criteria/AS
names for subsequent routing of INVITEs and other messages.
SIP crypto node 4
This SIP server wants access to NAS-Session-Key data so that it
can verify/decrypt subsequent SIP messages.
6.8 SIP-Authentication-Scheme AVP
The SIP-Authentication-Scheme AVP (AVP code TBD) is of type
UTF8String and indicates the authentication scheme used in the
authentication of SIP messages. Current values are "Basic" and
"Digest", defined in [8].
6.9 SIP-Authenticate AVP
The SIP-Authenticate AVP (AVP code TBD) is of type UTF8String and
contains the data portion of the WWW-Authenticate or Proxy-
Authenticate SIP headers if present in a SIP response.
johansson et al. expires August 2002 [Page 25]
INTERNET DRAFT Feb 2002
6.10 SIP-Authorization AVP
The SIP-Authorization AVP (AVP code TBD) is of type UTF8String and
contains the data portion of the Authorization or Proxy-Authorization
SIP headers if present in a SIP request.
6.11 SIP-Authentication-Context AVP
The SIP-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.
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 SIP-
Authentication-Context AVP would be carrying such information.
6.12 SIP-Number-Auth-Items AVP
The SIP-Number-Auth-Items AVP (AVP Code TBD) is of type Unsigned32
and indicates the number of authentication and/or authorization
vectors provided by the Diameter server.
When used in a request, it indicates the number of SIP-Auth-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 SIP-Number-Auth-Items AVP indicates the actual
number of items provided by the Diameter server.
6.13 SIP-Auth-Data-Item AVP
The SIP-Auth-Data-Item (AVP code TDB) is of type Grouped, and
contains the authentication and/or authorization information for the
Diameter client.
SIP-Auth-Data-Item :: = < AVP Header : TBD >
[ SIP-Item-Number ]
[ SIP-Authentication-Scheme ]
[ SIP-Authenticate ]
[ SIP-Authorization ]
[ SIP-Authentication-Context ]
* [ NAS-Session-Key ]
* [ AVP ]
6.14 SIP-Item-Number AVP
johansson et al. expires August 2002 [Page 26]
INTERNET DRAFT Feb 2002
The SIP-Item-Number (AVP code TDB) is of type Unsigned32, and is
included in a SIP-Auth-Data-Item grouped AVP in circumstances where
there are multiple occurrences of SIP-Auth-Data-Item AVPs, and the
order in which they should be processed is significant. In this
scenario, SIP-Auth-Data-Item AVPs with a low SIP-Item-Number value
(such as 1) should be processed before SIP-Auth-Data-Items AVPs with
a high SIP-Item-Number value (such as 13).
6.15 SIP-User-Data AVP
The SIP-User-Data AVP (AVP Code TBD) is of type OctetString, and MUST
NOT be interpreted by the Diameter protocol. This AVP contains the
user profile data required for a SIP server to give service to a
user.
6.16 NAS-Session-Key AVP
The NAS-Session-Key AVP is defined in [3].
6.17 NAS-Key-Binding AVP
The NAS-Key-Binding AVP is defined in [3].
6.18 SIP-User-Service-Info AVP
The SIP-User-Service-Info AVP (AVP code TBD) is of type Grouped.
This AVP is used to communicate two different types of information.
First, a list of capabilities that are either required or preferable
in order for a SIP server to grant service to a user. Second, a list
of default servers (indicated in the user's service profile) which
may be used to service the user. An HSP will be able to select an
appropriate SSP with these two lists of information.
Message format
SIP-User-Service-Info ::= < AVP Header: TBD >
* [ SIP-Capability ]
* [ SIP-Server-Name ]
* [ AVP ]
6.19 SIP-Deregistration-Reason AVP
The SIP-Deregistration-Reason AVP (AVP Code TBD) is of type Grouped,
and indicates the reason for a deregistration operation.
johansson et al. expires August 2002 [Page 27]
INTERNET DRAFT Feb 2002
Message format
SIP-Deregistration-Reason::= < AVP Header: TBD >
* [ SIP-Reason ]
* [ SIP-Server-Behavior ]
* [ AVP ]
6.20 SIP-Capability AVP
The SIP-Capability AVP (AVP Code TBD) is of type Unsigned32, and is
used to represent a particular capability of a SIP server.
6.21 SIP-Version-Number AVP
The SIP-Version-Number AVP (AVP Code TBD) is of type Unsigned32.
This AVP is used within a SIP-Capability AVP, and indicates support
for a particular version of the capability indicated within the same
SIP-Capability AVP.
6.22 Vendor-ID AVP
The Vendor-ID AVP is defined in [2].
6.23 SIP-Optional-Parameter AVP
The SIP-Optional-Parameter AVP (AVP Code TBD) is of type OctetString.
The value included in this AVP MUST not be interpreted by the
Diameter protocol, and is simply passed as opaque data to SIP
servers.
6.24 SIP-Capability-Type AVP
The SIP-Capability-Type AVP (AVP Code TBD) is of type Enumerated, and
specifies the type of capability. The following values are defined.
MANDATORY 1
The capability MUST be supported by a server in order to be
considered for providing SIP services to a user
OPTIONAL 2
This capability MAY be supported by a server in order to be
considered for providing SIP services to a user
INFORMATIONAL 3
This capability is supported by a SIP server
6.25 SIP-Reason AVP
johansson et al. expires August 2002 [Page 28]
INTERNET DRAFT Feb 2002
The SIP-Reason AVP (AVP code TBD) is of type UTF8String, and contains
textual information to inform the user about the reason for a de-
registration.
6.26 SIP-Server-Behavior AVP
The SIP-Server-Behaviour AVP (AVP code TBD) is of type Enumerated,
and defines the reason for the network initiated de-registration. The
following values are defined:
PERMANENT_TERMINATION 0
The IMS subscription or service profile(s) has been permanently
terminated. The SSP should start the network initiated de-
registration towards the user.
NEW_SERVER_ASSIGNED 1
A new SSP has been allocated to the user due to some reason, e.g.
an error case, where the SIP registration is terminated in a new
SSP. The SSP shall not start the network initiated de-
registration towards the user but only clears its registration
state and information regarding the user, i.e. all service
profiles are cleared.
7.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"
johansson et al. expires August 2002 [Page 29]
INTERNET DRAFT Feb 2002
[8] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access
Authentication"
8.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 August 2002 [Page 30]
INTERNET DRAFT Feb 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
9.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 August 2002 [Page 31]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/