INTERNET DRAFT Henrik Basilier
Category: Informational Ericsson, Inc.
Title: draft-calhoun-sip-aaa-reqs-02.txt Pat R. Calhoun
Date: May 2001 Sun Microsystems, Inc.
Matt Holdrege
ipVerse
Tony Johansson
Ericsson, Inc.
James Kempf
Sun Microsystems, Inc.
AAA Requirements for IP Telephony/Multimedia
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.
Calhoun et al. expires November 2001 [Page 1]
INTERNET DRAFT May 2001
Abstract
The AAA Working Group has been defining requirements for Network
Access in Inter-Domain (roaming) networks, including requirements
from the Mobile IP and NASREQ Working Groups. Some of these
requirements were input from work done in the 3rd Generation wireless
SDOs. These same SDO's have a need to tie their IP Intelligent
Servers (e.g. Softswitches, Call Agents, SIP Servers, etc.) to their
AAA infrastructure. This specification defines some requirements for
both the AAA (meaning a new extension to DIAMETER) and IP
Telephony/Multimedia protocols (SIP, MEGACO, etc.)
This Internet Draft is intended to stimulate discussions within the
SIP Working Group, in order to come up with a set of requirements
that could then be used to begin informative protocol design in the
AAA Working Group.
Table of Contents
1.0 Introduction
1.1 Requirements language
2.0 Network Architecture
2.1 Registration
2.2 Invitation
2.2.1 Invitation terminating in the mobile node
2.2.2 Invitation originating from the mobile node
3.0 Requirements
4.0 Security Considerations
5.0 References
6.0 Acknowledgements
7.0 Authors' Addresses
8.0 Full Copyright Statement
Calhoun et al. expires November 2001 [Page 2]
INTERNET DRAFT May 2001
1.0 Introduction
The AAA Working Group has been defining requirements for Network
Access in Inter-Domain (roaming) networks, including requirements
from the Mobile IP and NASREQ Working Groups. Some of these
requirements were input from work done in the 3rd Generation wireless
SDOs. These same SDO's have a need to tie their IP Intelligent
Servers (e.g. Softswitches, Call Agents, SIP Servers, etc.)to their
AAA infrastructure. This specification defines some requirements for
both the AAA (meaning a new extension to DIAMETER) and IP
Telephony/Multimedia protocols (SIP, MEGACO, etc.)
This Internet Draft is intended to stimulate discussions within the
SIP Working Group, in order to come up with a set of requirements
that could then be used to begin informative protocol design in the
AAA Working Group.
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].
2.0 Network Architecture
This section will contain some details on how the authors envision
SIP will be used in 3G as well as other wired and wireless networks.
We will detail how the registration procedure will occur. We will
also investigate how a SIP invitation will proceed. All examples in
this version of the document assumes that the SIP clients always
registers with their home network (home control).
The authors wish to state that much of this work is still in progress
in various other groups including the SIP WG and 3G SDOs, and is
subject to change. The ideas described in this document do not
represent a final agreement in any working group or SDOs, but does
include ideas from well established positions in the related groups.
This document will be updated when further SIP, AAA, and 3G
requirements are received.
This document is also intended as an informal method for IETF SIP
experts to feed in their expertise into the 3G standardization
efforts through comments on this Internet Draft.
Although a driving force towards the integration of SIP and AAA is
Calhoun et al. expires November 2001 [Page 3]
INTERNET DRAFT May 2001
the next generation wireless networks (3G), it is desirable that the
architecture proposed be similar, if not identical, to the wireline
architecture.
2.1 Registration
In this section, we will provide an example of a user registering his
device. The scenario described is one where the user is roaming in a
visited network, typically owned and operated by a different service
provider. This is however seen as a superset of the scenario where
the user is in his home network, which is therefore not explicitly
described.
It is a requirement that a user is not be tied to a specific SIP
server. This is necessary for many reasons, including scaling and to
minimize deployment issues when SIP servers are added to the network
to relieve traffic load. In this document, the SIP server that has
been either statically or dynamically assigned to serve a particular
user is called the Anchor SIP Proxy. This document assumes that the
Anchor SIP proxy is always assigned in the home network of the user.
One other important requirement is the ability to have a SIP server
Central Point of Contact (SCPC), acting as a SIP proxy/redirect. The
SCPC will use a location database function to proxy/redirect messages
to the Anchor SIP proxy serving the particular user. This SCPC will
be used both for incoming SIP Sessions (SIP Invites originating in
another network) as well as messages originating from roaming mobiles
(accessing functions in their home network from a different
domain/provider). The location database function is the same as
described in [1].
Furthermore, a SIP server Point of Contact in the Visited network
(SPCV) MAY be present. The SPCV is the first point of contact in the
visited network for a multimedia user. The SPCV behaves like a Proxy
(as defined in [1] or subsequent versions), i.e. it accepts requests
and processes them internally or forwards them on to the SCPC,
possibly after translation.
There could be several methods for a mobile node to find its
SCPC/SPCV or for any other node to find the SCPC Contact of a user.
Although the exact methods to use is outside the scope of this
document, we have assumed the use of Domain Name Service (DNS)
throughout this document.
Calhoun et al. expires November 2001 [Page 4]
INTERNET DRAFT May 2001
Home Network
+--------+ +----------+
+------->|xyz.com |<----->| xyz.com |
| | AAAH |<--+ | Location |
| +--| server +-+ | | Database |
| | +--------+ | | +----------+
| | | | ^
6.AAA|7.AAA| 4.AAA| |3.AAA |
Req| Rsp| Rsp| | Req |
| v v | v
+--+--------+ 5. SIP +---+---------+
| Anchor | Reg.| SIP |
|Softswitch/|<-------+ Central |
| SIP | | Point of |
| Proxy +------->| Contact |
+-----------+8.200 OK+--+----------+
| ^
| |
9.200 OK| | 2. SIP Register
v |
+-------+--------+
| (optional) SIP |
Visited Network | Point of |
| Contact in |
| Visited network|
+--+-------------+
| ^
10.200 OK | | 1. SIP Register
v |
+-------+-+
| SIP |
| Client | bob@xyz.com
+---------+
Figure 1: SIP Registration
In the event an SPCV is present, a SIP client issues its SIP Register
message to the SPCV within the visited network, otherwise the message
is send directly to the SCPC. When present, the SPCV forwards the SIP
Register to a SCPC in the home network of the user. The SPCV could
modify the information in the Contact header of the SIP Register
message so that it contains the identity of the SPCV.
When the SCPC receives SIP Register message from the SIP client or
the SPCV, the SCPC will issue a AAA message to the Home AAA Server
(AAAH). The AAA message includes the SIP Client's identity, the SIP
message as opaque data, and other authorization and service specific
information. The AAAH uses the information to authenticate the SIP
Calhoun et al. expires November 2001 [Page 5]
INTERNET DRAFT May 2001
client, and to determine whether it authorizes the client to access
the service.
The AAAH MAY decide that a challenge-response procedure is
appropriate, and instruct the SIP proxy to send back a 401
(Unauthorized) response. The AAAH will generate the challenge in the
response message that is sent back in to the client, which will have
to re-register.
The SCPC MAY select an Anchor SIP proxy for the user (selection based
on information obtained from the AAAH server).
If access is granted, the AAAH must verify whether a static Anchor
SIP Server was configured for the client or if one was selected by
the SCPC. Otherwise, the AAAH dynamically assigns an Anchor SIP
Server to the SIP client, which will act as the client's server for
the duration of the authorization period (determined by the AAAH).
The AAAH MAY also determine that the SCPC should act as the client's
server for the duration of the authorization period.
If the AAAH determines that the SIP client does not have a security
association with the assigned server, it MAY create a dynamic
security association between the nodes, by distributing session keys
to be used in all subsequent SIP messages. This is similar to the
method described in [4].
Dynamic establishment of security associations by the AAAH is
typically useful in scenarios where the entities do not have pre-
established trust, and trust is mandatory in all SIP messages. It
should be equally possible for the AAAH to return the relevant
certificates to the entities, which could then establish a direct
security association, via an out-of-band key management protocol,
such as the Internet Key Exchange [8].
When the SCPC has obtained a successful reply from the AAAH the SCPC
will forward SIP Register message to the selected Anchor SIP Server.
The Anchor SIP proxy MAY pull security information (e.g. Session
keys) and other necessary information (e.g. Service Profile) from the
AAAH. The Anchor SIP proxy will then responds back to the SCPC with a
200 OK message, which be proxied back all the way to the user.
The AAAH MAY push security information (e.g Session keys) along with
other necessary information (e.g Service profile) to the assigned
Anchor SIP proxy. This sequence is not illustrated in any of the
figures.
Calhoun et al. expires November 2001 [Page 6]
INTERNET DRAFT May 2001
In the event that the AAAH created session keys for the communicating
SIP entities, the SIP server MUST include the session keys destined
for the SIP client within the SIP response. The server then adds its
own authentication information using the session keys it received
from the AAAH. The response is subsequently forwarded to the SIP
client.
A successful SIP registration MAY result in the generation of an
accounting record by the client's anchor SIP server. The accounting
record MAY include such information as the user's identity, the
location of the registration, date and time, etc.
Once the AAAH has sent the successful authorization message to the
anchor SIP server, it MAY update its local location database. The
database contains the identity of the SIP client, and the anchor SIP
server. This database MAY be used by other SIP servers within the
local administrative domain to identify a SIP client's assigned SIP
server.
Figure 2 shows an alternative scenario that MAY be supported. The
only difference is that the SCPC after authentication issues a
redirect to the SPCV, sending it the address of the Anchor SIP proxy.
The SPCV node MAY upon reception of this redirect message redirect
all subsequent messaging directly to the Anchor SIP proxy, including
SIP Invite messages, thus bypassing the SCPC.
Calhoun et al. expires November 2001 [Page 7]
INTERNET DRAFT May 2001
Home Network
+--------+ +----------+
+------->|xyz.com |<----->| xyz.com |
| | AAAH |<--+ | Location |
| +--| server +-+ | | Database |
| | +--------+ | | +----------+
| | | | ^
7.AAA|8.AAA| 4.AAA| |3.AAA |
Rsp| Req| Rsp| | Req |
| v v | v
+-----------+ +----+--------+
| Anchor | | SIP |
|Softswitch/| | Central |
| SIP | | Point of |
| Proxy | | Contact |
+--+--------+ +----+--------+
| ^ | ^
| | | |
| | | | 2. SIP Register
| | 5.Redirect| |
| | | |
| | v |
| | 6.SIP +-------+--------+
| | Register | SIP |
| +-----------+ Point of |
| | Contact in |
+---------------->| Visited network|
9. 200 OK +----+-----------+
| ^
10. 200 OK | | 1. SIP Register
v |
+-------+-+
| SIP |
| Client | bob@xyz.com
+---------+
Figure 2: SIP Registration with redirect.
2.2 Invitation
In this section, we will look at the details of a SIP invite message,
and how a session is setup. Although it cannot be forbidden, it is
assumed that the SIP Servers do not share pre-existing security
association, either implicitly or via the AAA infrastructure. This
allows SIP sessions to be established from users that are not members
of the AAA infrastructure.
Calhoun et al. expires November 2001 [Page 8]
INTERNET DRAFT May 2001
2.2.1 Invitation terminating in the mobile node
Home Network
+--------+ +----------+ +----------+
|xyz.com | | xyz.com | | Naming |
| AAAH | | Location | | Server |
+->| server | | Database | | (e.g.DNS)|
| +--------+ +----------+ +----------+
| ^ ^
| AAA | Location |
| | Query | xyz.com?
v v v
+-----------+ Invite+-----------+ Invite +-----------+
| Anchor |<------+ SIP |<-------+ abc.com |
|Softswitch/| | Central | | |
| SIP +------>| Point of |------->| SIP |
| Proxy |200 OK | Contact |200 OK | Server |
+-------+---+ +-----------+ +---+-------+
^ | | ^
200 OK| | 200 OK| |
| | SIP | | SIP
| | Invite | | Invite
| v v |
+--+------+ +---------+
| SIP | | SIP |
| Client | | Client |
+---------+ +---------+
bob@xyz.com joe@abc.com
Figure 3: Mobile Node terminated SIP Session Initiation
Figure 3 and Figure 4 provides some example scenarios of a user that
wishes to establish a SIP session with bob@xyz.com.
The SIP client of joe@abc.com issues the invite message to its local
SIP Server (abc.com SIP Server).
If the Anchor SIP proxy of bob@xyz.com is not known, the SIP Server
SHOULD attempt to resolve the SIP Central Point of Contact (SCPC)
within the home network, perhaps using a mechanism such as DNS. The
Invite message is forwarded to the SCPC, which finds the user's
current anchor SIP server by sending a query to the Location
Database. At that point, the SCPC MAY either forward the request
directly to the Anchor SIP Server (Figure 3), or return a redirect
message to the initiating SIP Server (Figure 4). In either case, the
Calhoun et al. expires November 2001 [Page 9]
INTERNET DRAFT May 2001
message is forwarded to the Anchor SIP Server.
Home Network
+--------+ +----------+ +----------+
|xyz.com | | xyz.com | | Naming |
| AAAH | | Location | | Server |
+->| server | | Database | | (e.g.DNS)|
| +--------+ +----------+ +----------+
| ^ ^
| AAA | Location |
| | Query | xyz.com?
v v v
+-----------+ +-----------+ Invite +-----------+
| Anchor | | SIP |<-------| abc.com |
|Softswitch/| | Central | | |
| SIP |<-+ | Point of |------->| SIP |
| Proxy | | | Contact |Redirect| Server |
+-----------+ | +-----------+ +-----------+
^ | Invite | ^
| +---------------------------+ |
| SIP SIP |
| Invite Invite |
v |
+---------+ +---------+
| SIP | | SIP |
| Client | | Client |
+---------+ +---------+
bob@xyz.com joe@abc.com
Figure 4: Mobile node terminated SIP Session Initiation (alternative)
Upon receipt of the SIP Invite message, the Anchor SIP Server MAY
send an authorization request to the AAAH, in order to determine
whether the session can be established. The authorization check by
the AAAH MAY include other policy decisions, such as time of day,
origination point of the session, etc. A successful response from the
AAAH will result in the forwarding of the SIP Invite message to the
SIP Client. A response that includes an error would cause the Anchor
SIP Server to return an error back to the initiating SIP Server.
When the SIP session (and RTP flow) is established, the SIP servers
initiate accounting records, which are transfered to the AAA
infrastructure. The accounting records should include usage
information, that is necessary for billing purposes. The traditional
telco world current makes use, and prefers, non-cumulative accounting
information, therefore any interim accounting information MUST be
Calhoun et al. expires November 2001 [Page 10]
INTERNET DRAFT May 2001
non-cumulative. At the end of the SIP session, a final accounting
record should be issued that includes a summary of the session.
2.2.2 Invitation originating from the mobile node
Home Network
+----------+ +-------+ +----------+
| xyz.com | |xyz.com| | Naming |
Location | | AAAH | | Server |
| Database | | server| | (e.g.DNS)|
+----------+ +-------+ +----------+
^ ^ ^
|Location |AAA |abc.com?
|Query | |
v v v
+-----------+Invite +-----------+Invite +-----------+
| SIP +------->| Anchor +------>| abc.com |
| Central | |Softswitch/| | |
| Point of |<-------+ SIP |<------+ SIP |
| Contact |200 OK | Proxy |200 OK | Server |
+---+-------+ +-----------+ +------+----+
| ^ ^ |
| | 200 OK| |SIP
200 OK| |SIP | |Invite
| |Invite | |
v | | v
+------+--+ +-+-------+
| SIP | | SIP |
| Client | | Client |
+---------+ +---------+
bob@xyz.com joe@abc.com
Figure 5: Mobile node initiated SIP Session Initiation
Figure 5 provides an example of a user, bob@xyz.com, that wishes to
establish a SIP session with joe@abc.com.
The SIP Client of bob@xyz.com sends the SIP Invite, either to his
SCPC SIP proxy, or directly to the Anchor SIP proxy, if this is
known. If the SIP Central Point of Contact receives the SIP Invite,
it will after a location lookup proxy it to the Anchor SIP proxy.
Upon receipt of the SIP Invite message, the Anchor SIP Server MAY
send an authorization request to the AAAH, in order to determine
whether the session can be established. The authorization check by
the AAAH MAY include other policy decisions, such as time of day,
origination point of the session, etc. A successful response from the
AAAH will result in the forwarding of the SIP Invite message to the
Calhoun et al. expires November 2001 [Page 11]
INTERNET DRAFT May 2001
SIP Client. A response that includes an error would cause the Anchor
SIP Server to return an error back to the initiating SIP Client.
The Anchor SIP Server will after this use ordinary SIP proxying
mechanisms to proxy the SIP Invite to the SIP server serving
joe@abc.com, which will proxy the message to the SIP Client of
joe@abc.com. SIP 200 OK messages traverse back along the same path.
When the SIP session (and RTP flow) is established, the SIP servers
initiate accounting records, which are transfered to the AAA
infrastructure. The accounting records should include usage
information, that is necessary for billing purposes. The traditional
telco world current makes use, and prefers, non-cumulative accounting
information, therefore any interim accounting information MUST be
non-cumulative. At the end of the SIP session, a final accounting
record should be issued that includes a summary of the session.
3.0 Requirements
From the previous section, we can extract the following requirements:
- A basic requirement for Service Providers is to integrate
different networks for more efficient operations. IETF AAA
efforts support this idea by striving for a single AAA
architecture and protocol set. Whether access is supported by
PPP, Mobile-IP, MEGACO or SIP, a common architecture and
protocol set SHOULD be used.
- The AAA infrastructure MUST be able to perform policy control
of the SIP servers/proxies, controlling their
behavior/functionality based on user and/or network policies.
- The AAAH MUST authenticate a user, and MAY authorize a user and
the session being requested. The Home AAA server may implement
whatever policy it wishes on authorizing the session, such as
time of day, long distance, etc.
- The AAA infrastructure MUST be able to distribute (push or
pull) subscriber/service profiles to the relevant SIP servers,
based on policies.
- The AAA infrastructure MUST be able to do an allocation of a
SIP server for a subscriber at registration time, based on
policies, load distribution etc.
- Allow SIP messages to be sent through the AAA infrastructure as
opaque data (e.g. when the authentication procedures includes
http digest calculation), to allow the Home AAA server to
authenticate the message. This eliminates the need for the
Home AAA server to send the user's "password" to SIP servers.
- The AAA infrastructure MUST support SIM and smart cards.
- Ability for SIP Servers to provide the duration of a session,
Calhoun et al. expires November 2001 [Page 12]
INTERNET DRAFT May 2001
the parties involved, and other relevant information to the
visited and home AAA servers as accounting information.
- The AAA protocol MUST support for both cumulative, and non-
cumulative, accounting models.
- The AAA accounting messages MUST Separate the "session duration
time" information from those generated via additional services
(e.g. 3-way calling, etc.)
- Support for real-time and non-real time accounting data
transfers.
4.0 Security Considerations
It is assumed that integrating AAA and IP Telephony/Multimedia will
not introduce any new security risks. Therefore, the AAA data MUST be
secured and obscured when transiting the network, the endpoints MUST
be authenticated before data is sent, and the endpoints MAY be
authorized to access certain types of AAA data.
5.0 References
[1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
Session Initiation Protocol". RFC 2543, March 1999.
[2] Aboba et al, "Network Access AAA Evaluation Criteria". RFC 2989,
November 2000.
[3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
Authorization, and Accounting Requirements". RFC 2977, October
2000.
[5] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location
Protocol, Version 2", RFC 2165, June 1999.
[6] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu-
ary 1999.
[7] H. Schulzrinne, L. Slutsman, I. Faynberg, H. Lu, "Interworking
between SIP and INAP". draft-schulzrinne-sin-00.txt, IETF Work
in Progress, July 2000.
[8] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" RFC
1409, November 1998.
Calhoun et al. expires November 2001 [Page 13]
INTERNET DRAFT May 2001
6.0 Acknowledgements
Many of the requirements, and thoughts expressed in this Internet
Draft, came from presentations that were presented at various 3rd
Generation wireless meetings, such as 3GPP, 3GPP2 and MWIF.
7.0 Authors' Addresses
Questions about this memo can be directed to:
Henrik Basilier
Ericsson Inc.
2100 Shattuck Ave.
Berkeley, Califonia, 94704
USA
Phone: +1 858-361-4314
Fax: +1 510-666-3999
E-mail: henrik.basilier@ericsson.com
Pat R. Calhoun
Network and Security Research Center, Sun Laboratories
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650-786-7733
Fax: +1 650-786-6445
E-mail: pcalhoun@eng.sun.com
Matt Holdrege
ipVerse
223 Ximeno Ave.
Long Beach, CA 90803
U.S.A.
E-mail: matt@ipverse.com
Tony Johansson
Ericsson Inc.
2100 Shattuck Ave.
Berkeley, Califonia, 94704
USA
Calhoun et al. expires November 2001 [Page 14]
INTERNET DRAFT May 2001
Phone: +1 510-305-6108
Fax: +1 510-666-3999
E-mail: tony.johansson@ericsson.com
James Kempf
Network and Security Research Center, Sun Laboratories
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650-786-5890
Fax: +1 650-786-6445
E-mail: james.kempf@eng.sun.com
8.0 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. The lim-
ited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns. This document
and the information contained herein is provided on an "AS IS" basis
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Calhoun et al. expires November 2001 [Page 15]