One document matched: draft-calhoun-sip-aaa-reqs-00.txt
INTERNET DRAFT Henrik Basilier
Category: Informational Ericsson, Inc.
Title: draft-calhoun-sip-aaa-reqs-00.txt Pat R. Calhoun
Date: July 2000 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 2000. All Rights Reserved.
Calhoun et al. expires January 2001 [Page 1]
INTERNET DRAFT July 2000
Abstract
The AAA Working Group has been defining requirements for Network
Access in an Inter-Domain (roaming) network, both Mobile IP and
NASREQ. 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 and IP Telephony protocols
(SIP, MEGACO, etc.)
This first Internet Draft is intended to simulate discussions within
the SIP Working Group, in order to come up with a set of requirements
that could then be used to begin protocol design.
Table of Contents
1.0 Introduction
1.1 Requirements language
2.0 Network Architecture
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 January 2001 [Page 2]
INTERNET DRAFT July 2000
1.0 Introduction
The AAA Working Group has been defining requirements [2] for Network
Access in an Inter-Domain (roaming) network, both Mobile IP and
NASREQ. 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 and IP Telephony protocols
(SIP, MEGACO, etc.)
This first Internet Draft is intended to simulate discussions within
the SIP Working Group, in order to come up with a set of requirements
that could then be used to begin protocol design.
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 [13].
2.0 Network Architecture
In this specification, we assume that a roaming SIP user is a
superset of a user in its home network, therefore we will concentrate
on the former. Figure one (1) provides an example of an inter-domain
SIP network. This architecture was chosen, due to its similarities to
the existing AAA architecture for Mobile IP [4] and NASREQ [5].
Although a driving force towards the integration of SIP and AAA is
the next generation wireless networks (3G), it is desirable that the
architecture proposed be similar, if not identical, to the wireline
architecture.
In the example provided in Figure 1, a user (bob@xyz.com) gets access
to the visited network. The method by which access to the network is
gained is completely outside the scope of this document, but it is
assumed that the AAA infrastructure was used to authenticate and
authorized the user's request to access the network.
Once the user has access to the network, he discovers the local SIP
Proxy, which could be done using a service discovery protocol, such
as SLP [6].
When the SIP client issues its SIP Register message to the local
proxy, an AAA message is created, which includes the SIP message as
Calhoun et al. expires January 2001 [Page 3]
INTERNET DRAFT July 2000
opaque data, to the local AAA server, known as the AAAF. The AAAF MAY
apply local policy decisions to the request, which may cause the
request to be denied. If the request is not denied, it is forwarded
to the user's Home AAA Server (AAAH), using the domain portion of the
user's NAI [7].
The AAAH server is responsible for authenticating the SIP message,
ensuring that the correct secret information shared with the SIP
Client, or user, was used to generate the authentication information.
Further, it authorizes the client's registration request based on its
local policy, which could include validating that the user is
permitted to receive service in a visited network.
At the time of authorization, the AAAH MAY assign a Home SIP Server,
which MAY be done for load balancing reasons. It would also record
the user's current binding information. In the event that a dynamic
security association is to be setup between the SIP Proxy and the
Home SIP server, the AAAH MAY generate keying information, similar to
those described in [4]. The AAAH then returns a reply, back to the
AAAF, and SIP Proxy, which includes profile information, known as
authorization information. This information could include Quality of
Service information, that the visited network would apply to the
user's SIP session (and related RTP flows).
The SIP Registration message is then forwarded to the Home SIP
Server. In the event that the AAAH server had returned dynamic
security association information, the SIP Proxy would add
authentication information, generated using the key received by the
AAAH.
When the SIP Client wishes to initiate a call, the invite message is
forwarded to the SIP Proxy. In the event that the AAAH server
returned dynamic security association information, the mobile would
have included the authentication information, generated using the
session keys generated on the AAAH. If the Home SIP Server is to be
contacted for all calls generated by the SIP Client, the SIP Proxy
authenticates the message to it. The Home SIP Server (or SIP Proxy if
the Home is not involved) initiates an authorization request to the
AAA infrastructure. The AAAH should determine whether the requested
call is permitted, and may perform additional policy verifications,
and return the appropriate response.
If a successful response was returned by the AAAH, the Home SIP
Server forwards the SIP invite to the proper destination.
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
Calhoun et al. expires January 2001 [Page 4]
INTERNET DRAFT July 2000
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.
Visited Network Home Network
+--------+ +--------+ +--------+
|abc.com | | Broker | |xyz.com |
| AAAF |<----->| AAA |<-------->| AAAH |
+->| server | | Server | | server |
| +--------+ +--------+ +--------+
| ^ ^
| AAA | | AAA
| | |
v v v
+-----------+ +-----------+ +-----------+
|Softswitch/| |Softswitch/| |Softswitch/|
| SIP | | SIP |<--------------->| Home SIP |
| Proxy | | Proxy | SIP | Server |
+-----------+ +-----------+ +-----------+
^
| SIP
|
v
+---------+
| SIP |
| Client | bob@xyz.com
+---------+
Figure 1: Inter-Domain SIP Architecture
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 support for AAA brokers and
proxies.
- The AAA infrastructure MUST support SIP users roaming to a
Calhoun et al. expires January 2001 [Page 5]
INTERNET DRAFT July 2000
foreign (or visited) networks.
- It is assumed that a hybrid/distributed model is used, where
the actual session/call control is allowed in either the home
or visited network. The AAAH makes this decision at the time
the user is initially authorized.
- 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.
- Certain localized services (e.g. 911) must be provided by the
serving network.
- The AAAH will authenticate, and authorize, a user and the
session being requested. The Home AAA server may implement
whatever policy it wishes on authorizing the call, 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.
- Support for the AAA infrastructure to return Quality of Service
(QOS) properties to the visited network, to be applied to the
user's telephony session.
- 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.
- Dynamic security associations created between the visited SIP
Server and the Home SIP Server. This will be necessary for
basic SIP proxy authentication. The AAAH MAY provide the
dynamic security association to the Proxy and Home SIP Servers.
- Allow SIP messages to be sent through the AAA infrastructure as
opaque data, 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 call, the
parties involved, and other relevant information to the visited
and home AAA servers as accounting information.
- Tthe AAA protocol MUST support for both cumulative, and non-
cumulative, accounting models.
- Support for pre-paid calls
- The AAA accounting messages MUST Separate the "air 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.
- The protocol MUST be able to provide the user with real-time
feedback on the cost of the call.
4.0 Security Considerations
Calhoun et al. expires January 2001 [Page 6]
INTERNET DRAFT July 2000
It is assumed that integrating AAA and IP Telephony 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", IETF work
in progress, draft-ietf-aaa-na-reqts-02.txt, March 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", draft-ietf-
mobileip-aaa-reqs-03.txt, IETF work in progress, March 2000.
[5] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access
Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work
in progress, June 2000.
[6] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location
Protocol, Version 2", RFC 2165, June 1999.
[7] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu-
ary 1999.
[8] H. Schulzrinne, L. Slutsman, I. Faynberg, H. Lu, "Interworking
between SIP and INAP". draft-schulzrinne-sin-00.txt, IETF Work
in Progress, July 2000.
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:
Calhoun et al. expires January 2001 [Page 7]
INTERNET DRAFT July 2000
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
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
Calhoun et al. expires January 2001 [Page 8]
INTERNET DRAFT July 2000
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 (2000). 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 January 2001 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 21:14:43 |