Internet DRAFT - draft-calhoun-sip-aaa-reqs
draft-calhoun-sip-aaa-reqs
INTERNET DRAFT Henrik Basilier
Category: Informational Ericsson, Inc.
Title: draft-calhoun-sip-aaa-reqs-04.txt Pat R. Calhoun
Date: March 2002 Black Storm Networks
Matt Holdrege
ipVerse
Tony Johansson
Ericsson, Inc.
James Kempf
Sun Microsystems, Inc.
Jaakko Rajaniemi
Nokia Networks
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 September 2002 [Page 1]
INTERNET DRAFT Feb 2002
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 Internet Draft describes requirements from 3rd Generation
wireless SDOs, discusses an architecture that satisfies those
requirements and deduces requirements for detailed definition of SIP-
AAA interworking. Furthermore, the Draft is intended to stimulate
discussions within the SIPPING Working Group, in order to come up
with a set of requirements that could then be used to begin
informative protocol design (meaning a new application extension to
Diameter) in the AAA Working Group.
Table of Contents
1.0 Introduction
1.1 Requirements language
1.2 Abbreviations
2.0 Network Architecture
2.1 Prerequisites for the 3G SDOs
2.2 Registration
2.3 Invitation
2.3.1 Invitation terminating in the mobile node
2.3.2 Invitation originating from the mobile node
2.3.3 Session accounting
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 September 2002 [Page 2]
INTERNET DRAFT Feb 2002
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 Internet Draft describes requirements from 3rd Generation
wireless SDOs, discusses an architecture that satisfies those
requirements and deduces requirements for detailed definition of SIP-
AAA interworking. Furthermore, the Draft is intended to stimulate
discussions within the SIPPING Working Group, in order to come up
with a set of requirements that could then be used to begin
informative protocol design (meaning a new application extension to
Diameter) 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].
1.2 Abbreviations
3GPP: Third Generation Partnership Project
3GPP2: Third Generation Partnership Project 2
AAA: Authentication, Authorization and Accounting
DNS: Domain Name Server
DSI: Dynamic Subscriber Information database
SDO: Standard Development Organization
SIP: Session Initiation Protocol
Calhoun et al. expires September 2002 [Page 3]
INTERNET DRAFT Feb 2002
2.0 Network Architecture
This section describes details of a scalable network architecture
based on SIP using a backend AAA infrastructure for use in 3G and
possibly other wired and wireless networks. We will detail how the
registration procedure will occur. We will also investigate how a SIP
invitation will proceed.
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 the next generation wireless networks (3G) are a driving
force towards the integration of SIP and AAA, it is desirable that
the architecture proposed be similar, if not identical, to the
wireline architecture.
2.1 Prerequisites for the 3G SDOs
The usage of SIP and Diameter within 3GPP and 3GPP2 is or is expected
to be specified in the respective SDOs, which set some prerequisites
on the interworking between the 3G SDOs SIP architecture and the AAA
infrastructure. There is a separate discussion about the way 3GPP
and 3GPP2 defines the usage of SIP. This document focuses only on SIP
- AAA related issues.
The following requirements are identified due to the perceived need
of evolving existing telecommunications infrastructure rather than
build new independent ones as well as the need to solve problems
identified with existing systems:
1. It is required that the home network always maintain the
control of sessions and services because service mobility can
be easier realized.
2. Scalability of the architecture is required. This will
minimize deployment issues when SIP servers are added to the
network to relieve traffic load.
Calhoun et al. expires September 2002 [Page 4]
INTERNET DRAFT Feb 2002
3. The distributed architecture of the 3G network shall be hidden
from the user. Thus a user must not be tied to a particular SIP
server.
4. Performance considerations: the operational architecture of
hosts that serve many users shall be kept as simple as
possible. Resource consuming operations shall be dedicated to
servers that can implement load sharing.
5. Necessity of SIP-AAA interworking: A 3GPP or 3GPP2 operator
requires its SIP servers to have access through AAA to
subscriber information so that they can request authorization
and authentication information before granting access to the
user to the multimedia services he or she may have subscribed
to. An operator may therefore want the possibility to restrict
the usage of SIP servers to authorized users only. Accounting
may be used to gather usage data of SIP servers for a specific
user.
6. Multiple access networks may exist: authorization based on the
authorization from the access network does not guarantee access
rights for SIP services.
2.2 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.
As stated in section 2.1, it is a requirement that a user MUST 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 Serving SIP Proxy
in the home network. This document assumes that the Serving SIP Proxy
is always assigned in the home network of the user.
One other important consequence from the requirements in section 2.1
is the ability to have a Home entry SIP Proxy, acting as a SIP proxy.
The Home entry SIP Proxy will access a Dynamic Subscriber Information
(DSI) database through the AAAH in order to identify the Serving SIP
Proxy in the home network serving the particular user. This Home
entry SIP Proxy MAY be used both for incoming SIP Sessions (SIP
INVITEs originating in another network) as well as messages
Calhoun et al. expires September 2002 [Page 5]
INTERNET DRAFT Feb 2002
originating from roaming mobiles (accessing functions in their home
network from a different domain/provider) if there was a desire to
hide the network configuration. If there was no desire to hide the
network configuration the SIP INVITEs MAY be originated directly to
the Serving SIP Proxy in the home network.
Furthermore, a Outbound SIP Proxy in the Visited network MAY be
present. The Outbound SIP Proxy is the first point of contact in the
visited network for a multimedia user. The Outbound SIP Proxy 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 Home entry SIP Proxy, possibly after translation.
There could be several methods for a mobile node to find its Home
entry SIP Proxy / Outbound SIP Proxy or for any other node to find
the Home entry SIP Proxy 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 September 2002 [Page 6]
INTERNET DRAFT Feb 2002
Home Network
+--------+ +----------+
+------->|xyz.com |<----->| xyz.com |
| | AAAH |<--+ | DSI |
| +--| server +-+ | | Database |
| | +--------+ | | +----------+
| | | |
6.AAA|7.AAA| 4.AAA| |3.AAA
Req| Rsp| Rsp| | Req
| v v |
+--+--------+ 5. SIP +---+---------+
|Serving SIP| Reg.| Home |
| Proxy in |<-------+ entry |
| the home | | SIP |
| network +------->| Proxy |
+-----------+8.200 OK+--+----------+
| ^
| |
9.200 OK| | 2. SIP REGISTER
v |
+-------+--------+
| (optional) |
Visited Network | Outbound |
| SIP |
| Proxy |
+--+-------------+
| ^
10.200 OK | | 1. SIP REGISTER
v |
+-------+-+
| SIP |
| Client | bob@xyz.com
+---------+
Figure 1: SIP Registration
In the event an Outbound SIP Proxy is present, a SIP client issues
its SIP REGISTER method to the Outbound SIP Proxy within the visited
network, otherwise the message is sent directly to the Home entry SIP
Proxy. When present, the Outbound SIP Proxy forwards the SIP REGISTER
to a Home entry SIP Proxy in the home network of the user. When the
Home entry SIP Proxy receives SIP REGISTER method from the SIP client
or the Outbound SIP Proxy, the Home entry SIP Proxy will issue a AAA
message to the Home AAA Server (AAAH). The AAA message includes the
SIP Client's identity, relevant parameters from the SIP message, and
other authorization and service specific information. The AAAH MAY
use the information to authenticate the SIP client, and to determine
whether it authorizes the client to access the service.
Calhoun et al. expires September 2002 [Page 7]
INTERNET DRAFT Feb 2002
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 would generate the challenge in the
response message that is sent back in to the SIP client, which would
then have to re-register.
If access is granted, the AAAH must verify whether a static Serving
SIP Proxy in the home network was configured for the client or if one
was selected by the Home entry SIP Proxy. If an Serving SIP Proxy in
the home network has not been selected, the AAAH MAY dynamically
assign an Serving SIP Proxy in the home network to the SIP client,
who will act as the client's server for the duration of the
authorization period (determined by the AAAH) or the Home entry SIP
Proxy MAY select a Serving SIP Proxy in the home network for the user
(selection based on information obtained from the AAA server).
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 Home entry SIP Proxy has obtained a successful reply from
the AAAH the Home entry SIP Proxy will forward SIP REGISTER method to
the selected Serving SIP Proxy in the home network.
At this point the Serving SIP Proxy in the home network MAY pull
security information (e.g. Session keys) and other necessary
information (e.g. Service Profile) from the AAAH. If the Home entry
SIP Proxy has selected the Serving SIP Proxy in the home network for
the user, the Serving SIP Proxy in the home network MAY also request
to the AAAH that it updates the DSI database to include the identity
of the Serving SIP Proxy.
If the AAAH has authenticated the client the Serving SIP Proxy in the
home network will then responds back to the Home entry SIP Proxy with
a 200 OK message, which is proxied back all the way to the user.
If the authentication of the SIP client is instead handled by the
Serving SIP Proxy in the home network, the Serving SIP Proxy in the
Calhoun et al. expires September 2002 [Page 8]
INTERNET DRAFT Feb 2002
home network MAY decide that a challenge-response procedure is
appropriate, and MAY issue a 401 (Unauthorized) response, including
the challenge. The SIP client would calculate the answer to the
challenge and would have to re-register and if granted, then the
Serving SIP Proxy in the home network will send back a 200 OK
message.
The AAAH MAY push security information (e.g Session keys) along with
other necessary information (e.g Service profile) to the assigned
Serving SIP Proxy in the home network. This sequence is not
illustrated in any of the figures.
A successful SIP registration MAY result in the generation of an
accounting record by the client's Serving SIP Proxy in the home
network. 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
Serving SIP Proxy in the home network, it MAY update its DSI
database. The database contains the identity of the SIP client, and
the Serving SIP Proxy in the home network. This database MAY be used
by other SIP servers within the local administrative domain to
identify a SIP client's assigned SIP server.
Additionally, under certain circumstances (e.g., subscription
termination, lost terminal, etc.), a home network administrative
function may determine a need to clear a user's SIP registration and
the assignment of the Serving SIP Proxy in the home network. This
function initiates the de-registration procedure and may reside in
various elements depending on the exact reason for initiating the de-
registration. One such home network element is the AAAH. Also an
administrative function external to the AAAH may trigger the AAAH to
initiate the de-registration procedure.
2.3 Invitation
In this section, we will look at the details of a SIP INVITE message,
how a session is setup, and how accounting takes place for the
session. It is assumed that there will be some kind of security
association between SIP servers. This may be established either via
the AAA infrastructure or in some other way to allow SIP sessions to
be established from SIP servers / proxies that are not members of the
AAA infrastructure on behalf of other users.
2.3.1 Invitation terminating in the mobile node
Calhoun et al. expires September 2002 [Page 9]
INTERNET DRAFT Feb 2002
Home Network
+--------+ +----------+ +----------+
|xyz.com | | xyz.com | | Naming |
| AAAH |<-->| DSI | | Server |
+->| server | | Database | | (e.g.DNS)|
| +--------+ +----------+ +----------+
| ^ ^
| AAA | |
| | | xyz.com?
v V v
+-----------+ INVITE+-----------+ INVITE +-----------+
|Serving SIP|<------+ Home |<-------+ abc.com |
|Proxy in | | entry | | |
|the home +------>| SIP |------->| SIP |
|network |200 OK | Proxy |200 OK | Server |
+-------+---+ +-----------+ +---+-------+
^ | | ^
200 OK| | 200 OK| |
| | SIP | | SIP
| | INVITE | | INVITE
| v v |
+--+------+ +---------+
| SIP | | SIP |
| Client | | Client |
+---------+ +---------+
bob@xyz.com joe@abc.com
Figure 2: Mobile Node terminated SIP Session Initiation
Figure 2 provides an example scenario 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 Serving SIP Proxy in the home network of bob@xyz.com is not
known, the SIP Server SHOULD attempt to resolve the Home entry SIP
Proxy within the home network, perhaps using a mechanism such as DNS.
The INVITE method is forwarded to the Home entry SIP Proxy. Upon
receipt of the SIP INVITE, the Home entry SIP Proxy MAY send an
authorization request to the AAAH, in order to determine whether the
session can be established and to find out which of the Serving SIP
Proxy in the home network is assigned to the SIP Client. At that
point, the Home entry SIP Proxy will forward the request directly to
the Serving SIP Proxy in the home network (Figure 2).
Upon receipt of the SIP INVITE method, the Serving SIP Proxy in the
home network MAY send an authorization request to the AAAH, in order
Calhoun et al. expires September 2002 [Page 10]
INTERNET DRAFT Feb 2002
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 method to the SIP Client. A response that includes an
error would cause the Serving SIP Proxy in the home network to return
an error back to the initiating SIP Server.
2.3.2 Invitation originating from the mobile node
Home Network
+----------+ +-------+ +----------+
| xyz.com | |xyz.com| | Naming |
DSI |<->| AAAH | | Server |
| Database | | server| | (e.g.DNS)|
+----------+ +-------+ +----------+
^ ^ ^
| | |
+-----------+ | |abc.com?
| | |
v v v
+-----------+INVITE +-----------+INVITE +-----------+
| Home +------->|Serving SIP+------>| abc.com |
| entry | | Proxy in | | |
| SIP |<-------+ the home |<------+ SIP |
| Proxy |200 OK | network |200 OK | Server |
+---+-------+ +-----------+ +------+----+
| ^ ^ |
| | 200 OK| |SIP
200 OK| |SIP | |INVITE
| |INVITE | |
v | | v
+------+--+ +-+-------+
| SIP | | SIP |
| Client | | Client |
+---------+ +---------+
bob@xyz.com joe@abc.com
Figure 3: Mobile node initiated SIP Session Initiation
Figure 3 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
Home entry SIP Proxy, or directly to the Serving SIP Proxy in the
home network, if this is known. If the Home entry SIP Proxy receives
the SIP INVITE, it will after a location lookup in the DSI database,
proxy it to the Serving SIP Proxy in the home network.
Calhoun et al. expires September 2002 [Page 11]
INTERNET DRAFT Feb 2002
Upon receipt of the SIP INVITE method, the Serving SIP Proxy in the
home network 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 method to the SIP Client. A response that includes an
error would cause the Serving SIP Proxy in the home network to return
an error back to the initiating SIP Client.
The authorization MAY be performed in the Serving SIP Proxy in the
home network if the AAAH has provided the required information to the
Serving SIP Proxy in the home network in the registration.
The Serving SIP Proxy in the home network 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.
2.3.3 Session accounting
During the SIP session establishment, the SIP server MAY initiate an
accounting session towards the Accounting server in the home or
visited network. SIP servers MAY generate several accounting records
during the SIP session. At the end of the SIP session, a final
accounting record should be issued that includes a summary of the SIP
session.
The accounting records should include accounting information that is
necessary for billing and inter-network settlement purpose.
Accounting information such as user identities (called and calling
party Ids), SIP call Id, used media types, request-URI, QoS
parameters (requested/negotiated quality of service), accounting
correlation Id, and SIP session duration should be recorded.
Any change during the SIP session that MAY affect the charge of SIP
session (e.g. change of media type, additional service requested,
call redirection) should be reflected in an accounting record. For
example during session forwarding, the initial calling party (A) MAY
incur the charges from A to B while the forwarding party MAY incur
charges due to the 'forwarded' session. Also, if the called party
requests additional media components with regard to the initial
request from calling party then the called party MAY be charged for
these additional components.
Parameters for accounting generation SHOULD be configurable in the
Calhoun et al. expires September 2002 [Page 12]
INTERNET DRAFT Feb 2002
SIP servers, or alternatively, the AAA server MAY indicate interim
accounting information to the SIP server, which advises the SIP
server when to generate the interim accounting records and if a
cumulative or non-cumulative accounting model MUST be used. It
should be noted that the traditional telco world currently makes use
of, and prefers, non-cumulative accounting information.
If SIP extensions (e.g. instant messaging, presence service) are
used, some of the request or response messages in these extensions
MAY trigger generation of accounting information. For example, a SIP
SUBSCRIBE MAY trigger generation of a one-time event accounting
record, session based instant messaging MAY trigger generation of
accounting session and SIP INFO methods MAY trigger generation of an
interim accounting message.
Accounting data related to bearer payload (e.g. number of transmitted
packets, used bandwidth) is assumed to be handled by other mechanisms
than SIP and is not included in these requirements. However a unique
accounting correlation Id MAY exist, which correlates the SIP session
with specific bearer(s)in the access network. If the unique
correlation Id exist, it MUST be included in all accounting records
to be able to correlate the accounting information from SIP session
to used bearer in the access network.
3.0 Requirements
From the previous section, we can extract the following requirements
for SIP-AAA interworking:
1. A basic requirement for Service Providers is to be able 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.
2. The AAAH MAY authenticate a user based on the corresponding
SIP REGISTER method.
3. The AAAH MAY authenticate a user session (the end result of a
successful SIP INVITE method), implementing whatever policy it
wishes, such as taking into account time of day, distance, etc.
4. The AAA infrastructure MUST be able to distribute (push or
pull) subscriber/service/security profiles to the relevant SIP
servers, based on policies
Calhoun et al. expires September 2002 [Page 13]
INTERNET DRAFT Feb 2002
5. The AAAH MUST be able to update the entry for the assigned SIP
server for the user performing SIP registration.
6. The AAAH MUST be able to provide the assigned server of the
user to the SIP entities requesting it.
7. The AAAH MUST be able to initiate de-registration of the user.
8. The AAA infrastructure or the Home entry SIP Proxy MUST be
able to allocate a SIP server for a subscriber at registration
time, based on policies, load distribution etc.
9. The scheme supported for the authentication between the SIP
servers and the AAA infrastructure MUST be flexible enough to
accommodate current authentication mechanisms, e.g. using
Subscriber Identity Module (SIM) card, and possible future
authentication mechanisms.
10. Ability for SIP Servers to provide the duration of a session,
the parties involved, and other relevant information to the
visited and home AAA servers as accounting information.
11. The AAA accounting messages MUST separate the "session
duration time" information from those generated via additional
services (e.g. 3-way calling, etc.)
12. There MUST be support for accounting transfers where the
information contained in the accounting data has a direct
bearing on the establishment, progression and termination of a
session.
13. There MUST be support for accounting transfers where the
information contained in the accounting data does NOT have a
direct bearing on the establishment, progression and
termination of a session.
14. SIP servers MUST be able to provide relevant accounting
information for billing and inter-network settlement purpose to
home and visited AAA servers. Both one time event accounting
records and session based (START, INTERIM, STOP records)
accounting MUST be supported.
15. Any change during the SIP session that affects the charge of
SIP session MUST be reflected in accounting messages.
Calhoun et al. expires September 2002 [Page 14]
INTERNET DRAFT Feb 2002
16. The AAA accounting protocol MUST support accounting per media
component (e.g. voice, video). The AAA accounting Protocol
MUST enable different parties to be charged per media
component.
17. Both cumulative and non-cumulative accounting model MUST be
supported.
18. Parameters for accounting generation must either be
configurable in the SIP servers or communicated by the AAA
servers.
19. If possible the accounting for SIP session MUST be correlated
to the bearer in the access network.
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: Sesˇ
sion 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 Levˇ
els", BCP 14, RFC 2119, March 1997.
[4] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authoˇ
rization, and Accounting Requirements". RFC 2977, October 2000.
[5] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Proˇ
tocol, Version 2", RFC 2165, June 1999.
[6] Aboba, Beadles "The Network Access Identifier." RFC 2486. January
1999.
[7] H. Schulzrinne, L. Slutsman, I. Faynberg, H. Lu, "Interworking
between SIP and INAP". draft-schulzrinne-sin-00.txt, IETF Work in
Calhoun et al. expires September 2002 [Page 15]
INTERNET DRAFT Feb 2002
Progress, July 2000.
[8] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" RFC 1409,
November 1998.
6.0 Acknowledgements
The authors would like to thank the participants of the 3GPP and
3GPP2 working groups for their valuable feedback, and to Harri Hakala
for very useful proposed text.
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
Black Storm Networks
250 Cambridge Avenue
Suite 200
Palo Alto, California, 94306
USA
Phone: +1 650-617-2932
Fax: +1 720-293-7501
E-mail: pcalhoun@diameter.org
Matt Holdrege
ipVerse
223 Ximeno Ave.
Long Beach, CA 90803
U.S.A.
E-mail: matt@ipverse.com
Calhoun et al. expires September 2002 [Page 16]
INTERNET DRAFT Feb 2002
Tony Johansson
Ericsson Inc.
2100 Shattuck Ave.
Berkeley, Califonia, 94704
USA
Phone: +1 510-305-6108
Fax: +1 510-666-3999
E-mail: tony.johansson@ericsson.com
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
Jaakko Rajaniemi
Nokia Networks
P.O. Box 301
00045 Nokia Group
Finland
Phone: +358 50 3391387
Fax: +358 9 51130163
E-mail: jaakko.rajaniemi@nokia.com
Calhoun et al. expires September 2002 [Page 17]
INTERNET DRAFT Feb 2002
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 September 2002 [Page 18]
