INTERNET DRAFT Henrik Basilier Category: Informational Ericsson, Inc. Title: draft-calhoun-sip-aaa-reqs-01.txt Pat R. Calhoun Date: November 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 May 2001 [Page 1] INTERNET DRAFT November 2000 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 May 2001 [Page 2] INTERNET DRAFT November 2000 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 [13]. 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 May 2001 [Page 3] INTERNET DRAFT November 2000 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 foreign 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 explicitely 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]. There could be several methods for a mobile node to find its SCPC 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 May 2001 [Page 4] INTERNET DRAFT November 2000 Home Network +--------+ +----------+ +------->|xyz.com |<----->| xyz.com | | | AAAH |<--+ | Location | | +--| server +-+ | | Database | | | +--------+ | | +----------+ | | | | ^ 4.AAA|3.AAA| 5.AAA| |2.AAA | Rsp| Req| Rsp| | Req | | v v | v +--+--------+ 6. SIP +---+---------+ | Anchor | Reg.| SIP | |Softswitch/|<-------+ Central | | SIP | | Point of | | Proxy +------->| Contact | +-----------+7.200 OK+--+----------+ | ^ | | 8.200 OK| | 1. SIP Register | | | | v | +-------+-+ | SIP | | Client | bob@xyz.com +---------+ Figure 1: SIP Registration When the SIP client issues its SIP Register message to the SCPC within its home network, a AAA message is issued 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 client, and to determine whether it authorizes the client to access the service. If the AAAH determines that its clock, and that of the client, is synchronized, as evidenced by the Timestamp header field, it MAY process the message with some assurances that the message is not a replay of an old message. However, 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. Calhoun et al. expires May 2001 [Page 5] INTERNET DRAFT November 2000 Home Network +--------+ +----------+ +------->|xyz.com |<----->| xyz.com | | | AAAH |<--+ | Location | | +--| server +-+ | | Database | | | +--------+ | | +----------+ | | | | ^ 4.AAA|3.AAA| 5.AAA | |2.AAA | Rsp| Req| Response| | Req | | v v | v +--+--------+ +---+---------+ | Anchor | | SIP | |Softswitch/| | Central | | SIP | | Point of | | Proxy | | Contact | +--+--------+ +----+--------+ | ^ | ^ | | | | | | | | 1. SIP Register | | 6.Redirect| | | | | | | |7.SIP v | | | Register +-------+-+ | +-----------+ SIP | +---------------->| Client | bob@xyz.com 8.200 OK +---------+ Figure 2: SIP Registration with redirect. The SCPC MAY select an Anchor SIP proxy for the user, in such a case it MUST pass the address of the selected Anchor to the AAAH. 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 centralized SIP Server (the one that generated the AAA message) 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 Calhoun et al. expires May 2001 [Page 6] INTERNET DRAFT November 2000 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 [9]. 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. It then responds back to the SCPC and passes the address of the assigned Anchor SIP proxy. The SCPC then proxies the registration message to the Anchor SIP proxy, which responds with a 200 OK message. If security information and other necessary information (e.g. Service Profile) has not been pushed to the Anchor SIP proxy, the Anchor SIP proxy MAY pull this information from the AAAH. This sequence is not illustrated in any of the figures. 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 mobile node, sending it the address of the Anchor SIP proxy. The mobile 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. 2.2 Invitation In this section, we will look at the details of a SIP invite message, Calhoun et al. expires May 2001 [Page 7] INTERNET DRAFT November 2000 and how a call is setup. Although it cannot be forbidden, it is assumed that the SIP Servers do not share pre-existing security association, either implicitely or via the AAA infrastructure. This allows SIP sessions to be established from users that are not members of the AAA infrastructure. 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 an example 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) Calhoun et al. expires May 2001 [Page 8] INTERNET DRAFT November 2000 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 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 call, 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. Calhoun et al. expires May 2001 [Page 9] INTERNET DRAFT November 2000 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. 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. Calhoun et al. expires May 2001 [Page 10] INTERNET DRAFT November 2000 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 call, 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 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 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. - 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 Calhoun et al. expires May 2001 [Page 11] INTERNET DRAFT November 2000 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 call, 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: Ses- sion 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 Lev- els", BCP 14, RFC 2119, March 1997. [4] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho- rization, 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 Pro- tocol, Version 2", RFC 2165, June 1999. Calhoun et al. expires May 2001 [Page 12] INTERNET DRAFT November 2000 [7] Aboba, Beadles "The Network Access Identifier." RFC 2486. January 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. [9] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" RFC 1409, November 1998. 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. Calhoun et al. expires May 2001 [Page 13] INTERNET DRAFT November 2000 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 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 Calhoun et al. expires May 2001 [Page 14] INTERNET DRAFT November 2000 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 May 2001 [Page 15]