Request for Comments: 4567 F. Lindholm
Category: Standards Track M. Naslund
K. Norrman
Ericsson
E. Carrara
Royal Institute of Technology
July 2006
Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines general extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry
messages, as specified by a key management protocol, in order to
secure the media. These extensions are presented as a framework, to
be used by one or more key management protocols. As such, their use
is meaningful only when complemented by an appropriate key management
protocol.
General guidelines are also given on how the framework should be used
together with SIP and RTSP. The usage with the Multimedia Internet
KEYing (MIKEY) key management protocol is also defined.
Table of Contents
1. Introduction ....................................................3
1.1. Notational Conventions .....................................4
2. Applicability ...................................................4
3. Extensions to SDP and RTSP ......................................5
3.1. SDP Extensions .............................................5
3.2. RTSP Extensions ............................................6
4. Usage with SDP, SIP, RTSP, and SAP ..............................7
4.1. Use of SDP .................................................8
4.1.1. General Processing ..................................8
4.1.2. Use of SDP with Offer/Answer and SIP ...............10
4.1.3. Use of SDP with SAP ................................13
4.1.4. Bidding-Down Attack Prevention .....................13
4.2. RTSP Usage ................................................14
5. Example Scenarios ..............................................17
5.1. Example 1 (SIP/SDP) .......................................17
5.2. Example 2 (SDP) ...........................................18
5.3. Example 3 (RTSP) ..........................................18
5.4. Example 4 (RTSP) ..........................................20
6. Adding Further Key Management Protocols ........................21
7. Integration of MIKEY ...........................................22
7.1. MIKEY Interface ...........................................22
8. Security Considerations ........................................23
9. IANA Considerations ............................................25
9.1. SDP Attribute Registration ................................25
9.2. RTSP Registration .........................................26
9.3. Protocol Identifier Registration ..........................26
10. Acknowledgements ..............................................27
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................28
1. Introduction
There has recently been work to define a security profile for the
protection of real-time applications running over RTP, [SRTP].
However, a security protocol needs a key management solution to
exchange keys and security parameters, manage and refresh keys, etc.
A key management protocol is executed prior to the security
protocol’s execution. The key management protocol’s main goal is to,
in a secure and reliable way, establish a security association for
the security protocol. This includes one or more cryptographic keys
and the set of necessary parameters for the security protocol, e.g.,
cipher and authentication algorithms to be used. The key management
protocol has similarities with, e.g., SIP [SIP] and RTSP [RTSP] in
the sense that it negotiates necessary information in order to be
able to set up the session.
The focus in the following sections is to describe a new SDP
attribute and RTSP header extension to support key management, and to
show how these can be integrated within SIP and RTSP. The resulting
framework is completed by one or more key management protocols, which
use the extensions provided.
Some of the motivations to create a framework with the possibility to
include the key management in the session establishment are:
* Just as the codec information is a description of how to encode and
decode the audio (or video) stream, the key management data is a
description of how to encrypt and decrypt the data.
* The possibility to negotiate the security for the entire multimedia
session at the same time.
* The knowledge of the media at session establishment makes it easy
to tie the key management to the multimedia sessions.
* This approach may be more efficient than setting up the security
later, as that approach might force extra roundtrips, possibly also
a separate setup for each stream, hence implying more delay to the
actual setup of the media session.
* The possibility to negotiate keying material end-to-end without
applying end-to-end protection of the SDP (instead, hop-by-hop
security mechanisms can be used, which may be useful if
intermediate proxies need access to the SDP).
Currently in SDP [SDPnew], there exists one field to transport keys,
the "k=" field. However, this is not enough for a key management
protocol as there are many more parameters that need to be
transported, and the "k=" field is not extensible. The approach used
is to extend the SDP description through a number of attributes that
transport the key management offer/answer and also to associate it
with the media sessions. SIP uses the offer/answer model [OAM]
whereby extensions to SDP will be enough. However, RTSP [RTSP] does
not use the offer/answer model with SDP, so a new RTSP header is
introduced to convey key management data. [SDES] uses the approach
of extending SDP, to carry the security parameters for the media
streams. However, the mechanism defined in [SDES] requires end-to-
end protection of the SDP by some security protocol such as S/MIME,
in order to get end-to-end protection. The solution described here
focuses only on the end-to-end protection of key management
parameters and as a consequence does not require external end-to-end
protection means. It is important to note though, and we stress this
again, that only the key management parameters are protected.
The document also defines the use of the described framework together
with the key management protocol Multimedia Internet KEYing (MIKEY)
[MIKEY].
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 [RFC2119].
2. Applicability
[SDES] provides similar cryptographic key distribution capabilities,
and it is intended for use when keying material is protected along
with the signaling.
In contrast, this specification expects endpoints to have
preconfigured keys or common security infrastructure. It provides
its own security and is independent of the protection of signaling
(if any). As a result, it can be applied in environments where
signaling protection is not turned on, or used hop-by-hop (i.e.,
scenarios where the SDP is not protected end-to-end). This
specification will, independently of the signaling protection
applied, ensure end-to-end security establishment for the media.
3. Extensions to SDP and RTSP
This section describes common attributes that can be included in SDP
or RTSP when an integrated key management protocol is used. The
attribute values follow the general SDP and RTSP guidelines (see
[SDPnew] and [RTSP]).
For both SDP and RTSP, the general method of adding the key
management protocol is to introduce new attributes, one identifier to
identify the specific key management protocol, and one data field
where the key management protocol data is placed. The key management
protocol data contains the necessary information to establish the
security protocol, e.g., keys and cryptographic parameters. All
parameters and keys are protected by the key management protocol.
The key management data SHALL be base64 [RFC3548] encoded and comply
with the base64 grammar as defined in [SDPnew]. The key management
protocol identifier, KMPID, is defined as below in Augmented Backus-
Naur Form grammar (ABNF) [RFC4234].
KMPID = 1*(ALPHA / DIGIT)
Values for the identifier, KMPID, are registered and defined in
accordance to Section 9. Note that the KMPID is case sensitive, and
it is RECOMMENDED that values registered are lowercase letters.
3.1. SDP Extensions
This section provides an ABNF grammar (as used in [SDPnew]) 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
The ABNF for the key management extensions (conforming to the
att-field and att-value) are as follows:
key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value
key-mgmt-att-field = "key-mgmt"
key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data
prtcl-id = KMPID
; e.g., "mikey"
keymgmt-data = base64
SP = %x20
where KMPID is as defined in Section 3 of this memo, and base64 is as
defined in SDP [SDPnew]. Prtcl-id refers to the set of values
defined for KMPID in Section 9.
The attribute MAY be used at session level, media level, or at both
levels. An attribute defined at media level overrides an attribute
defined at session level. In other words, if the media-level
attribute is present, the session level attribute MUST be ignored for
this media. Section 4.1 describes in detail how the attributes are
used and how the SDP is handled in different usage scenarios. The
choice of the level depends, for example, on the particular key
management protocol. Some protocols may not be able to derive enough
key material for all the sessions; furthermore, possibly a different
protection to each session could be required. The particular
protocol might achieve this only by specifying it at the media level.
Other protocols, such as MIKEY, have instead those capabilities (as
it can express multiple security policies and derive multiple keys),
so it may use the session level.
3.2. RTSP Extensions
To support the key management attributes, the following RTSP header
is defined:
KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec)
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %x22 URI %x22 ";"]
where KMPID is as defined in Section 3 of this memo, "base64" as
defined in [SDPnew], and "URI" as defined in Section 3 of [RFC3986].
The "uri" parameter identifies the context for which the key
management data applies, and the RTSP URI SHALL match a (session or
media) URI present in the description of the session. If the RTSP
aggregated control URI is included, it indicates that the key
management message is on session level (and similarly the RTSP media
control URI that it applies to the media level). If no "uri"
parameter is present in a key-mgmt-spec the specification applies to
the context identified by the RTSP request URI.
The KeyMgmt header MAY be used in the messages and directions
described in the table below.
Method | Direction | Requirement
---------------------------------------------
DESCRIBE response | S->C | RECOMMENDED
SETUP | C->S | REQUIRED
SETUP Response | S->C | REQUIRED (error)
Note: Section 4.2 describes in detail how the RTSP extensions are
used.
We define one new RTSP status code to report error due to any failure
during the key management processing (Section 4.2):
Status-Code = "463" ; Key management failure
A 463 response MAY contain a KeyMgmt header with a key management
protocol message that further indicates the nature of the error.
4. Usage with SDP, SIP, RTSP, and SAP
This section gives rules and recommendations of how/when to include
the defined key management attribute when SIP and/or RTSP are used
together with SDP.
When a key management protocol is integrated with SIP/SDP and RTSP,
the following general requirements are placed on the key management:
* At the current time, it MUST be possible to execute the key
management protocol in at most one request-response message
exchange. Future relaxation of this requirement is possible but
would introduce significant complexity for implementations
supporting multi-roundtrip mechanisms.
* It MUST be possible from the SIP/SDP and RTSP application, using
the key management API, to receive key management data and
information of whether or not a message is accepted.
The content of the key management messages depends on the key
management protocol that is used. However, the content of such key
management messages might be expected to be roughly as follows: the
key management Initiator (e.g., the offerer) includes the key
management data in a first message, containing the media description
it should apply to. This data in general consists of the security
parameters (including key material) needed to secure the
communication, together with the necessary authentication information
(to ensure that the message is authentic).
At the Responder’s side, the key management protocol checks the
validity of the key management message, together with the
availability of the parameters offered, and then provides the key
management data to be included in the answer. This answer may
typically authenticate the Responder to the Initiator, and also state
if the initial offer was accepted or not. Certain protocols might
require the Responder to include a selection of the security
parameters that he is willing to support. Again, the actual content
of such responses is dependent on the particular key management
protocol.
Section 7 describes a realization of the MIKEY protocol using these
mechanisms. Procedures to be used when mapping new key management
protocols onto this framework are described in Section 6.
4.1. Use of SDP
This section describes the processing rules for the different
applications that use SDP for the key management.
4.1.1. General Processing
The processing when SDP is used is slightly different according to
the way SDP is transported, and if it uses an offer/answer or
announcement. The processing can be divided into four different
steps:
1) How to create the initial offer.
2) How to handle a received offer.
3) How to create an answer.
4) How to handle a received answer.
It should be noted that the last two steps may not always be
applicable, as there are cases where an answer cannot or will not be
sent back.
The general processing for creating an initial offer SHALL follow the
following actions:
* The identifier of the key management protocol used MUST be placed
in the prtcl-id field of SDP. A table of legal protocols
identifiers is maintained by IANA (see Section 9).
* The keymgmt-data field MUST be created as follows: the key
management protocol MUST be used to create the key management
message. This message SHALL be base64 encoded [RFC3548] by the SDP
application and then encapsulated in the keymgmt-data attribute.
Note though that the semantics of the encapsulated message is
dependent on the key management protocol that is used.
The general processing for handling a received offer SHALL follow the
following actions:
* The key management protocol is identified according to the prtcl-id
field. A table of legal protocols identifiers is maintained by
IANA (Section 9).
* The key management data from the keymgmt-data field MUST be
extracted, base64 decoded to reconstruct the original message, and
then passed to the key management protocol for processing. Note
that depending on key management protocol, some extra parameters
might also be requested by the specific API, such as the
source/destination network address/port(s) for the specified media
(however, this will be implementation specific depending on the
actual API). The extra parameters that a key management protocol
might need (other than the ones defined here) MUST be documented,
describing their use, as well as the interaction of that key
management protocol with SDP and RTSP.
* If errors occur, or the key management offer is rejected, the
session SHALL be aborted. Possible error messages are dependent on
the specific session establishment protocol.
At this stage, the key management will have either accepted or
rejected the offered parameters. This MAY cause a response message
to be generated, depending on the key management protocol and the
application scenario.
If an answer is to be generated, the following general actions SHALL
be performed:
* The identifier of the key management protocol used MUST be placed
in the prtcl-id field.
* The keymgmt-data field MUST be created as follows. The key
management protocol MUST be used to create the key management
message. This message SHALL be base64 encoded [RFC3548] by the SDP
application and then encapsulated in the keymgmt-data attribute.
The semantics of the encapsulated message is dependent on the key
management protocol that is used.
The general processing for handling a received answer SHALL follow
the following actions:
* The key management protocol is identified according to the prtcl-id
field.
* The key management data from the keymgmt-data field MUST be
extracted, base64 decoded to reconstruct the original message, and
then passed to the key management protocol for processing.
* If the key management offer is rejected and the intent is to re-
negotiate it, it MUST be done through another Offer/Answer
exchange. It is RECOMMENDED to NOT abort the session in that case,
but to re-negotiate using another Offer/Answer exchange. For
example, in [SIP], the "security precondition" as defined in
[SPREC] solves the problem for a session initiation. The
procedures in [SPREC] are outside the scope of this document. In
an established session, an additional Offer/Answer exchange using a
re-INVITE or UPDATE as appropriate MAY be used
* If errors occur, or the key management offer is rejected and there
is no intent to re-negotiate it, the session SHALL be aborted. If
possible, an error message indicating the failure SHOULD be sent
back.
Otherwise, if all the steps are successful, the normal setup
proceeds.
4.1.2. Use of SDP with Offer/Answer and SIP
This section defines additional processing rules, to the general
rules defined in Section 4.1.1, applicable only to applications using
SDP with the offer/answer model [OAM] (and in particular SIP).
When an initial offer is created, the following offer/answer-specific
procedure SHALL be applied:
* Before creating the key management data field, the list of protocol
identifiers MUST be provided by the SDP application to (each) key
management protocol, as defined in Section 4.1.4 (to defeat
bidding-down attacks).
For a received SDP offer that contains the key management attributes,
the following offer/answer-specific procedure SHALL be applied:
* Before, or in conjunction with, passing the key management data to
the key management protocol, the complete list of protocol
identifiers from the offer message is provided by the SDP
application to the key management protocol (as defined in Section
4.1.4).
When an answer is created, the following offer/answer-specific
procedure SHALL be applied:
* If the key management rejects the offer and the intent is to re-
negotiate it, the Answer SHOULD include the cause of failure in an
included message from the key management protocol. The
renegotiation MUST be done through another Offer/Answer exchange
(e.g., using [SPREC]). In an established session, it can also be
done through a re-INVITE or UPDATE as appropriate.
* If the key management rejects the offer and the session needs to be
aborted, the answerer SHOULD return a "488 Not Acceptable Here"
message, optionally also including one or more Warning headers (a
"306 Attribute not understood" when one of the parameters is not
supported, and a "399 Miscellaneous warning" with arbitrary
information to be presented to a human user or logged; see Section
20.43 in [SIP]). Further details about the cause of failure MAY be
described in an included message from the key management protocol.
The session is then aborted (and it is up to local policy or end
user to decide how to continue).
Note that the key management attribute (related to the same key
management protocol) MAY be present both at session level and at
media level. Consequently, the process SHALL be repeated for each
such key management attribute detected. In case the key management
processing of any such attribute does not succeed (e.g.,
authentication failure, parameters not supported, etc.), on either
session or media level, the entire session setup SHALL be aborted,
including those parts of the session that successfully completed
their part of the key management.
If more than one key management protocol is supported, multiple
instances of the key management attribute MAY be included in the
initial offer when using the offer/answer model, each transporting a
different key management protocol, thus indicating supported
alternatives.
If the offerer includes more than one key management protocol
attribute at session level (analogous for the media level), these
SHOULD be listed in order of preference (the first being the
preferred). The answerer selects the key management protocol it
wishes to use, and processes only it, on either session or media
level, or on both, according to where located. If the answerer does
not support any of the offerer’s suggested key management protocols,
the answerer indicates this to the offerer so a new Offer/Answer can
be triggered; alternatively, it may return a "488 Not Acceptable
Here" error message, whereby the sender MUST abort the current setup
procedure.
Note that the placement of multiple key management offers in a single
message has the disadvantage that the message expands and the
computational workload for the offerer will increase drastically.
Unless the guidelines of Section 4.1.4 are followed, multiple lines
may open up bidding-down attacks. Note also that the multiple-offer