Network Working Group J. Arkko
INTERNET-DRAFT V. Torvinen
draft-uusitalo-sipping-authentication-00.txt I. Uusitalo
Expires: August 2002 Ericsson
February 2002
3GPP Requirements for SIP Authentication
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
1. Abstract
The 3rd Generation Partnership Project (3GPP) has selected Session
Initiation Protocol (SIP) [1] as the session establishment protocol
for the 3GPP IP Multimedia Core Network Subsystem. This document
discusses requirements identified by 3GPP concerning SIP
authentication methods.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in
this document are to be interpreted as described in [RFC 2119].
Arkko et al. February 2002 [Page 1]
SIP AUTHENTICATION REQUIREMENTS January 2002
3. Table of contents
1. Abstract........................................................1
2. Conventions used in this document...............................1
3. Table of contents...............................................2
4. Introduction and Motivation.....................................2
5. Definitions.....................................................3
6. Requirements....................................................3
7. Discussion......................................................4
8. Acknowledgments.................................................4
9. References......................................................4
10. Author's Address...............................................5
4. Introduction and Motivation
3GPP has selected SIP [1] as the protocol to establish and tear down
multimedia sessions in the IP Multimedia Core Network Subsystem (IM
CN Subsystem). See [3] for a description of the IP CN Subsystem. A
comprehensive set of session flows can be found in [4].
This document is an effort to define requirements applicable for
authentication methods used with SIP protocol, particularly in the
3GPP IM CN Subsystem. The requirements are listed in "3GPP
Requirements on SIP" [2], but we consider them to be beneficial also
to infrastructures other than 3GPP. Therefore they've been separated
into this new draft that's easier to deal with. In addition to [2],
also [8] list general requirements identified by 3GPP to support SIP
for IM CN Subsystem in cellular networks.
Authentication and Key Agreement (AKA) [5] is an authentication and
session key distribution protocol defined by the 3GPP. It is based
on a challenge-response mechanism and symmetric cryptography. AKA
typically runs in smart card devices like the ISIM, but it can be
implemented also in host software. AKA provides mutual
authentication by the ISIM and the home environment showing
knowledge of a secret key K that is shared between and available
only to the two parties.
AKA operates in the following manner:
- The ISIM and the home environment (HE) have agreed on the secret
key K beforehand.
- The end-user terminal including the ISIM and the home environment
are communicating over an insecure channel.
- The HE produces an authentication vector basically based on K, a
random number RAND and on a sequence number SQN. The authentication
vector consists of a random part RAND, an authenticator part AUTN
used by the ISIM for authenticating the HE to the ISIM, an expected
result XRES, a session key IK for integrity check, and a session key
CK for encryption.
Arkko et al. February 2002 [Page 2]
SIP AUTHENTICATION REQUIREMENTS January 2002
- The RAND and AUTN are delivered to the ISIM
- The ISIM uses K and the SQN to verify the AUTN. If
this operation is successful, the ISIM calculates IK and CK from K
and RAND using the same key generating functions as the HE. The ISIM
calculates also the response, RES, from K and the RAND and sends
this to the HE.
- The HE verifies the result from the ISIM. If the result is
correct, IK and CK can be used to protect further communications
ISIM calculates IK and CK from RAND using key generating functions.
See [5] for further details on AKA.
5. Definitions
AKA: Authentication and Key Agreement
ISIM: IM Services Identity Module
UMTS: Universal Mobile Telecommunications System
6. Requirements
3GPP SIP capable terminals possess SIM-cards (ISIM) to securely
store identity information and e.g. shared secret keys shared with
the home environment. It is necessary to re-use authentication based
on the shared key stored in ISIM also with SIP authentication.
Significant costs are involved in building a large, global security
infrastructure that involves hundreds of millions of secure tamper-
proof devices, many authentication servers, procedures, personnel,
and equipment to distribute passwords or tokens to users, and so on.
It is necessary to be able to re-use an existing infrastructure
built for another purpose also when the same terminals are used for
multimedia communications and need authenticate their SIP signaling.
>> Req 1: AKA authentication MUST be supported with SIP.
AKA needs to follow the regular SIP authentication such that the
authentication can be performed not just for hop-by-hop but also in
other cases.
>> Req 2: AKA authentication in SIP MUST support end-to-middle, end-
to-end as well as hop-by-hop authentication.
Initial authentication is performed between the SIP UA and the
authenticating SIP proxy or registrar residing in the home network.
However, the authentication method must not require knowledge of the
long-term authentication credentials in these nodes. It must be
possible to delegate the actual authentication task to a central
server. This is necessary in order to avoid duplicating the shared
Arkko et al. February 2002 [Page 3]
SIP AUTHENTICATION REQUIREMENTS January 2002
AKA secrets in a SIP server farm, and to ensure that the storage of
the secrets is kept in specialized nodes.
>> Req 3: AKA authentication in SIP MUST NOT require access to long-
term authentication credentials in the SIP and it MUST be possible
to delegate the authentication task to e.g. an AAA node.
7. Discussion
AKA will be used in thin devices such as PDAs or mobile terminals.
Resources are limited in such devices, so authentication using only
symmetric methods must be possible. Asymmetric cryptography and
certificates could be optionally used but their use should not be
mandated. Also, in cellular networks bandwidth is limited, so the
authentication method should have a small amount of roundtrips. The
authentication shouldn't have a noticeable negative impact on the
session setup delay.
TLS [7] doesn't fulfil the requirements of chapter 6. For example,
TLS provides hop-by-hop authentication, but not the other two
mentioned in requirement 2. Work conducted at IETF IPsec Remote
Access working group (IPSRA) doesn't suite to requirements above
either.
Providing AKA for SIP can be done in several ways. One approach is
to provide AKA for one of the general authentication frameworks in
IETF such as EAP, SASL, or GSS_API, and then allow that framework to
be used in SIP. An example of this approach is in [9]. Another
approach is to provide AKA as a new algorithm under the existing
Digest framework in SIP, as described in [10]. Recent discussions
with IETF authentication experts indicate that the latter approach
may be preferable, as it can be progressed to an RFC status faster
and without discussions on which of the general frameworks should be
selected. It also results in less likely interoperability problems
as there isn't as much freedom to implement different authentication
schemes as there is in the general frameworks. In the long run, it
is also expected that application layer protocols will all migrate
to the use of certificates and tickets when sufficient CPU and
communication bandwidth becomes available.
8. Acknowledgments
We would like to thank Allison Mankin, Dean Willis, Rohan Mahy,
Bernard Aboba, Miguel Garcia, as well as numerous people at 3GPP SA3
and Ericsson for interesting discussions in this problem space.
9. References
1. Rosenberg, J., et al., "SIP:Session Initiation Protocol",
draft-ietf-sip-rfc2543bis-05.txt, October 2001, work in
progress.
Arkko et al. February 2002 [Page 4]
SIP AUTHENTICATION REQUIREMENTS January 2002
2. Garcia, M., et al., "3GPP requirements on SIP", draft-garcia-
sipping-3gpp-regs-02.txt, November 2001, work in progress.
3. 3GPP TS 23.228: "IP Multimedia (IM) Subsystem (Stage 2) -
Release 5". Version 5.3.0 is available at
ftp://ftp.3gpp.org/Specs/2001-12/Rel-5/23_series/23228-530.zip
4. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call
control based on SIP and SDP". Version 1.9.0 is available at
ftp://ftp.3gpp.org/tsg_cn/WG1_mm-cc-sm/TSGN1_22/Docs/N1-
020280_24228-190.zip
5. 3GPP TS 33.102: "Security Architecture (Release 4)". Version
4.3.0 is available at ftp://ftp.3gpp.org/Specs/2001-12/Rel-
4/33_series/33102-430.zip
6. Franks, J., et al., "HTTP Authentication: Basic and Digest
Access Authentication", RFC 2617, June 1999
7. Dierks, T., Allen, C., "The TLS Protocol, Version 1.0", RCF
2246, January 1999
8. 3GPP TS 33.203: "Access security for IP-based services (Release
5)". Version 1.00 is available at
ftp://ftp.3gpp.org/Specs/Latest-drafts/33203-100.zip
9. Arkko, J., Torvinen, V., Niemi, A., "HTTP Authentication with
EAP", draft-torvinen-http-eap-01.txt, November 2001, work in
progress.
10. Arkko, J., Torvinen, V., Niemi, A., "HTTP Digest
Authentication using AKA", draft-niemi-sip-digest-aka-00.txt,
to appear.
10. Authors' Addresses
Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Vesa Torvinen
Oy LM Ericsson Ab
Joukahaisenkatu 1
20520 Turku
Finland
Phone: +358 40 7230822
EMail: vesa.torvinen@ericsson.fi
Arkko et al. February 2002 [Page 5]
SIP AUTHENTICATION REQUIREMENTS January 2002
Ilkka Uusitalo
Oy LM Ericsson Ab
Tutkijantie 2C
90570 Oulu
Finland
Phone: +358 40 7245404
EMail: ilkka.uusitalo@ericsson.fi
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
document 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
developing 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 limited 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 DISCLAIMS 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.
Arkko et al. February 2002 [Page 6]