Network Working Group J. Arkko
INTERNET-DRAFT V. Torvinen
draft-uusitalo-sipping-delegation-00.txt I. Uusitalo
Expires: August 2002 Ericsson
February 2002
Requirements for Delegation of Message Protection for SIP
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 Session Initiation Protocol (SIP) is an application-layer
control (signaling) protocol for creating, modifying and terminating
sessions with one or more participants. These sessions include
Internet telephone calls, multimedia distribution and multimedia
conferences. SIP has a number of security mechanisms used for hop-
by-hop or end-to-end message protection. The SIP node handling
authentication and initial message protection may decide, for
efficiency reasons, to delegate subsequent message protection to
another SIP node. In this document we discuss requirements
concerning the delegation of message protection for SIP.
Arkko et al. February 2002 [Page 1]
SIP DELEGATION REQUIREMENTS February 2002
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.
3. Table of contents
1. Abstract........................................................1
2. Conventions used in this document...............................2
3. Table of contents...............................................2
4. Introduction and Motivation.....................................2
5. Requirements....................................................2
6. Discussion......................................................3
7. Acknowledgments.................................................4
8. References......................................................4
9. Author's Address................................................5
4. Introduction and Motivation
A SIP node that shares a security context with a user may decide to
delegate, according to a policy, further message protection after
the initial authentication to another SIP node. This might be
necessary due to e.g. re-allocation of clients for capacity reasons,
or in order to avoid additional authentication in a multi-hop
situation (e.g. via TLS and PKI for the first hop).
An essential part of delegating message protection is the
transportation of keys used for message protection. Since the
security of a system relies on the secrecy of the keys, care has to
be taken to ensure that the keys are transported in a secure manner.
For example, it is not recommended to specify a key transport
mechanism that relies on underlying security because the application
using the keys might not be aware of the security. It is also not
recommended to make bundled key transport features into
authentication mechanisms without confidentiality protection.
It may also be possible to use Kerberos [5] in SIP in the future.
Even though Kerberos tickets are safe as such, the same delegation
and key transport features as proposed in this document may be
needed. This document assumes that keying material and tickets
require the same mechanisms from SIP.
This document is an effort to define requirements applicable for
delegation of message protection with SIP protocol. Most of these
requirements are listed also 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.
5. Requirements
Arkko et al. February 2002 [Page 2]
SIP DELEGATION REQUIREMENTS February 2002
A SIP node may decide, according to a policy, to delegate further
message protection after the initial authentication to another SIP
node. For example, the SIP node delegating further message
protection might be a registrar.
>> Req 1. A SIP node MUST be able to send keying material (or
tickets) to another SIP node.
Performing authentication on all SIP signaling messages would likely
create bottlenecks in the authentication infrastructure. Therefore,
a distributed implementation of security functions responsible for
authentication may be required in some SIP implementations (e.g.
3GPP).
>> Req 2: It SHOULD be possible to perform an initial authentication
based on long-term authentication credentials, followed by
subsequent protected signaling that uses short-term authentication
credentials.
Secret keys and tickets are of importance to a security of a system
and compromising them would be harmful.
>> Req 3. The key transport mechanism MUST protect transferred keys
(or tickets) in a secure manner.
SIP can be transported over different underlying protocols, some of
which offer security while some don't. The application using the
keys is not necessarily aware of lower layer security deployment.
Therefore it is not recommended to specify a key transport mechanism
that relies on the security of the underlying layers.
>> Req 4. The key transport mechanism MUST not depend on the
security of any underlying layers.
6. Discussion
Currently, SIP does not have secure way to transport keying material
or tickets between the SIP nodes. SIP does not include a mechanism
for delegation of security tasks either. SIP body (e.g. SDP) can be
used to carry keying material to protect subsequent multimedia
sessions. It has also been proposed that SIP could be used to carry
keys to protect SIP [2]. Similar requirements may be found if other
similar security credentials, such as tickets or tokens, are
utilized in SIP in the future. For example, the transport of
Kerberos tickets [5] between SIP nodes may be required. Even though
tickets may be secured by some other means, the same transport and
delegation features as proposed in this document may be needed.
The key transport should be specified as an individual function,
with its specific headers or bodies used for transporting the keys
in SIP.
Arkko et al. February 2002 [Page 3]
SIP DELEGATION REQUIREMENTS February 2002
The reliance to lower-layer security schemes in the transport of the
keys is also problematic. Due to the importance of the session keys
for the security of the system, the applications should be aware of
where they are receiving keys. While some SIP implementations may be
able to trust on the underlying network security, a standardized key
transport mechanism is likely to find other users as well, and needs
to prepare for different network cases. For example, a separate
gateway solution is unlikely to provide application layer
information about the source of the keys - it can at most guarantee
that the keys came from one of the sources trusted by the gateway.
In a multi-hop situation, even information provided from an
underlying security mechanism may not be very helpful. Therefore,
the recommendation is that an application layer mechanism is used to
protect key transport. One such mechanism is S/MIME, though also
other possibilities such as XML Digital Signatures exist.
Delegation of security tasks should be somehow integrated as a part
of key transport. In practice, there should be some way to
communicate the purpose for which the transported keys are used.
HTTP authentication framework [6] includes functionality similar to
the delegation requirement. HTTP server may be responsible for
authenticating data that is situated in another server. This basic
delegation mechanism is achieved by using the "opaque" parameter
together with sequential 401 unauthorized and 301/302 redirection
error messages. The servers do not exchange key material, however
the delegating server is able to send delegation-related data to the
delegated server in the "opaque" parameter.
7. 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.
8. References
1. Rosenberg, J., et al., "SIP:Session Initiation Protocol",
draft-ietf-sip-rfc2543bis-05.txt, October 2001, work in
progress.
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/Specs/Latest-drafts/24288-190.zip
Arkko et al. February 2002 [Page 4]
SIP DELEGATION REQUIREMENTS February 2002
5. Kohl, J., Neuman, C., " The Kerberos Network Authentication
Service (V5)", RCF 1510, September 1993.
6. Franks, J., et al., "HTTP Authentication: Basic and Digest
Access Authentication", RFC 2617, June 1999.
9. 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
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
Arkko et al. February 2002 [Page 5]
SIP DELEGATION REQUIREMENTS February 2002
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]
SIP DELEGATION REQUIREMENTS February 2002
Arkko et al. February 2002 [Page 7]