SIPPING Working Group John Loughney
Internet-Draft Nokia
Gonzalo Camarillo
Ericsson
June 30, 2002
SIP-AAA Requirements
< draft-loughney-sip-aaa-req-01.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 December 30, 2002 [Page 1]
Internet-Draft June 30, 2002
Table of Contents
1 Introduction
1.1 Scope of This Document
1.2 Terminology
1.3 Requirements Language
2 Requirements
2.1 Common Requirements
2.2 Authentication Requirements
2.3 Authorization Requirements
2.4 Accounting Requirements
3 Scenarios
3.1 WLAN Roaming Using Third Party Service Providers
3.2 Simple 3GPP Example
4 Security Considerations
5 Acknowledgements
6 References
6.1 Normative
6.2 Non-Normative
7 Authors' Addresses
8 Full Copyright Statement
Loughney, Camarillo expires December 30, 2002 [Page 2]
Internet-Draft June 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].
The applicability of 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].
1.1 Scope of This Document
SIP sessions have needs for session authentication, authorization and
accounting. This document outlines some of the requirements that SIP
has for AAA. This document is intended as a generic document for SIP
AAA requirements.
This document does not intend to develop a charging and/or billing
mechanism for SIP.
One possible use of this document would be to create a basic AAA
application for SIP needs. This could be a Diameter application,
possibly where with Diameter running in Radius-compatibility mode.
There may also be needs for a mechanism for tying this into a Web-
services model.
1.2 Terminology
AAA Authentication, Authorization and Accounting
Accounting In this draft, accounting is meant in a broad
sense, not simply charging or billing.
Home AAA Server Server where user with which the user maintains
an account relationship.
Online Accounting Downloading some kind of credit into the
access device, and deducting from that credit
as usage accumulates.
Offline Accounting Transferring records to a home accounting
server, for later billing and settlement,
Loughney, Camarillo expires December 30, 2002 [Page 3]
Internet-Draft June 30, 2002
without doing any accounting-related control
or feedback for the services rendered.
SIP Session Initiation Protocol
UAC User Agent Client
UAS User Agent Server
Proxies Proxies are nodes which forward requests
and responses as well as make policy decisions.
1.3 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. It is assumed that
different situations, deployment scenarios will affect which
requirements are needed. It is not intended that all requirements
are needed to be supported.
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 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.3 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.4 Call Setup Times
AAA should not unduly burden call setup times where appropriate.
It may be reasonable to support some delay during registration, but
delay during sessions (especially real-time) are problematic.
2.1.5 SIP Server Allocation
Loughney, Camarillo expires December 30, 2002 [Page 4]
Internet-Draft June 30, 2002
The AAA infrastructure or the UAS MUST be able to allocate a SIP
server for a subscriber when required, based on policies, load
distribution etc.
2.1.6 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.7 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.1.5 User De-authorization
The home AAA server MUST be able to inform a SIP server when a
particular user is no longer authorized to perform a particular task,
even if it is an ongoing task.
2.2 Authentication Requirements
2.2.1 Authentication Based on SIP Requests
The home AAA server MUST be able to authenticate a user based on any
SIP request, except CANCEL.
2.2.2 Flexible Authentication of SIP requests
The scheme supported for the authentication between the SIP servers
and the AAA infrastructure MUST be flexible enough to accommodate a
variety of authentication mechanisms.
2.3 Authorization Requirements
2.3.1 Ability to Authorize SIP Registration
It MUST be possible for the Home AAA server to authorize any SIP
request, except CANCEL.
2.3.2 Information transfer
It MUST be possible to transfer a wide range or set of information
needed to make an authorization decision.
2.3.3 Distribution of Profiles
Loughney, Camarillo expires December 30, 2002 [Page 5]
Internet-Draft June 30, 2002
A SIP entity performing authentication, authorization or accounting
MUST be able to access the information needed to perform its task
(e.g., user profile) in the AAA server.
2.3.4 Authorization Based on Policy
The home AAA server MAY authorize 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.4 Accounting Requirements
Accounting is more than simple charging. Accounting may be a simple
list of services accessed, servers accessed, duration of session,
etc. Charging for SIP sessions can be extremely complex and requires
some additional study. It is not the intent of this section to focus
on charging.
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.
Loughney, Camarillo expires December 30, 2002 [Page 6]
Internet-Draft June 30, 2002
2.4.6 Support for Accounting on Different Media Components
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 Stateful and Stateless Accounting
Stateful and stateless accounting MUST be possible.
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 Support for Arbitrary Correlation IDs
Some networks need to be able to relate the accounting to some aspect
of the session. Therefore, there is a need to support arbitrary
correlation IDs.
2.4.10 Support for Accounting Autoconfiguration
The ability support for autoconfiguration (automatic discovery
process of accounting servers, for example) to the SIP node MUST be
supported.
2.4.11 Support of Credit-based Charging
Support for credit-based charging is needed. The accounting
application must be able to check the end user's account for coverage
for the requested service event charge prior to execution of that
service event. All the chargeable events related to a specific
account must be prevented from the end user when the credit of that
account is exhausted or expired.
2.4.11
The scheme supported for the accounting between the SIP servers and
the AAA infrastructure MUST be flexible enough to accommodate a
variety of accounting mechanisms.
3 Scenarios
This section outlines some possible scenarios for SIP and AAA
interaction. These are purely illustrative examples, and do not
impose any requirements.
Loughney, Camarillo expires December 30, 2002 [Page 7]
Internet-Draft June 30, 2002
3.1 WLAN Roaming Using Third Party Service Providers
To be added.
3.2 Simple 3GPP Example
To be added.
4 Security Considerations
This document is informational in nature, so it does not directly
affect the security of the Internet. However, security is a basic
requirement of this work.
5 Acknowledgements
The authors would like to thank the participants of the SIP interim
meeting, May 2002 for their comments. The authors would also thank
Mary Barns, Pete McCann for their comments.
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
[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,
Loughney, Camarillo expires December 30, 2002 [Page 8]
Internet-Draft June 30, 2002
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
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
Loughney, Camarillo expires December 30, 2002 [Page 9]
Internet-Draft June 30, 2002
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIM-
ITED 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 December 30, 2002 [Page 10]