[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

INTERNET DRAFT                                           Henrik Basilier
Category: Informational                                   Ericsson, Inc.
Title: draft-calhoun-sip-aaa-reqs-03.txt                  Pat R. Calhoun
Date: Oct 2001                                      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 March 2002                   [Page 1]


INTERNET DRAFT                                                  Oct 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 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.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 March 2002                   [Page 2]


INTERNET DRAFT                                                  Oct 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 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 March 2002                   [Page 3]


INTERNET DRAFT                                                  Oct 2001


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 March 2002                   [Page 4]


INTERNET DRAFT                                                  Oct 2001


       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.











Calhoun et al.             expires March 2002                   [Page 5]


INTERNET DRAFT                                                  Oct 2001


   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
   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.

   Additionally, for different reasons (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.
















Calhoun et al.             expires March 2002                   [Page 6]


INTERNET DRAFT                                                  Oct 2001


                      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 March 2002                   [Page 7]


INTERNET DRAFT                                                  Oct 2001


   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.






Calhoun et al.             expires March 2002                   [Page 8]


INTERNET DRAFT                                                  Oct 2001


   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
   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.

   For different reasons (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,
   and how a session is setup. 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.




Calhoun et al.             expires March 2002                   [Page 9]


INTERNET DRAFT                                                  Oct 2001


2.3.1  Invitation terminating in the mobile node
                   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).





Calhoun et al.             expires March 2002                  [Page 10]


INTERNET DRAFT                                                  Oct 2001


   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 Server.

   When the SIP session is established, the SIP servers MAY initiate
   accounting records, which are transferred to the AAA infrastructure.
   The accounting records should include usage information, which is
   necessary for billing purposes. The traditional telco world currently
   makes use of, 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.

   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.





























Calhoun et al.             expires March 2002                  [Page 11]


INTERNET DRAFT                                                  Oct 2001


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 March 2002                  [Page 12]


INTERNET DRAFT                                                  Oct 2001


   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.

   When the SIP session 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 currently
   makes use of, 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.

   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.

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 infrastructure MUST be able to distribute user and/or
         network policy information to the SIP servers/proxies.




Calhoun et al.             expires March 2002                  [Page 13]


INTERNET DRAFT                                                  Oct 2001


       3. The AAAH MAY authenticate a user, and MAY authorize a user and
         the session being requested. The AAAH may implement whatever
         policy it wishes on authorizing the session, such as time of
         day, long 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

       5. The AAAH MUST be able to update the entry for the assigned SIP
         server for the user performing SIP registration to the DSI
         database.

       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 protocol MUST provide support for both cumulative,
         and non-cumulative, accounting models.

       12. The AAA accounting messages MUST separate the "session
         duration time" information from those generated via additional
         services (e.g. 3-way calling, etc.)

       13. There MUST be support for real-time and non-real time
         accounting data transfers.










Calhoun et al.             expires March 2002                  [Page 14]


INTERNET DRAFT                                                  Oct 2001


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
     Progress, July 2000.

[8]  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.








Calhoun et al.             expires March 2002                  [Page 15]


INTERNET DRAFT                                                  Oct 2001


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


      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






Calhoun et al.             expires March 2002                  [Page 16]


INTERNET DRAFT                                                  Oct 2001


      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

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 March 2002                  [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/