Internet Engineering Task Force J. Arkko
MMUSIC Working Group E. Carrara
INTERNET-DRAFT F. Lindholm
Expires: May 2002 M. Naslund
K. Norrman
Ericsson
November, 2001
Key Management Extensions for SDP and RTSP
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Work for securing real-time applications have started. It has also
brought toward the need for a key management infrastructure to
support the security protocol.
This document defines extensions for SDP and RTSP to carry the
security information needed by a key management protocol, in order to
secure the media stream itself.
Arkko, et al. [Page 1]
INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001
TABLE OF CONTENTS
1. Introduction..................................................2
1.1. Notational Conventions......................................3
2. SDP Attribute Fields for Key Management.......................3
2.1. SDP Grammar.................................................4
2.2. SDP in SIP and RTSP.........................................5
3. RTSP Header and Grammar.......................................5
4. Security Considerations.......................................6
5. IANA Considerations...........................................6
6. Conclusions...................................................7
7. Acknowledgments...............................................7
8. Author's Addresses............................................7
9. References....................................................7
1. Introduction
There has recently been work to define a security framework for the
protection of real-time applications running over RTP, [SRTP].
However, a security protocol needs a key management infrastructure to
exchange keys and security parameters, managing and refreshing keys,
etc.
The Session Description Protocol [SDP] is used to convey
advertisements of conference sessions and communicate the relevant
conference setup information to prospective participants. SDP is
intended to use different transport protocols as appropriate, e.g.
the Session Initiation Protocol [SIP] and the Real-Time Streaming
Protocol [RTSP].
An efficient way of performing key management is to integrate it into
SDP. This approach may reduce the number of roundtrips compared to a
standalone key management scheme (and in some cases it could also
reduce the total bandwidth consumption). However, to make it possible
to integrate the key management protocol (e.g. [MIKEY]) into SDP, a
set of attributes in SDP is needed. Such a set of attributes is
defined in this document to support integrated media stream key
management.
Currently in SDP, one field exists to transport keys, i.e. the "key="
field. However, this is not enough for a key management protocol.
There MUST exist the possibility to include not only the key, but
also the key encrypted, encryption parameters, security protocol
parameters, and at the same time have it all authenticated. This can
not be done with the "key=" field as specified today.
In RTSP, the SDP description is mainly used in the response to the
DESCRIBE method. This makes it hard to send key management messages
back from the client to the server. Therefore, this draft also
Arkko, et al. [Page 2]
INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001
defines an RTSP header that may be used to carry additional key
management messages.
1.1. Notational Conventions
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.
2. SDP Attributes for Key Management
This subsection describes common attributes that are to be included
in the SDP description when an integrated key management protocol is
used. All attribute values MUST follow the general SDP guidelines.
The attributes are designed to give a minimal impact on SDP, i.e.
only a minimal set of "knowledge" MUST be built into an existing SDP
stack in order to support the key management.
Three SDP attributes are defined.
To be able to detect the key management protocol applied, this MUST
be signaled by:
a=keymgmt-prot:<protocol>
The key management protocol data MUST be provided in the following
field:
a=keymgmt-data:<key-transport-data>
Note that the data MUST be encoded in a way so that it complies with
the normal SDP rules.
In case the key management mechanism does not provide authentication
of the key management part, additional authentication data MAY be
provided in the "keymgmt-auth" field.
a=keymgmt-auth:<key-auth-data>
The key management attributes may be defined both at the session
level (i.e. before the media descriptor lines) and at the media level
of the SDP description. If the key management attributes are defined
at media level, it will only apply to that specific media. If the key
management attributes are defined at both session and media level,
the media level definition overrides the session level definition for
that specific media.
Arkko, et al. [Page 3]
INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001
Example 1 (session level)
a=keymgmt-prot:MIKEY
a=keymgmt-data:uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 2232 RTP/SAVP 31
In this example, MIKEY is negotiating the crypto suite for both
streams at session level. It is recommended to use this approach if
possible to save both bandwidth and computational resources.
Example 2 (media level)
m=audio 49000 RTP/SAVP 98
a=keymgmt-prot:MIKEY
a=keymgmt-data:uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
a=rtpmap:98 AMR/8000
m=video 2232 RTP/AVP 31
Note that the video part in this example is not protected by any
security protocol.
2.1. SDP Grammar
This section provides an Augmented Backus-Naur Form (ABNF) grammar
(as used in [SDP]) for the key management extensions to SDP.
Note that the new definitions are compliant with the definition of an
attribute field, i.e.
attribute = (att-field ":" att-value) | att-field
Three new attributes are defined, keymgmt-prtcl, keymgmt-data, and
key-extra-auth.
keymgmt-prtcl = "keymgmt-prot:" prtcl-name
prtcl-name = 1*(alpha-numeric|SAFE)
; e.g. "MIKEY"
keymgmt-data = "keymgmt-data:" byte-string
key-extra-auth = "keymgmt-auth:" byte-string
byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
;any byte except NUL, CR or LF
Arkko, et al. [Page 4]
INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001
alpha-numeric = ALPHA | DIGIT
DIGIT = "0" | POS-DIGIT
POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|
"l"|"m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|
"w"|"x"|"y"|"z"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|
"H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|"Q"|"R"|
"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"
SAFE = "\$" | "-" | "_" | "." | "+"
2.2. SDP in SIP and RTSP
Both SIP and RTSP provide means to transport SDP descriptions. This
section gives a recommendation of how/when to include key management
initiated SDP descriptions in SIP and RTSP.
For SIP, the recommendation is to use the Invite message (and the
following response) to transport the SDP description with the key
management parameters.
For RTSP, the recommendation is to let the server include a SDP
description with the key management parameters in the response to a
DESCRIBE message. A problem with RTSP is that no SDP description can
be assumed to be sent back to the server. Therefore, other means to
send key management messages between client and server is needed.
This may be solved by using the new RTSP header defined in Section 3.
In general, any key management protocol using SDP as a mean of
transport, MUST not require a great number of exchange messages. It
is RECOMMENDED that the key management protocol does not use more
than one roundtrip. This is to create as small (if any) impact as
possible on the underlying transporting mechanism (e.g., SIP and
RTSP).
3. RTSP Header and Grammar
To support the three different parameters described in Section 2, a
new RTSP header is defined.
KeyMgmt = "KeyMgmt" ":" [stream-url] protocol data [auth]
stream-url = "url" "=" url ";"
protocol = "Prot" "=" prtcl-name
Arkko, et al. [Page 5]
INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001
data = ";" "Data" "=" string
auth = ";" "Auth" "=" string
string = 1*(alpha-numeric|SAFE|"=")
alpha-numeric, SAFE and prtcl-name are as defined in Section 2.1. The
url indicates the stream URL for which the parameters correspond to.
It is recommended that the string is a base64 encoded value.
The new key management header should be possible to use in both
request and response messages of the following methods:
* ANNOUNCE
* SETUP
* PLAY
* RECORD
* SET_PARAMETER
* GET_PARAMETER
* OPTIONS
When a key management protocol is enabled in the RTSP implementation,
it MUST for each message to be sent (that may contain the KeyMgmt
header), check with the key management protocol if any parameters(s)
should be include in the header (i.e. the Data or Auth parameter).
For each message received (that contains the KeyMgmt header), the key
management parameters (Data and Auth) are passed to the key
management protocol for processing.
4. Security Considerations
The nature of this document is to allow SDP and RTSP support for
security of the media sessions. It is therefore not the intention of
this document to describe possible security solution nor define
possible security problems. The defined SDP and RTSP extensions are
not believed to introduce any new security risks to SDP and RTSP.
Note that the purpose of the key management fields is to secure the
media streams themselves. Provided that the key management schemes
are secure, the SDP payloads can be passed along unprotected, and the
media streams will still be secure even if some attackers gained
knowledge of the SDP contents. There may, however, be other reasons
to protect the SDP payloads such as preventing attackers from gaining
any information regarding the session or the used equipment.
5. IANA Considerations
Three new attributes fields for SDP (see Section 2) and one new RTSP
header are registered (see Section 3).
Arkko, et al. [Page 6]
INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001
6. Conclusions
A security solution for real-time applications needs a key management
infrastructure. Integrating the key management scheme with the
session establishment protocol could be done efficiently in most of
the scenarios. This document defines extensions to SDP and RTSP so
that it will be possible to integrate a key management protocol (e.g.
MIKEY) into protocol such as SIP and RTSP.
7. Acknowledgments
Thanks to: Joerg Ott, Colin Perkins, Magnus Westerlund, and the rest
involved in the MMUSIC WG and the MSEC WG.
8. Author's Addresses
Jari Arkko
Ericsson
02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com
Elisabetta Carrara
Ericsson Research
SE-16480 Stockholm Phone: +46 8 50877040
Sweden EMail: elisabetta.carrara@era.ericsson.se
Fredrik Lindholm
Ericsson Research
SE-16480 Stockholm Phone: +46 8 58531705
Sweden EMail: fredrik.lindholm@era.ericsson.se
Mats Naslund
Ericsson Research
SE-16480 Stockholm Phone: +46 8 58533739
Sweden EMail: mats.naslund@era.ericsson.se
Karl Norrman
Ericsson Research
SE-16480 Stockholm Phone: +46 8 4044502
Sweden EMail: karl.norrman@era.ericsson.se
9. References
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Norrman, K., "MIKEY: Multimedia Internet KEYing", Internet Draft,
IETF, Work in progress (MSEC).
Arkko, et al. [Page 7]
INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001
[RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[SDP] Handley, M., and Jacobson, V., "Session Description Protocol
(SDP)", IETF, RFC2327
[SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J.,
"SIP: Session Initiation Protocol", IETF, RFC2543.
[SRTP] Blom, R., Carrara, E., McGrew, D., Naslund, M, Norrman, K.,
and Oran, D., "The Secure Real Time Transport Protocol", Internet
Draft, IETF, Work in Progress (AVT).
This Internet-Draft expires in May 2002.
Arkko, et al. [Page 8]
