Network Working Group Maria-Carmen Belinchon
INTERNET-DRAFT Miguel-Angel Pallares
Category: Standards Track Carolina Canales
Expires: August 2003 Miguel Garcia
Ericsson
Peter J. McCann
Lucent
Jaakko Rajaniemi
Kalle Tammi
Nokia
February, 2003
Diameter Multimedia Application
<draft-belinchon-aaa-diameter-mm-app-00.txt>
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This document specifies a Diameter application that supports the
authentication, authorization, and collection of 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
Belinchon et all [Page 1]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
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 the
client node to be authenticated for access with the use of either the
Mobile IP [3] or NASREQ [11] Diameter application.
TABLE OF CONTENTS
1. Introduction.....................................................3
1.1 Requirements language...........................................4
1.2 Advertising Application Support.................................4
1.3 Definitions.....................................................5
2. Description of a SIP network architecture........................5
2.1 User authentication by SSP......................................6
2.2 User authentication by AAA server...............................8
2.3 Invitation......................................................9
2.4 User Profile Updating..........................................10
2.5 User registration termination..................................10
3 Multimedia messages.............................................11
3.1 User-Authorization-Request (UAR) Command.......................11
3.2 User-Authorization-Answer (UAA) Command........................12
3.3 Server-Assignment-Request (SAR) Command........................14
3.4 Server-Assignment-Answer (SAA) Command.........................15
3.5 Location-Info-Request (LIR) Command............................17
3.6 Location-Info-Answer (LIA) Command.............................17
3.7 Multimedia-Auth-Request (MAR) Command..........................18
3.8 Multimedia-Auth-Answer (MAA) Command...........................19
3.9 Registration-Termination-Request (RTR) Command.................21
3.10 Registration-Termination-Answer (RTA) Command.................21
3.11 Push-Profile-Request (PPR) Command............................22
3.12 Push-Profile-Answer (PPA) Command.............................23
4 Result Code AVP values...........................................24
4.1 Success........................................................24
4.2 Permanent failures.............................................24
5 Diameter AVP values..............................................25
5.1 Charging-Information AVP.......................................27
5.1.1 Primary-Event-Charging-Function-Name AVP.....................27
5.1.2 Secondary -Event-Charging-Function-Name AVP..................27
5.1.3 Primary-Charging-Collection-Function-Name AVP................27
5.1.4 Secondary -Charging-Collection-Function-Name AVP.............27
5.4 Server-Name AVP................................................27
5.5 Server-Capability AVP..........................................28
5.5.1 Mandatory-Capability AVP.....................................28
5.5.2 Optional-Capability AVP......................................28
Belinchon et all [Page 2]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
5.6 Server-Assignment-Type AVP.....................................28
5.7 SIP-Auth-Data-Item AVP.........................................29
5.7.1 SIP-Item-Number AVP..........................................30
5.7.2 SIP-Authentication-Scheme AVP................................30
5.7.3 SIP-Authenticate AVP.........................................30
5.7.4 SIP-Authorization AVP........................................30
5.7.5 SIP-Authentication-Info AVP..................................30
5.7.6 SIP-Authentication-Context AVP...............................30
5.7.7 Confidentiality-Key AVP......................................31
5.7.8 Integrity-Key AVP............................................31
5.8 SIP-Number-Auth-Items AVP......................................31
5.9 Deregistration-Reason AVP......................................31
5.9.1 Reason-Code AVP..............................................31
5.9.2 Reason-Info AVP..............................................31
5.10 Public-Identity AVP...........................................32
5.11 Visited-Network-Identifier AVP................................32
5.12 User-Authorization-Type AVP...................................32
5.13 User-Data AVP.................................................32
5.14 User-Data-Already-Available AVP...............................33
5.15 User-Data-Request-Type AVP....................................33
6. Authentication Details..........................................33
7. IANA Considerations.............................................34
8 Acknowledgements.................................................34
9 References.......................................................34
9.1 Normative References...........................................34
9.2 Non-Normative References.......................................35
10 Authors' Addresses..............................................35
11. Full Copyright Statement.......................................36
1. Introduction
This document specifies a Diameter application that supports the
authentication, authorization and collection of 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
Belinchon et all [Page 3]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
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) or at any
other moment agreed by the entities involved in the authentication
(e.g., at SIP session initiation). 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 the WWW-Authenticate methods Basic
and Digest, which are supported by 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.
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 2. Sections 3, 4 and 5 address the Diameter Multimedia
Application's specific commands, result codes, and AVPs,
respectively. Section 7 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 [10].
1.2 Advertising Application Support
Diameter nodes conforming to this specification MAY advertise support
by including the Auth-Application-Id AVP in the Capabilities-
Exchange-Request and Capabilities-Exchange-Answer commands [BASE].
Belinchon et all [Page 4]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
1.3 Definitions
Further clarification of these definitions can be found in ref [10].
Implicit registration: Mechanism that supports for multimedia the
registration of a set of public identities belonging to the same
group by the registration of only one of the identities.
Non-Registered identity: Public multimedia identity that is not
registered and for which no data are stored in the network nodes.
Registered identity: Public multimedia identity that is registered
and therefore the concerned user profile is stored both in the AAA
and the SSP.
Unregistered identity: Public multimedia identity that is not
registered but whose profile is stored either in the AAA server or in
the SSP as a consequence of previous registrations or a call in
course.
2. Description of a SIP network architecture
Home Realm
+-------+
UAR/UAA +-->| AAA |<--+ PPR/PPA
LIR/LIA | |xyz.com| | MAR/MAA
| | | | SAR/SAA
| +-------+ | RTR/RTA
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, according to the requirements in [1] and [10].
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
Belinchon et all [Page 5]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
(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
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 the SSP authentication mode.
+-------+ +-------+ +-------+
| 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 | | |
Belinchon et all [Page 6]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
---------->| 10. UAR | |
+------------------>| |
| 11. UAA | |
|<------------------+ |
| | 12. SIP-REG |
+-------------------------------------->|
| | 13. SAR |
| |<------------------+
| | 14. SAA |
| +------------------>|
| 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 a "User-Authorization-Answer" (UAA), which will inform
about the result of the user authorization. In case of a successful
authorization, the UAA will indicate either the identity of a local
SIP server or a list of capabilities from which the HSP will select
the appropriate SSP.
When successful authorization, the HSP will forward the registration
request 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 of
the same user 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 his/her identity.
When the subsequent SIP registration is received from the user, the
HSP (assumed to be stateless) 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. The SSP node performed the authentication in the previous
registration request by means of MAR/MAA, so at this point it is not
necessary to ask for it again. Instead, the SSP will contact the AAA
server by means of a Server-Assignment-Request (SAR) requesting it to
store the name of the server that is currently serving the user and
the concerned user profile.
Belinchon et all [Page 7]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
The AAA server will respond with a "Server-Assignment-Answer" (SAA).
If the Result-Code does not inform about an error, the User-Data AVP
shall contain the information that the SSP needs to give service to
the user.
The SSP will produce then a 200 (OK) message, and send it to the HSP.
The HSP will then forward the 200 (OK) message towards 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.
+-------+ +-------+ +-------+
| 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 |<--------------------------------------+
<-----------+ | |
| | |
Belinchon et all [Page 8]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
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
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.
2.3 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 | |
Belinchon et all [Page 9]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
|<------------------+ |
| | 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 MaryÆs 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.
2.4 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. PPR |
+------------------>|
| |
| 2. PPA |
|<------------------+
| |
Figure 6. User profile update initiated by AAA server
The AAA server sends a Push-Profile-Request (PPR) to the serving SIP
server to which the user is registered. The PPR message contains a
User-Data AVP with the updated user profile.
2.5 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 Session-
Termination-Request (if it is initiated by the SSP/HSP) or with a
Registration-Termination-Request (if it is initiated by the AAA).
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.
Belinchon et all [Page 10]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
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.
3 Multimedia messages
This section defines new Diameter message Command-Code [8] values
that MUST be supported by all Diameter implementations that conform
to this specification. The Command Codes (assigned by IANA in ref
[8]) are:
Command-Name Abbrev. Code Reference
------------------------------------------------------------------
User-Authorization-Request UAR 300 3.1
User-Authorization-Answer UAA 300 3.2
Server-Assignment-Request SAR 301 3.3
Server-Assignment-Answer SAA 301 3.4
Location-Info-Request LIR 302 3.5
Location-Info-Answer LIA 302 3.6
Multimedia-Auth-Request MAR 303 3.7
Multimedia-Auth-Answer MAA 303 3.8
Registration-Termination-Request RTR 304 3.9
Registration-Termination-Answer RTA 304 3.10
Push-Profile-Request PPR 305 3.11
Push-Profile-Answer PPA 305 3.12
3.1 User-Authorization-Request (UAR) Command
The User-Authorization-Request (UAR), indicated by the Command-Code
field set to 300 and the 'R' bit set in the Command Flags field, is
sent by an HSP node, acting as a Diameter client, to a AAA server in
order to request authorization of a mobile user.
The HSP asks for authorization of the REGISTRATION, DE-REGISTRATION
or REGISTRATION&CAPABILITIES procedure to the AAA server. For the
exact meaning of these values, see User-Authorization-Type AVP
(chapter 5.12).
According to [10], a user is defined in the multimedia system by one
private identity and one or more public identities. Both of them are
checked in the registration process.
The HSP extracts the private identity from the SIP Authorization:
header and includes it in the UAR message within the User-Name AVP.
The HSP extracts the public identity from the SIP From: header and
includes it in the UAR message within the Public-Identity AVP.
Belinchon et all [Page 11]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
Message Format
< User-Authorization-Request > ::= Diameter Header: 300: REQ, PXY >
< Session-ID >
< Auth-Application-Id >
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Name }
{ Public-Identity }
{ Visited-Network-Identifier }
[ User-Authorization-Type ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
3.2 User-Authorization-Answer (UAA) Command
The User-Authorization-Answer (UAA), indicated by the Command-Code
field set to 300 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 in addition to the values already defined in [2]. Whenever
a failure is encountered, the AAA will stop processing and return the
concerned error. When no error code is specified, the AAA will set
the code to DIAMETER_SUCCESS.
When the authorization procedure succeeds, the AAA server sends back
to the HSP the name of an already assigned SSP or the capabilities
needed by the HSP to select the appropriate SSP. The UAA message will
carry one information or the other based on the received User-
Authorization-Type AVP value and the public identity.
At reception of the UAR message, the AAA server MUST check the
existence of the user (i.e., the private identity is defined). If the
server does not recognized the user private identity received in the
User-Name AVP, the DIAMETER_ERROR_USER_UNKNOWN code will be sent back
to the HSP. Otherwise the AAA will check that this private identity
matches with the public identity received in the Public-Identity AVP.
If there is no match, the AAA server will send back to the HSP the
DIAMETER_ERROR_IDENTITIES_DONT_MATCH code.
If no error occurred, the AAA server MUST check that the user is
allowed to roam in the visited network and is authorized to register.
This is performed only if the received User-Authorization-Type AVP
value is equal to REGISTRATION or REGISTRATION&CAPABILITIES. In case
of failure, the AAA server will send back to the HSP the
Belinchon et all [Page 12]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
DIAMETER_ERROR_ROAMING_NOT_ALLOWED or DIAMETER_AUTHORIZATION_REJECTED
code.
In the case that the requested authorization type was
REGISTRATION&CAPABILITIES, the AAA will send back the needed
capabilities for the HSP to select an appropriate SSP. The UAA will
make use of the Server-Capabilities AVP to convey this information.
In the case that the authorization type was REGISTRATION:
- If the user (i.e., that public identity or other implicitly
registered identity) has been already authorized (registered), the
Result-Code AVP is set to DIAMETER_SUBSEQUENT_REGISTRATION and the
UAA will make use of the Server-Name AVP to contain the SIP URL of
the currently assigned server
- If the user is unregistered, i.e. there is no any registered
identity but at least one identity is unregistered, a server is
already assigned for that user, the Result-Code AVP is set to
DIAMETER_SUBSEQUENT_REGISTRATION if the AAA knows that no server
needs to be re-assigned, and the UAA will make use of the Server-
Name AVP to contain the SIP URL of the currently assigned server.
Otherwise, the Result-Code AVP is set to DIAMETER_SERVER_SELECTION
and either the capabilities and the already assigned server name is
sent back to let the HSP to decide whether or not selecting a new
server.
- If the user is unregistered, i.e. there is no registered or
unregistered identity, the Result-Code AVP is set to
DIAMETER_FIRST_REGISTRATION and the UAA will make use of the
Server-Capabilities AVP to convey the information needed by the HSP
to select an appropriate SSP.
In the case that the authorization type was DE-REGISTRATION:
- If the user (i.e., that public identity or other implicitly
registered identity) has been already authorized (registered), the
Result-Code AVP is set to DIAMETER_SUCESS and the AAA removes the
information for that identity (or set of identities when they are
implicitly registered).
- If the user is unregistered, i.e. there is no any registered
identity but at least one identity is unregistered, a server is
already assigned for that user, so the Result-Code AVP is set to
DIAMETER_SUCESS and the AAA removes the information for that
identity (or set of identities when they are implicitly
registered).
- If the user is unregistered, i.e. there is no registered or
unregistered identity, the Result-Code AVP is set to
DIAMETER_ERROR_IDENTITY_NOT_REGISTERED.
Belinchon et all [Page 13]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
Message Format
< User-Authorization-Answer > ::= < Diameter Header: 300: PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
[ Result-Code ]
{ Origin-Host }
{ Origin-Realm }
[ Server-Name ]
[ Server-Capabilities ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
3.3 Server-Assignment-Request (SAR) Command
The Server-Assignment-Request (SAR) command, indicated by the
Command-Code field set to 301 and the 'R' bit set in the Command
Flags field, is sent by a Diameter Multimedia client to a Diameter
Multimedia server to request it to store the name of the server that
is currently serving the user.
Upon registration procedure, once the user authentication has been
performed, the SSP MUST inform the AAA server that he is the SSP
serving that user, and at the same time the SSP requests for the user
profile. This is done by means if SAR/SAA commands.
The SAR/SAA exchange also occurs when an INVITE SIP message is
received in the HSP and therefore the SSP is selected for the
communication.
For other cases where the SAR/SAA procedure is performed, see chapter
5.6 (Server-Assignment-Type AVP).
When requesting the user profile, the SSP can request the whole user
profile, just the information related to the registered public
identities, or the information related to the unregistered (but still
in use) identities. This is accomplished by the concerned value in
the User-Data-Request-Type and User-Data-Already-Available AVPs.
Message Format
<Server-Assignment-Request> ::= < Diameter Header: 301, REQ, PXY>
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
Belinchon et all [Page 14]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
[ Destination-Host ]
{ Destination-Realm }
[ User-Name ]
*[ Public-Identity ]
[ Server-Name ]
{ Server-Assignment-Type }
{ User-Data-Request-Type }
{ User-Data-Already-Available}
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
3.4 Server-Assignment-Answer (SAA) Command
The Server-Assignment-Answer (SAA) command, indicated by the Command-
Code field set to 301 and the 'R' bit cleared in the Command Flags
field, is sent by a server in response to the Server-Assignment-
Request command. The Result-Code AVP may contain one of the values
defined in section 4 in addition to the values already defined in
[2]. If Result-Code does not inform about an error, the User-Data AVP
shall contain the information that the SSP needs to give service to
the user.
At reception of the SAR, the AAA MUST check first that the user
exists (i.e., the private identity is defined). If the server does
not recognized the user private identity received in the User-Name
AVP, the DIAMETER_ERROR_USER_UNKNOWN code will be sent back to the
HSP. Otherwise the AAA will check that this private identity matches
with the public identity received in the Public-Identity AVP. If
there is no match, the AAA server will send back to the HSP the
DIAMETER_ERROR_IDENTITIES_DONT_MATCH code.
If the SSP contacted the AAA to perform a REGISTRATION or
RE_REGISTRATION (Server Assignment Type AVP) procedure, the AAA shall
download the relevant user public identity information to the SSP and
the Result-Code shall be set to DIAMETER_SUCCESS. At this point, the
identity is considered authenticated and registered. Only one
identity can be present in the request. If more than one identity is
present, the Result-Code shall be set to
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and no user information shall be
returned.
If the SSP contacted the AAA due to UNREGISTERED_USER, the AAA shall
store the SSP name, download the relevant user public identity
information and the Result-Code shall be set to DIAMETER_SUCCESS. At
this point, the identity is considered unregistered. Only one
identity can be present in the request. If more than one identity is
present, the Result-Code shall be set to
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and no modifications shall be
performed.
Belinchon et all [Page 15]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
If the SSP contacted the AAA due to TIMEOUT_DEREGISTRATION,
USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or
ADMINISTRATIVE_DEREGISTRATION, the AAA shall clear the SSP name for
all the public identities that the SSP indicated in the request. If
no public identity is present in the request, the private identity
MUST be present; the AAA shall clear the SSP name for all the
identities of the user. At this point, the identities are considered
not registered. The Result-Code shall be set to DIAMETER_SUCCESS.
If the SSP contacted the AAA due to
TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or
USER_DEREGISTRATION_STORE_SERVER_NAME, the AAA decides whether to
keep the stored SSP name or not for all the public identities that
the SSP indicated in the request. If no public identity is present in
the request, the private identity MUST be present and the previous
decision applies to all the user public identities. At this point,
the identities are considered unregistered. If the AAA decides to
keep the SSP name the Result-Code shall be set to DIAMETER_SUCCESS,
otherwise shall be set to DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED.
If the SSP contacted the AAA due to NO_ASSIGNMENT, the AAA checks
whether the user is assigned for the SSP requesting the data and
downloads the user public identity information requested in the User-
Data-Request-Type AVP. The Result-Code shall be set to
DIAMETER_SUCCESS. If the requesting SSP is not the same as the
assigned SSP, the Result-Code shall be set to DIAMETER_UNABLE_TO
COMPLY.
If the SSP contacted the AAA due to AUTHENTICATION_FAILURE or
AUTHENTICATION_TIMEOUT, the AAA shall clear the SSP name for the
public identity that the SSP indicated in the request and the Result-
Code shall be set to DIAMETER_SUCCESS. At this point, the identity is
considered unregistered. Only one identity can be present in the
request. If more than one identity is present the Result-Code shall
be set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and no modifications
shall be performed.
See chapter 4.2 for the description on the behavior of the AAA when
the name of the SSP received in the request is different from the
name already stored in the AAA.
Message Format
<Server-Assignment-Answer> ::= < Diameter Header: 301: PXY >
< Session-Id >
{ Auth-Application-Id }
[ Result-Code ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ User-Data ]
Belinchon et all [Page 16]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
[ Charging-Information ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
3.5 Location-Info-Request (LIR) Command
The Location-Info-Request (LIR), indicated by the Command-Code field
set to 302 and the 'R' bit set in the Command Flags field, is sent by
an 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.
The HSP queries the AAA server to get the SSP in which the user was
registered. The user registration is identified by the public
identity.
Message Format
< Location-Info-Request > ::= < Diameter Header: 302, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ Public-Identity }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
3.6 Location-Info-Answer (LIA) Command
The Location-Info-Answer (LIA), indicated by the Command-Code field
set to 302 and the 'R' bit cleared in the Command Flags field, is
sent by a Diameter server in response to a Location-Info-Request.
At reception of the LIR command, the AAA server will send back to the
HSP either the SIP server currently associated with the user or the
needed capabilities for the HSP to select an appropriate SSP.
The Result-Code AVP may contain one of the values defined in section
4 in addition to the values already defined in [2]. The AAA shall
stop processing and return the corresponding error code when a
failure is encountered. Otherwise, DIAMETER_SUCCESS Result-Code AVP
is returned.
Belinchon et all [Page 17]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
At reception of the LIR, the AAA MUST check first that the user
exists (i.e., the public identity is defined). If the server does not
recognized the user public identity received in the Public-Identity
AVP, the DIAMETER_ERROR_USER_UNKNOWN code will be sent back to the
HSP.
Otherwise the registration status of the public identity received in
the request is checked.
If it is registered or unregistered, the AAA shall return the stored
SSP name within the Server-Name AVP and the Result-Code AVP shall be
set to DIAMETER_SUCCESS.
If it is not registered, but has services related to unregistered
state, the AAA may return information about the required SSP
capabilities, which enables the HSP to select an SSP. In this case,
the Server-Capabilities AVP will be present and with the same
information that is sent in the UAR message during the registration.
If Server-Capabilities AVP is not present, the HSP will understand
that any SSP is suitable to serve the user. The Server-Name AVP will
not be present and the Vendor-Specific-Result will be set to
DIAMETER_UNREGISTERED_SERVICE.
If it is not registered and has no unregistered services related
data, the response shall contain the Result-Code AVP set to
DIAMETER_ERROR_IDENTITY_NOT_REGISTERED.
If the AAA cannot fulfil received request, e.g. due to database
error, it shall set Result-Code to DIAMETER_UNABLE_TO_COMPLY. No SSP
name or SSP capabilities shall be present in the response.
Message Format
< Location-Info-Answer > ::= < Diameter Header: 302: PXY >
< Session-Id >
{ Auth-Application-Id }
[ Result-Code ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Server-Name ]
[ Server-Capabilities ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
3.7 Multimedia-Auth-Request (MAR) Command
Belinchon et all [Page 18]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
The Multimedia-Auth-Request (MAR), indicated by the Command-Code
field set to 303 and the 'R' bit set in the Command Flags field, is
sent by an SSP node, acting as a Diameter client, to a server in
order to request the authentication 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
< Multimedia-Auth-Request > ::= < Diameter Header: 303, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
[ Destination-Host ]
{ User-Name }
{ Public-Identity }
[ SIP-Number-Auth-Items ]
[ SIP-Auth-Data-Item ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
3.8 Multimedia-Auth-Answer (MAA) Command
The Multimedia-Auth-Answer (MAA), indicated by the Command-Code field
set to 303 and the 'R' bit cleared in the Command Flags field, is
sent by the server in response to the Multimedia-Auth-Request
command. The Result-Code AVP may contain one of the values defined in
section 4 in addition to the values defined in [2].
Depending on where the authentication is performed (in the SSP or
AAA), the MAR/MAA sequence is performed just after the SSP receives
non-integrity protected REGISTER SIP method (authentication to be
performed in the SSP) or after the SSP receives a integrity protected
REGISTER SIP method (authentication performed in the AAA).
At reception of the MAR, the AAA MUST check first that the user
exists (i.e., the private identity is defined). If the server does
not recognized the user private identity received in the User-Name
AVP, the DIAMETER_ERROR_USER_UNKNOWN code will be sent back to the
HSP. Otherwise the AAA will check that this private identity matches
with the public identity received in the Public-Identity AVP. If
there is no match, the AAA server will send back to the HSP the
DIAMETER_ERROR_IDENTITIES_DONT_MATCH code.
The AAA MUST check that the authentication scheme indicated within
the grouped SIP-Auth-Data-Item AVP is supported. If not, the AAA will
send back the DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED code.
Belinchon et all [Page 19]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
If the received MAR contains the SIP-Authorization and Destination-
Host AVPs within the grouped SIP-Auth-Data-Item AVP, the AAA detects
that the authorization is being requested after a synchronization
failure. In this case, the AAA shall return the requested
authentication information and the Result-Code shall be set to
DIAMETER_SUCCESS.
Otherwise, the AAA shall download as many Authentication-Data-Item
grouped AVPs as the number specified in the SIP-Number-Auth-Items AVP
from the MAR message. Then, the AAA shall check the registration
status of the public identity received in the request.
If it is registered or unregistered, and the SSP name received in the
MAR is different from the one stored in the AAA, the AAA considers
the public identity as pending of the authentication confirmation.
The Result-Code shall be set to DIAMETER_SUCCESS.
If it is registered or unregistered, and the SSP name received in the
MAR is identical to the one stored in the AAA, the Result-Code shall
be set to DIAMETER_SUCCESS. If the public identity is unregistered,
it is considered as pending of the authentication confirmation. And
the AAA shall store the SSP name. . And the AAA shall store the SSP
name.
If it is not registered, the public identity is considered as pending
of the authentication confirmation. The Result-Code shall be set to
DIAMETER_SUCCESS.
AAA shall treat exceptions to the cases specified here as error
situations where the Result-Code shall be set to
DIAMETER_UNABLE_TO_COMPLY and no authentication information shall be
returned.
Message Format
< Multimedia-Auth-Answer > ::= < Diameter Header: 303, PXY >
< Session-Id >
{ Auth-Application-Id }
[ Result-Code ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Public-Identity ]
[ SIP-Number-Auth-Items ]
* [ SIP-Auth-Data-Item ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
Belinchon et all [Page 20]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
3.9 Registration-Termination-Request (RTR) Command
The Registration-Termination-Request (RTR) command, indicated by the
Command-Code field set to 304 and the 'R' bit set in the Command
Flags field, is sent by a Diameter Multimedia server to a Diameter
Multimedia client in order to request the de-registration of a user.
The AAA server can initiate the de-registration of a user and inform
the SSP by means of the RTR message. The AAA can decide whether only
one public identity is going to be de-registered, a list of public
identities, or all the identities of the user (Public-Identity AVP is
then not present in the request).
The AAA shall also inform the SSP the reason for the de-registration,
which will be included in the DeRegistration-Reason AVP.
Message Format
<Registration-Termination-Request> ::= < Diameter Header: 304, REQ,
PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
{ User-Name }
*[ Public-Identity ]
{ DeRegistration-Reason }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
3.10 Registration-Termination-Answer (RTA) Command
The Registration-Termination-Answer (RTA) command, indicated by the
Command-Code field set to 304 and the 'R' bit cleared in the Command
Flags field, is sent by a client in response to the Registration-
Termination-Request command. The Result-Code AVP may contain one of
the values defined in section 4 in addition to the values already
defined in [2].
At reception of an RTR message, the SSP will proceed to the public
identities de-registration. If only one public identity or a list of
them was present in the RTR message, the SSP shall remove all the
stored information for these identities. If no public identity was
included in the request message, the SSP shall remove all information
(all public identities) related to the user identified by the private
identity.
Belinchon et all [Page 21]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
The de-registration procedure also implies some other actions for the
SSP, who will act based on the Deregistration-Reason AVP.
If the reason was PERMANENT_TERMINATION, the IMS subscription or
service profile(s) has been permanently terminated. The SSP should
start the network initiated de-registration towards the user.
If the reason was NEW_SERVER_ASSIGNED, the AAA informs the SSP that a
new SSP has been allocated to the user due to some reason. The SSP
MUST 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.
If the reason was SERVER_CHANGE, the AAA informs the SSP that a new
SSP shall be allocated to the user when the user's SSP capabilities
are changed in the AAA or when the SSP indicates that it has not
enough memory for the updated User Profile. The SSP should start the
network initiated de-registration towards the user, i.e. all
registrations are de-registered and the user is asked to re-register
to all existing registrations.
If the reason was REMOVE_SSP, the AAA indicates to the SSP that the
SSP should no longer be used for a given user. The SSP shall not
start the network initiated de-registration towards the user when the
user is not currently registered but clears all information regarding
the user and responds to the AAA. The AAA then removes the SSP for
that user.
Message Format
<Registration-Termination-Answer> ::= < Diameter Header: 304, PXY >
< Session-Id >
{ Auth-Application-Id }
[ Result-Code ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
3.11 Push-Profile-Request (PPR) Command
The Push-Profile-Request (PPR) command, indicated by the Command-Code
field set to 305 and the 'R' bit set in the Command Flags field, is
sent by a Diameter Multimedia server to a Diameter Multimedia client
in order to update the subscription data of a multimedia user in the
Belinchon et all [Page 22]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
Diameter Multimedia client whenever a modification has occurred in
the subscription data that constitutes the data used by the client.
The AAA uses this message to notify to the SSP changes in the profile
of one of the SSP users. The SSP includes the updated user profile in
the User-Data AVP.
Message Format
< Push-Profile-Request > ::= < Diameter Header: 305, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
{ User-Name }
{ User-Data }
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
3.12 Push-Profile-Answer (PPA) Command
The Push-Profile-Answer (PPA) command, indicated by the Command-Code
field set to 305 and the 'R' bit cleared in the Command Flags field,
is sent by a client in response to the Push-Profile-Request command.
The Result-Code AVP may contain one of the values defined in section
4 in addition to the values already defined in [2].
At reception of PPR message, the SSP understands that changes have
occurred in the profile of a user and proceeds to update the
information.
When no error occurs, the SSP shall overwrite the received user
profile for all public identities related to the received private
identity (User-Name AVP), and shall return DIAMETER_SUCCESS code.
When no error occurs, the SSP shall overwrite the received user
profile for all public identities indicated within the user data
(User-Data AVP), and shall return DIAMETER_SUCCESS code.
If the SSP receives an update request for a user not found, the error
code DIAMETER_ERROR_USER_UNKNOWN is sent back.
If the SSP receives more data than it can accept, it shall return the
DIAMETER_ERROR_TOO_MUCH_DATA error code to the AAA. The SSP shall not
overwrite the data that it already has to give service to the user
Belinchon et all [Page 23]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
and the AAA shall initiate a network-initiated de-registration
procedure towards the SSP with Deregistration-Reason set to
SERVER_CHANGE, which will trigger the assignment of a new SSP.
If the request failed for any other reason, the
DIAMETER_UNABLE_TO_COMPLY error is sent back.
Message Format
< Push-Profile-Answer > ::=< Diameter Header: 10415: 305 >
< Session-Id >
{ Auth-Application-Id }
[ Result-Code ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
4 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 2001
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 2002
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 be included in the message.
DIAMETER_UNREGISTERED_SERVICE 2003
The user is not currently registered, but the requested service can
still be granted to the user.
DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2004
The HSS informs to the S-CSCF that de-registration was successful but
the SSP name is not stored in the AAA.
4.2 Permanent failures
Belinchon et all [Page 24]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
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_USER_UNKOWN 5001
A message was received for a user that is unknown.
DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5002
The value in one of the Public-Identity AVPs does not correspond to
the private user identity specified in the User-Name AVP.
DIAMETER_ERROR_IDENTITY_NOT_REGISTERED (5003)
A query for location information is received for a public identity
that has not been registered before. The user to which this identity
belongs cannot be given service in this situation.
DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5004
The user is not allowed to roam in the visited network.
DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5005
The identity being registered has already a server assigned and the
registration status does not allow that it is overwritten.
DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED 5006
The authentication scheme indicated in an authentication request is
not supported.
DIAMETER_ERROR_IN_ASSIGNMENT_TYPE 5007
The SSP name sent in the Server-Assignment-Request command is the
same SSP name as the assigned SSP name, but Server-Assignment-Type is
not allowed, e.g. the user is registered and the SSP sends Server-
Assignment-Request indicating the assignment for the unregistered
user.
DIAMETER_ERROR_TOO_MUCH_DATA 5008
The SSP receives more data than it can accept. The SSP shall not
overwrite the data that it already has to give service to the user
and the AAA shall initiate a network-initiated de-registration
procedure towards the SSP with Deregistration-Reason set to
SERVER_CHANGE, which will trigger the assignment of a new SSP
DIAMETER_ERROR_NOT SUPPORTED_USER_DATA 5009
The SSP informs AAA that the received subscription data contained
information, which was not recognized or supported.
5 Diameter AVP values
The following sections define the AVPs used in this diameter
application.
Belinchon et all [Page 25]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Visited- 1 5.11 OctectString | | | | | N |
Network-Identifier | | | | | |
Public- 2 5.10 UTF8String | | | | | N |
Identity | | | | | |
Server-Name 3 5.4 UTF8String | | | | | N |
Server 4 5.5 Grouped | | | | | N |
Capability | | | | | |
Mandatory- 5 5.5.1 Unsigned32 | | | | | N |
Capability | | | | | |
Optional- 6 5.5.2 Unsigned32 | | | | | N |
Capability | | | | | |
User-Data 7 5.13 OctectString | | | | | N |
SIP-Number-Auth 8 5.8 Unsigned32 | | | | | N |
Items | | | | | |
SIP- 9 5.7.2 UTF8String | | | | | N |
Authentication-Scheme | | | | | |
SIP- 10 5.7.3 OctetString | | | | | N |
Authenticate | | | | | |
SIP- 11 5.7.4 OctetString | | | | | N |
Authorization | | | | | |
SIP- 12 5.7.5 OctetString | | | | | N |
Authentication-Context | | | | | |
SIP-Auth-Data- 13 5.7 Grouped | | | | | N |
Item | | | | | |
SIP-Item- 14 5.7 Unsigned32 | | | | | N |
Number | | | | | |
Server- 15 5.6 Enumerated | | | | | N |
Assignment-Type | | | | | |
Deregistration- 16 5.9 Grouped | | | | | N |
Reason | | | | | |
Reason- 17 5.6 Enumerated | | | | | N |
Code | | | | | |
Reason- 18 5.6 UTF8String | | | | | N |
Info | | | | | |
Charging- 19 5.1 Grouped | M | P | | | N |
Information | | | | | |
Primary - 20 5.1 DiameterURI | M | P | | | N |
Event-Charging-Function-Name | | | | | |
Secondary - 21 5.1 DiameterURI | M | P | | | N |
Event-Charging-Function-Name | | | | | |
Primary - 22 5.1 DiameterURI | M | P | | | N |
Charging-Collection-Function-Name | | | | | |
Secondary - 23 5.1 DiameterURI | M | P | | | N |
Charging-Collection-Function-Name | | | | | |
Belinchon et all [Page 26]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
User- 24 5.12 Enumerated | | | | | N |
Authorization-Type | | | | | |
User- Data- 25 5.15 Enumerated | | | | | N |
Request-Type | | | | | |
User- Data- 26 5.14 Enumerated | | | | | N |
Already-Available | | | | | |
Confidentiality- 27 5.14 OctetString | | | | | N |
Key | | | | | |
Integrity- 28 5.14 OctetString | | | | | N |
Key | | | | | |
5.1 Charging-Information AVP
The Charging-Information (AVP code TBD) is of type Grouped, and
contains the addresses of the charging functions.
AVP format
Charging-Information :: = < AVP Header : TBD >
[ Primary-Event-Charging-Function-Name ]
[ Secondary-Event-Charging-Function-Name ]
[ Primary-Charging-Collection-Function-Name ]
[ Secondary-Charging-Collection-Function-Name ]
*[ AVP]
5.1.1 Primary-Event-Charging-Function-Name AVP
The Primary-Event-Charging-Function-Name AVP (AVP Code TBD) is of
type DiameterURI. This AVP contains the address of the Primary Event
Charging Function.
5.1.2 Secondary -Event-Charging-Function-Name AVP
The Secondary-Event-Charging-Function-Name AVP (AVP Code TBD) is of
type DiameterURI. This AVP contains the address of the Secondary
Event Charging Function.
5.1.3 Primary-Charging-Collection-Function-Name AVP
The Primary-Charging-Collection-Function-Name AVP (AVP Code 22) is of
type DiameterURI. This AVP contains the address of the Primary
Charging Collection Function.
5.1.4 Secondary -Charging-Collection-Function-Name AVP
The Secondary-Charging-Collection-Function-Name AVP (AVP Code 23) is
of type DiameterURI. This AVP contains the address of the Secondary
Charging Collection Function.
5.4 Server-Name AVP
Belinchon et all [Page 27]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
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 is assigned to the SIP user.
5.5 Server-Capability AVP
The Server-Capability AVP (AVP Code TBD) is of type Grouped. This
AVP is used to indicate support for particular SIP capability, and
contains the information to assist the HSP in the selection of an
SSP.
Server-Capability ::= < AVP Header: TBD >
*[ Mandatory-Capability ]
*[ Optional-Capability ]
*[ Server-Name ]
*[ AVP ]
5.5.1 Mandatory-Capability AVP
The Mandatory-Capability AVP (AVP Code TBD) is of type Unsigned32.
The value included in this AVP can be used to represent a single
determined mandatory capability of an SSP. Each mandatory capability
available in an individual operatorÆs network shall be allocated a
unique value. The allocation of these values to individual
capabilities is an operator issue.
5.5.2 Optional-Capability AVP
The Optional-Capability AVP (AVP Code TBD) is of type Unsigned32. The
value included in this AVP can be used to represent a single
determined optional capability of an SSP. Each optional capability
available in an individual operatorÆs network shall be allocated a
unique value. The allocation of these values to individual
capabilities is an operator issue.
5.6 Server-Assignment-Type AVP
The Server-Assignment-Type AVP (AVP code TBD) is of type Enumerated,
and indicates the type of server update being performed in a Server-
Assignment-Request operation. The following values are defined:
NO_ASSIGNMENT (0)
This value is used to request from AAA the user profile assigned to
one or more public identities, without affecting the registration
state of those identities.
REGISTRATION (1)
Belinchon et all [Page 28]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
The request is generated as a consequence of a first registration of
an identity.
RE_REGISTRATION (2)
The request corresponds to the re-registration of an identity.
UNREGISTERED_USER (3)
The request is generated because the SSP received an INVITE for a
public identity that is not registered.
TIMEOUT_DEREGISTRATION (4)
The SIP registration timer of an identity has expired.
USER_DEREGISTRATION (5)
The SSP has received a user initiated de-registration request.
TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6)
The SIP registration timer of an identity has expired. The SSP keeps
the user data stored in the SSP and requests AAA to store the SSP
name.
USER_DEREGISTRATION_STORE_SERVER_NAME (7)
The SSP has received a user initiated de-registration request. The
SSP keeps the user data stored in the SSP and requests AAA to store
the SSP name.
ADMINISTRATIVE_DEREGISTRATION (8)
The SSP, due to administrative reasons, has performed the de-
registration of an identity.
AUTHENTICATION_FAILURE (9)
The authentication of a user has failed.
AUTHENTICATION_TIMEOUT (10)
The authentication timeout has expired.
5.7 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-Info ]
[ SIP-Authentication-Context ]
[Confidentiality-Key]
Belinchon et all [Page 29]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
[Integrity-Key]
* [ AVP ]
5.7.1 SIP-Item-Number AVP
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).
5.7.2 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].
5.7.3 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.
5.7.4 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.
5.7.5 SIP-Authentication-Info AVP
The SIP-Authentication-Info AVP (AVP Code TBD) is of type OctetString
and contains additional authentication information sent by the AAA
server in case of Digest authentication. It follows the format
defined in RFC2617 for the Authentication-Info Header (sect 3.2.3).
The content of this AVP is to be mapped to the SIP Authentication-
Info header upon reception by the SIP server.
5.7.6 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.
Belinchon et all [Page 30]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
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.
5.7.7 Confidentiality-Key AVP
The Confidentiality-Key (AVP code 27) is of type OctetString, and
contains the Confidentiality Key (CK).
5.7.8 Integrity-Key AVP
The Integrity-Key (AVP code 28) is of type OctetString, and contains
the Integrity Key (IK).
5.8 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.
5.9 Deregistration-Reason AVP
The Deregistration-Reason AVP (AVP Code TBD) is of type Grouped, and
indicates the reason for a deregistration operation.
Message format
Deregistration-Reason::= < AVP Header: TBD >
{ Reason-Code }
[ Reason-Info ]
* [ AVP ]
5.9.1 Reason-Code AVP
The Reason-Code 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)
NEW_SERVER_ASSIGNED (1)
SERVER_CHANGE (2)
REMOVE_SSP (3)
5.9.2 Reason-Info AVP
Belinchon et all [Page 31]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
The Reason-Info AVP (AVP code TBD) is of type UTF8String, and
contains textual information to inform the user about the reason for
a de-registration.
5.10 Public-Identity AVP
The Public-Identity AVP (AVP Code TBD) is of type OctetString,
encoded in the UTF-8 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]).
This AVP contains the SIP public identity of a user in the IMS.
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.11 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.12 User-Authorization-Type AVP
The User-Authorization-Type AVP (AVP code 24) is of type Enumerated,
and indicates the type of user authorization being performed in a
User Authorization operation, i.e. UAR command. The following values
are defined:
REGISTRATION (0)
This value is used in case of the initial registration or re-
registration. HSP determines this from the Expires field in the SIP
REGISTER method if it is not equal to zero.
This is the default value.
DE_REGISTRATION (1)
This value is used in case of the de-registration. HSP determines
this from the Expires field in the SIP REGISTER method if it is equal
to zero.
REGISTRATION_AND_CAPABILITIES (2)
This value is used in case of initial registration or re-registration
and when the HSP explicitly requests SSP capability information from
the AAA.
5.13 User-Data AVP
Belinchon et all [Page 32]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
The 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.
5.14 User-Data-Already-Available AVP
The User-Data-Already-Available AVP (AVP code TBD) is of type
Enumerated, and indicates to the AAA whether or not the SSP already
has the part of the user profile that it needs to serve the user. The
following values are defined:
USER_DATA_NOT_AVAILABLE (0)
The SSP does not have the data that it needs to serve the user.
USER_DATA_ALREADY_AVAILABLE (1)
The SSP already has the data that it needs to serve the user.
5.15 User-Data-Request-Type AVP
The User-Data-Request-Type AVP (AVP code TBD) is of type Enumerated,
and indicates the type of user profile the SSP is requesting from the
AAA . The following values are defined:
COMPLETE_PROFILE (0)
This value is used to request from the AAA the complete user profile
corresponding to one or more public identities.
REGISTERED_PROFILE (1)
This value is used to request from the AAA the registered part of the
user profile corresponding to one or more public identities.
UNREGISTERED_PROFILE (2)
This value is used to request from the AAA the unregistered part of
the user profile corresponding to one or more public identities.
6. Authentication Details
Authenticating a mobile user can occur through various mechanisms
(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 the server will determine
the AVPs to 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 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
Belinchon et all [Page 33]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
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, Confidentiality-Key and Integrity-
Key AVPs are included.
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
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 AVP 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.
7. IANA Considerations
The Application-Id for the multimedia application has to be assigned
by IANA.
Command Code values are assigned by IANA according to reference [8].
The Diameter multimedia application will make use of the values 300-
305.
8 Acknowledgements
The authors would like to thank Tony Johansson and Kevin Pursuer for
their invaluable contribution to the start up of this application and
the continuous progress.
9 References
9.1 Normative References
Belinchon et all [Page 34]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
[1] Loughney, Camarillo, "Authentication, Authorization and
Accounting Requirements ", draft-ietf-sipping-aaa-req-02.txt, IETF
work in progress, Feb 2003
[2] Calhoun, Akhtar, Arkko, Guttman, Rubens, Zorn, "Diameter Base
Protocol", draft-ietf-aaa-diameter-17.txt, IETF work in progress, Dic
2002
[3] Calhoun, Johansson, Perkins, "Diameter Mobile IPv4 Application,"
draft-ietf-diameter-mobileip-13.txt, IETF work in progress, October
2002
[4] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
Ses¡sion Initiation Protocol". RFC 3261, June 2002
[5] IETF RFC 2396: "Uniform Resource Identifiers (URI): generic
syntax"
[6] IETF RFC 2806: "URLs for Telephone Calls"
[7] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access
Authentication"
9.2 Non-Normative References
[8] J. Loughney, "Provisional Diameter Command Codes for 3GPP",
draft-loughney-aaa-cc-3gpp-01.txt, IETF work in progress, Dic 2002
[9] IETF RFC 2119: "Key words for use in RFCs to Indicate Requirement
Levels"
[10] M. Garcia-Martin, "3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol (SIP) ",
draft-ietf-sipping-3gpp-r5-requirements-00.txt, IETF work in
progress, Oct 2002
[11] Pat R. Calhoun, Glen Zorn, David Spence, David Mitton, "Diameter
Network Access Server Application", draft-ietf-aaa-diameter-nasreq-
11.txt, IETF work in progress, Feb 2003
[12] J. Loughney, G. Camarillo, "Authentication, Authorization and
Accounting Requirements for the Session Initiation Protocol", draft-
ietf-sipping-aaa-req-02.txt, IETF work in progress, Feb 2003
10 Authors' Addresses
Maria-Carmen Belinchon Phone: +34 913393535
Ericsson Spain Fax: +34 913392538
Via de los Poblados, 13
28033 Madrid
Belinchon et all [Page 35]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
Spain
E-mail: maria.c.belinchon@ericsson.com
Miguel-Angel Pallares Phone: +34 913394222
Ericsson Spain Fax: +34 913392538
Via de los Poblados, 13
28033 Madrid
Spain
E-mail: miguel.pallares@ericsson.com
Carolina Canales Phone: +34 913392680
Ericsson Spain Fax: +34 913392538
Via de los Poblados, 13
28033 Madrid
Spain
E-mail: carolina.canales-valenzuela@ece.ericsson.se
Miguel Garcia Phone: +358 9 2993553
Ericsson Finland Fax: +358 9 2993052
Hirsalantie 11
02420 Jorvas
Finland
E-mail: Miguel.A.Garcia@ericsson.com
Peter J. McCann Phone: +1 630 713 9359
Lucent Technologies Fax: +1 630 713 4982
Rm 2Z-305
263 Shuman Blvd
Naperville, IL 60566-7050
USA
E-Mail: mccap@lucent.com
Jaakko Rajaniemi Phone: +358 50 3391387
Nokia Networks Fax: +358 9 51130163
P.O. Box 301
00045 Nokia Group
Finland
E-mail: jaakko.rajaniemi@nokia.com
Kalle Tammi Phone: +358
Nokia Networks Fax: +358
P.O. Box 301
00045 Nokia Group
Finland
E-mail: kalle.tammi@nokia.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Belinchon et all [Page 36]
INTERNET-DRAFT Diameter Multimedia Application February, 2003
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.
Belinchon et all [Page 37]