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

Versions: 00 01

SIPPING Working Group                                      John Loughney
Internet-Draft                                                     Nokia
                                                       Gonzalo Camarillo
                                                                Ericsson

                                                          April 30, 2002



                          SIP-AAA Requirements
                   < draft-loughney-sip-aaa-req-00.txt >



Status of this Memo

   This document is an Internet-Draft and is subject to 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Distribution of this memo is unlimited.

   Copyright (C) The Internet Society 2002.  All Rights Reserved.

Abstract

   As SIP services are deployed on the Internet, there is a need for
   authentication, authorization and accounting of SIP sessions.  This
   document sets out the basic requirements for this work.







Loughney, Camarillo     expires October 30, 2002                [Page 1]


Internet-Draft                                            April 30, 2002


Table of Contents

      1     Introduction
      1.1   Terminology
      1.2   Requirements Language

      2     Requirements
      2.1   Common Requirements
      2.2   Authentication Requirements
      2.3   Authorization Requirements
      2.4   Accounting Requirements

      3     Scenarios

      4     Security Considerations

      5     Acknowledgements

      6     References
      6.1   Normative
      6.2   Non-Normative

      7     Authors' Addresses

      8     Full Copyright Statement


























Loughney, Camarillo     expires October 30, 2002                [Page 2]


Internet-Draft                                            April 30, 2002


1  Introduction

   The AAA working group is chartered to work on authentication,
   authorization and accounting solutions for the Internet, which
   consists of a base protocol, applications, end-to-end security
   application and a general architecture for providing these services
   [AAA-PROB, DIAM-BASE].

   The applicability of Diameter and AAA-based solutions for a number of
   protocols have been specified, for example the AAA requirements for
   Mobile IP [MIP-AAA].

   SIP provides a signaling protocol for creating, modifying and
   terminating different types sessions such as Internet phone calls,
   multimedia distribution and multimedia conferences [SIP, SIP-BIS].

   SIP sessions have needs for session authentication, authorization and
   accounting (i.e. - payment).  This document outlines some of the
   requirements that SIP has for AAA.

1.1 Terminology

   AAA     Authentication, Authorization and Accounting

   SIP     Session Initiation Protocol.

1.2 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 [KEYWORDS].

2  Requirements

   In this section, we list the requirements.

2.1 Common Requirements

2.1.1 Ability To Integrate Different Networks, Services and Users

   The basic AAA architecture allows for the support of different access
   methods and technologies.  Service providers MUST be able to provide
   AAA services for SIP irrespective of access method or technology.

2.1.2 Distribution of Profiles

   The AAA infrastructure MUST be able to distribute profiles (such as
   subscriber, service, security, etc.) to the relevant SIP servers,



Loughney, Camarillo     expires October 30, 2002                [Page 3]


Internet-Draft                                            April 30, 2002


   based on local policies.

2.1.3 Updating SIP Server Entries

   The home AAA server MUST be able to update the entry of the assigned
   SIP server for the user when required.

2.1.4 Indication of Assigned Server

   The home AAA server MUST be able to provide the assigned server of
   the user to the SIP entities requesting it.

2.1.5 User Deregistration

   The home AAA server MUST be able to initiate de-registration of the
   user.

2.1.6 SIP Server Allocation

   The AAA infrastructure or the home entry SIP Proxy MUST be able to
   allocate a SIP server for a subscriber when required, based on
   policies, load distribution etc.

2.1.7 Ability to Provide Session Information to the Parties Involved

   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.

2.1.8 Security

   AAA data MUST be able to be securely transported. The endpoints MUST
   be authenticated before data is sent. The endpoints MAY be authorized
   to access certain types of AAA data.

2.2 Authentication Requirements

2.2.1 Authentication Based on SIP REGISTER

   The home AAA server MAY authenticate a user based on the
   corresponding SIP REGISTER method.

2.2.2 Flexible Authentication

   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.



Loughney, Camarillo     expires October 30, 2002                [Page 4]


Internet-Draft                                            April 30, 2002


2.2.2 Authentication Based on Policy

   The home AAA server MAY authenticate a session (the end result of a
   successful SIP INVITE method); implementing whatever policy it
   wishes, such as based upon time of day, distance, etc.

2.3 Authorization Requirements


2.3.1 Ability to Authorize SIP Registration

It MUST be possible for the Home AAA server to authorize SIP
registration.

2.4 Accounting Requirements

2.4.1 Separation of Accounting Information

   AAA accounting messages MUST be able separate "session duration"
   information from other information generated via additional services
   (e.g. 3-way calling, etc.)

2.4.2 Accounting Information Related to Session Progression

   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.

2.4.3 Accounting Information Not Related to Session Progression

   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.

2.4.4 Support for One-Time and Session-based Accounting Records

   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.

2.4.5 SIP Session Changes

   Accounting messages MUST be able to reflect changes in the SIP
   session that affects the charging of SIP session.

2.4.6 Support for Accounting on Different Media Components




Loughney, Camarillo     expires October 30, 2002                [Page 5]


Internet-Draft                                            April 30, 2002


   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.

2.4.7 Support for Cumulative and Non-Cumulative Accounting

   Both cumulative and non-cumulative accounting model MUST be supported

2.4.8 Configuration of Accounting Generation Parameters

   Parameters for accounting generation must be either configurable in
   the SIP servers or communicated by the AAA servers.

2.4.9 Ability to Relate SIP Session to Access Bearer Used

   The ability to relate the accounting for SIP session to the bearer in
   the access network MUST be supported.

2.4.10 Ability to Transfer Accounting Server Information

   The ability to transfer accounting server information, i.e. address
   of the accounting servers (online, offline), to the SIP node MUST be
   supported.

3  Scenarios


4  Security Considerations

   This document is informational in nature, so it does not directly
   affect the security of the Internet.  It should be noted that the
   security considerations of Diameter and of SIP MUST be followed.

5  Acknowledgements

   The authors would like to thank the authors of the "AAA Requirements
   for IP Telephony/Multimedia" draft, which some of the information in
   this document is based on.

6  References

6.1  Normative


   [DIAM-BASE] P. Calhoun, et. al, "Diameter Base Protocol." Work In
               Progress.





Loughney, Camarillo     expires October 30, 2002                [Page 6]


Internet-Draft                                            April 30, 2002


   [KEYWORDS]  S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.


   [SIP]       M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg,
               "SIP: Session Initiation Protocol". RFC 2543, March 1999.


   [SIP-BIS]   J. Rosenberg, et. al, "SIP: Session Initiation Protocol".
               Work in Progress.

6.2  Non-Normative


[AAA-PROB]  P. Calhoun, et. al, "AAA Problem Statements".  Work in Pro-
            gress.


[MIP-AAA]   S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
            Authorization, and Accounting Requirements". RFC 2977,
            October 2000.


7  Authors' Addresses

   Questions about this memo can be directed to:

    John Loughney
    Nokia Research Center
    Itämerenkatu 11-13
    00180 Helsinki
    Finland

    Phone:  +358 50 483 6242
    E-mail: john.Loughney@nokia.com

    Gonzalo Camarillo
    Ericsson
    Advanced Signalling Research Lab.
    FIN-02420 Jorvas
    Finland

    Phone: +358 9 299 3371
    Fax:   +358 9 299 3052
    Email: Gonzalo.Camarillo@ericsson.com


8  Full Copyright Statement



Loughney, Camarillo     expires October 30, 2002                [Page 7]


Internet-Draft                                            April 30, 2002


   Copyright (C) The Internet Society (2002).  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.





























Loughney, Camarillo     expires October 30, 2002                [Page 8]


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