draft-ietf-mmusic-kmgmt-ext-14.txt   draft-ietf-mmusic-kmgmt-ext-15.txt 
Internet Engineering Task Force J. Arkko Internet Engineering Task Force J. Arkko
MMUSIC Working Group E. Carrara MMUSIC Working Group E. Carrara
INTERNET-DRAFT F. Lindholm INTERNET-DRAFT F. Lindholm
Expires: September 2005 M. Naslund Expires: December 2005 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
Mars 2005 June 2005
Key Management Extensions for Session Description Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP) Protocol (SDP) and Real Time Streaming Protocol (RTSP)
<draft-ietf-mmusic-kmgmt-ext-14.txt> <draft-ietf-mmusic-kmgmt-ext-15.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as groups may also distribute working documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/lid-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document defines general extensions for SDP and RTSP to carry This document defines general extensions for SDP and RTSP to carry
messages, as specified by a key management protocol, in order to messages, as specified by a key management protocol, in order to
secure the media. These extensions are presented as a framework, 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 be used by one or more key management protocols. As such, their use
is meaningful only when complemented by an appropriate key management is meaningful only when complemented by an appropriate key management
protocol. protocol.
General guidelines are also given on how the framework should be used General guidelines are also given on how the framework should be used
together with SIP and RTSP. The usage with the MIKEY key management together with SIP and RTSP. The usage with the MIKEY key management
protocol is also defined. protocol is also defined.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.....................................................3 1. Introduction.....................................................2
1.1. Notational Conventions.........................................4 1.1. Notational Conventions.........................................4
2. Extensions to SDP and RTSP.......................................4 2. Applicability....................................................4
2.1. SDP Extensions.................................................5 3. Extensions to SDP and RTSP.......................................4
2.2. RTSP Extensions................................................6 3.1. SDP Extensions.................................................5
3. Usage with SDP, SIP, RTSP, and SAP...............................6 3.2. RTSP Extensions................................................5
3.1. Use of SDP.....................................................7 4. Usage with SDP, SIP, RTSP, and SAP...............................6
3.1.1 General processing............................................7 4.1. Use of SDP.....................................................7
3.1.2 Use of SDP with offer/answer and SIP..........................9 4.1.1 General processing............................................7
3.1.3 Use of SDP with SAP..........................................12 4.1.2 Use of SDP with offer/answer and SIP..........................9
3.1.4 Bidding-down attack prevention...............................12 4.1.3 Use of SDP with SAP..........................................12
3.2. RTSP usage....................................................13 4.1.4 Bidding-down attack prevention...............................12
4. Example scenarios...............................................15 4.2. RTSP usage....................................................13
5. Adding further Key management protocols.........................19 5. Example scenarios...............................................15
6. Integration of MIKEY............................................20 6. Adding further Key management protocols.........................19
6.1 MIKEY Interface................................................21 7. Integration of MIKEY............................................20
7. Security Considerations.........................................22 7.1 MIKEY Interface................................................21
8. IANA Considerations.............................................23 8. Security Considerations.........................................22
8.1. SDP Attribute Registration....................................23 9. IANA Considerations.............................................23
8.2. RTSP Registration.............................................24 9.1. SDP Attribute Registration....................................23
8.3. Protocol Identifier Registration..............................24 9.2. RTSP Registration.............................................24
9. Acknowledgments.................................................25 9.3. Protocol Identifier Registration..............................24
10. Author's Addresses.............................................25 10. Acknowledgments................................................25
11. References.....................................................26 11. Author's Addresses.............................................25
11.1. Normative References.........................................26 12. References.....................................................26
11.2. Informative References.......................................26 12.1. Normative References.........................................26
12.2. Informative References.......................................26
1. Introduction 1. Introduction
[RFC Editor remark] All instances of RFC xxxx should be replaced [RFC Editor remark] All instances of RFC xxxx should be replaced
with the RFC number of this document, when published. with the RFC number of this document, when published.
There has recently been work to define a security profile for the There has recently been work to define a security profile for the
protection of real-time applications running over RTP, [SRTP]. protection of real-time applications running over RTP, [SRTP].
However, a security protocol needs a key management solution to However, a security protocol needs a key management solution to
exchange keys and security parameters, manage and refresh keys, etc. exchange keys and security parameters, manage and refresh keys, etc.
skipping to change at page 4, line 31 skipping to change at page 4, line 19
The document also defines the use of the described framework together The document also defines the use of the described framework together
with the key management protocol Multimedia Internet KEYing (MIKEY) with the key management protocol Multimedia Internet KEYing (MIKEY)
[MIKEY]. [MIKEY].
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Extensions to SDP and RTSP 2. Applicability
[SDES] provides similar cryptographic key distribution capabilities,
and it 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 This section describes common attributes that can be included in SDP
or RTSP when an integrated key management protocol is used. The or RTSP when an integrated key management protocol is used. The
attribute values follow the general SDP and RTSP guidelines (see attribute values follow the general SDP and RTSP guidelines (see
[SDPnew] and [RTSP]). [SDPnew] and [RTSP]).
For both SDP and RTSP, the general method of adding the key For both SDP and RTSP, the general method of adding the key
management protocol is to introduce new attributes, one identifier to management protocol is to introduce new attributes, one identifier to
identify the specific key management protocol, and one data field identify the specific key management protocol, and one data field
where the key management protocol data is placed. The key management where the key management protocol data is placed. The key management
skipping to change at page 5, line 4 skipping to change at page 5, line 6
protocol data contains the necessary information to establish the protocol data contains the necessary information to establish the
security protocol, e.g., keys and cryptographic parameters. All security protocol, e.g., keys and cryptographic parameters. All
parameters and keys are protected by the key management protocol. parameters and keys are protected by the key management protocol.
The key management data SHALL be base64 [RFC3548] encoded and comply The key management data SHALL be base64 [RFC3548] encoded and comply
with the base64 grammar as defined in [SDPnew]. The key management with the base64 grammar as defined in [SDPnew]. The key management
protocol identifier, KMPID, is defined as below in Augmented Backus- protocol identifier, KMPID, is defined as below in Augmented Backus-
Naur Form grammar (ABNF) [RFC2234]. Naur Form grammar (ABNF) [RFC2234].
KMPID = 1*(ALPHA / DIGIT) KMPID = 1*(ALPHA / DIGIT)
Values for the identifier, KMPID, are registered and defined in Values for the identifier, KMPID, are registered and defined in
accordance to Section 8. Note that the KMPID is case sensitive and it accordance to Section 8. Note that the KMPID is case sensitive and it
is RECOMMENDED that values registered are lower case letters. is RECOMMENDED that values registered are lower case letters.
2.1. SDP Extensions 3.1. SDP Extensions
This section provides an ABNF grammar (as used in [SDPnew]) for the This section provides an ABNF grammar (as used in [SDPnew]) for the
key management extensions to SDP. key management extensions to SDP.
Note that the new definitions are compliant with the definition of an Note that the new definitions are compliant with the definition of an
attribute field, i.e. attribute field, i.e.
attribute = (att-field ":" att-value) | att-field attribute = (att-field ":" att-value) | att-field
The ABNF for the key management extensions (conforming to the att- The ABNF for the key management extensions (conforming to the att-
skipping to change at page 6, line 5 skipping to change at page 5, line 54
used and how the SDP is handled in different usage scenarios. The used and how the SDP is handled in different usage scenarios. The
choice of the level depends for example on the particular key choice of the level depends for example on the particular key
management protocol. Some protocols may not be able to derive enough management protocol. Some protocols may not be able to derive enough
key material for all the sessions; furthermore, possibly a different key material for all the sessions; furthermore, possibly a different
protection to each session could be required. The particular protocol protection to each session could be required. The particular protocol
might achieve this only by specifying it at the media level. Other might achieve this only by specifying it at the media level. Other
protocols, such as MIKEY, have instead those capabilities (as it can protocols, such as MIKEY, have instead those capabilities (as it can
express multiple security policies and derive multiple keys), so it express multiple security policies and derive multiple keys), so it
may use the session level. may use the session level.
2.2. RTSP Extensions 3.2. RTSP Extensions
To support the key management attributes, the following RTSP header To support the key management attributes, the following RTSP header
is defined: is defined:
KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec) KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec)
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" <"> rtsp_URL <"> ";"] key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" <"> rtsp_URL <"> ";"]
"data" "=" base64 "data" "=" base64
where KMPID is as defined in Section 2 of this memo, "base64" as where KMPID is as defined in Section 2 of this memo, "base64" as
defined in [SDPnew], and "rtsp_URL" as defined in [RTSP]. defined in [SDPnew], and "rtsp_URL" as defined in [RTSP].
skipping to change at page 6, line 47 skipping to change at page 6, line 44
used. used.
We define one new RTSP status code to report error due to any failure We define one new RTSP status code to report error due to any failure
during the key management processing (Section 3.2): during the key management processing (Section 3.2):
Status-Code = "463" ; Key management failure Status-Code = "463" ; Key management failure
A 463 response MAY contain a KeyMgmt header with a key management A 463 response MAY contain a KeyMgmt header with a key management
protocol message that further indicates the nature of the error. protocol message that further indicates the nature of the error.
3. Usage with SDP, SIP, RTSP, and SAP 4. Usage with SDP, SIP, RTSP, and SAP
This section gives rules and recommendations of how/when to include This section gives rules and recommendations of how/when to include
the defined key management attribute when SIP and/or RTSP are used the defined key management attribute when SIP and/or RTSP are used
together with SDP. together with SDP.
When a key management protocol is integrated with SIP/SDP and RTSP, When a key management protocol is integrated with SIP/SDP and RTSP,
the following general requirements are placed on the key management: the following general requirements are placed on the key management:
* At the current time, it MUST be possible to execute the key * At the current time, it MUST be possible to execute the key
management protocol in at most one request-response message management protocol in at most one request-response message
skipping to change at page 7, line 43 skipping to change at page 7, line 43
if the initial offer was accepted or not. Certain protocols might if the initial offer was accepted or not. Certain protocols might
require the Responder to include a selection of the security require the Responder to include a selection of the security
parameters that he is willing to support. Again, the actual content parameters that he is willing to support. Again, the actual content
of such responses is dependent on the particular key management of such responses is dependent on the particular key management
protocol. protocol.
Section 6 describes a realization of the MIKEY protocol using these Section 6 describes a realization of the MIKEY protocol using these
mechanisms. Procedures to be used when mapping new key management mechanisms. Procedures to be used when mapping new key management
protocols onto this framework are described in Section 5. protocols onto this framework are described in Section 5.
3.1. Use of SDP 4.1. Use of SDP
This section describes the processing rules for the different This section describes the processing rules for the different
applications which use SDP for the key management. applications which use SDP for the key management.
3.1.1 General processing 4.1.1 General processing
The processing when SDP is used is slightly different according to The processing when SDP is used is slightly different according to
the way SDP is transported, and if it uses an offer/answer or the way SDP is transported, and if it uses an offer/answer or
announcement. The processing can be divided into four different announcement. The processing can be divided into four different
steps: steps:
1) How to create the initial offer. 1) How to create the initial offer.
2) How to handle a received offer. 2) How to handle a received offer.
3) How to create an answer. 3) How to create an answer.
4) How to handle a received answer. 4) How to handle a received answer.
It should be noted that the last two steps may not always be It should be noted that the last two steps may not always be
applicable, as there are cases where an answer can not or will not be applicable, as there are cases where an answer can not or will not be
sent back. sent back.
The general processing for creating an initial offer SHALL follow the The general processing for creating an initial offer SHALL follow the
following actions: following actions:
skipping to change at page 9, line 46 skipping to change at page 9, line 46
a re-INVITE or UPDATE as appropriate MAY be used. a re-INVITE or UPDATE as appropriate MAY be used.
* If errors occur, or the key management offer is rejected and there * 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 is no intent to re-negotiate it, the session SHALL be aborted. If
possible an error message indicating the failure SHOULD be sent possible an error message indicating the failure SHOULD be sent
back. back.
Otherwise, if all the steps are successful, the normal setup Otherwise, if all the steps are successful, the normal setup
proceeds. proceeds.
3.1.2 Use of SDP with offer/answer and SIP 4.1.2 Use of SDP with offer/answer and SIP
This section defines additional processing rules, to the general This section defines additional processing rules, to the general
rules defined in Section 3.1.1, applicable only to applications using rules defined in Section 3.1.1, applicable only to applications using
SDP with the offer-answer model [OAM] (and in particular SIP). SDP with the offer-answer model [OAM] (and in particular SIP).
When an initial offer is created, the following offer-answer specific When an initial offer is created, the following offer-answer specific
procedure SHALL be applied: procedure SHALL be applied:
* Before creating the key management data field, the list of protocol * Before creating the key management data field, the list of protocol
identifiers MUST be provided by the SDP application to (each) key identifiers MUST be provided by the SDP application to (each) key
skipping to change at page 11, line 48 skipping to change at page 11, line 48
answerer SHOULD send a "488 Not Acceptable Here" message, including answerer SHOULD send a "488 Not Acceptable Here" message, including
one or more Warning headers (at least a 306). The offerer MUST then one or more Warning headers (at least a 306). The offerer MUST then
abort the session. abort the session.
Note that, in multicast scenarios, unlike unicast, there is only a Note that, in multicast scenarios, unlike unicast, there is only a
single view of the stream [OAM], hence there MUST be a uniform single view of the stream [OAM], hence there MUST be a uniform
agreement of the security parameters. agreement of the security parameters.
After the offer is issued, the offerer SHOULD be prepared to receive After the offer is issued, the offerer SHOULD be prepared to receive
media, as the media may arrive prior to the answer. However, this media, as the media may arrive prior to the answer. However, this
brings issues, as the offer does not know yet the answerer's choice brings issues, as the offer does not know yet the answerers choice
in terms of e.g. algorithms, nor possibly the key is know. This can in terms of e.g. algorithms, nor possibly the key is know. This can
cause delay or clipping can occur; if this is unacceptable, the cause delay or clipping can occur; if this is unacceptable, the
offerer SHOULD use mechanisms outside the scope of this document, offerer SHOULD use mechanisms outside the scope of this document,
e.g. the security precondition for SIP [SPREC]. e.g. the security precondition for SIP [SPREC].
3.1.3 Use of SDP with SAP 4.1.3 Use of SDP with SAP
There are cases where SDP is used without conforming to the There are cases where SDP is used without conforming to the
offer/answer model; instead it is a one-way SDP distribution (i.e. offer/answer model; instead it is a one-way SDP distribution (i.e.
without back channel), such as when used with SAP and HTTP. without back channel), such as when used with SAP and HTTP.
The processing follows the two first steps of the general SDP The processing follows the two first steps of the general SDP
processing (see Section 3.1.1). It can be noted that the processing processing (see Section 3.1.1). It can be noted that the processing
in this case differs from the offer/answer case in the fact that only in this case differs from the offer/answer case in the fact that only
one key management protocol SHALL be offered (i.e. no negotiation one key management protocol SHALL be offered (i.e. no negotiation
will be possible). This implies that the bidding down attack is not will be possible). This implies that the bidding down attack is not
an issue; therefore the countermeasure is not needed. The key an issue; therefore the countermeasure is not needed. The key
management protocol used MUST support one-way messages. management protocol used MUST support one-way messages.
3.1.4 Bidding-down attack prevention 4.1.4 Bidding-down attack prevention
The possibility to support multiple key management protocols may, The possibility to support multiple key management protocols may,
unless properly handled, introduce bidding-down attacks. unless properly handled, introduce bidding-down attacks.
Specifically, a man-in-the-middle could "peel off" cryptographically Specifically, a man-in-the-middle could "peel off" cryptographically
strong offers (deleting the key management lines from the message), strong offers (deleting the key management lines from the message),
leaving only weaker ones as the Responder's choice. To avoid this, leaving only weaker ones as the Responder's choice. To avoid this,
the list of identifiers of the proposed key management protocols MUST the list of identifiers of the proposed key management protocols MUST
be authenticated. The authentication MUST be done separately by each be authenticated. The authentication MUST be done separately by each
key management protocol. key management protocol.
skipping to change at page 13, line 34 skipping to change at page 13, line 33
response to error messages, see "Security Considerations". response to error messages, see "Security Considerations".
End-to-end integrity protection of the key-mgmt attributes End-to-end integrity protection of the key-mgmt attributes
altogether, provided externally to the key management themselves, altogether, provided externally to the key management themselves,
also gives protection against this bidding down attack. This is for also gives protection against this bidding down attack. This is for
example the case if SIP uses S/MIME [RFC3851] to end-to-end integrity example the case if SIP uses S/MIME [RFC3851] to end-to-end integrity
protect the SDP description. As however this end-to-end protection is protect the SDP description. As however this end-to-end protection is
not an assumption of the framework, the mechanisms defined in this not an assumption of the framework, the mechanisms defined in this
section SHALL be applied. section SHALL be applied.
3.2. RTSP usage 4.2. RTSP usage
RTSP does not use the offer/answer model, as SIP does. This causes RTSP does not use the offer/answer model, as SIP does. This causes
some problems, as it is not possible (without modifying RTSP) to send some problems, as it is not possible (without modifying RTSP) to send
back an answer. To solve this, a new header has been introduced back an answer. To solve this, a new header has been introduced
(Section 2.2). This also assumes that the key management also has (Section 2.2). This also assumes that the key management also has
some kind of binding to the media, so that the response to the server some kind of binding to the media, so that the response to the server
will be processed as required. will be processed as required.
The server SHALL be the Initiator of the key management exchange for The server SHALL be the Initiator of the key management exchange for
sessions in PLAY mode, i.e. transporting media from server to client. sessions in PLAY mode, i.e. transporting media from server to client.
skipping to change at page 15, line 40 skipping to change at page 15, line 40
SETUP response using RTSP error code 463 (see Section 2.2) and the SETUP response using RTSP error code 463 (see Section 2.2) and the
session is aborted. It is up to the key management protocol to session is aborted. It is up to the key management protocol to
specify (within the RTSP status code message or through key specify (within the RTSP status code message or through key
management messages) details about the type of error that management messages) details about the type of error that
occurred. occurred.
Re-keying within RTSP is for further study, given that media updating Re-keying within RTSP is for further study, given that media updating
mechanisms within RTSP are unspecified at the time this document is mechanisms within RTSP are unspecified at the time this document is
written. written.
4. Example scenarios 5. Example scenarios
The following examples utilize MIKEY [MIKEY] as the key management The following examples utilize MIKEY [MIKEY] as the key management
protocol to be integrated into SDP and RTSP (see Section 5.1.). protocol to be integrated into SDP and RTSP (see Section 5.1.).
Example 1 (SIP/SDP) Example 1 (SIP/SDP)
A SIP call is taking place between Alice and Bob. Alice sends an A SIP call is taking place between Alice and Bob. Alice sends an
INVITE message consisting of the following offer: INVITE message consisting of the following offer:
v=0 v=0
skipping to change at page 19, line 47 skipping to change at page 19, line 47
SETUP rtsp://movie.example.com/action/video RTSP/1.0 SETUP rtsp://movie.example.com/action/video RTSP/1.0
CSeq: 315 CSeq: 315
Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059 Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video"; keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video";
data="AQEFgM0AdlABAAAAAAAAAAAAAA..." data="AQEFgM0AdlABAAAAAAAAAAAAAA..."
Note: The "uri" parameter could be excluded from the two SETUP Note: The "uri" parameter could be excluded from the two SETUP
messages in this example. messages in this example.
5. Adding further Key management protocols 6. Adding further Key management protocols
This framework cannot be used with all key management protocols. The This framework cannot be used with all key management protocols. The
key management protocol needs to comply with the requirements key management protocol needs to comply with the requirements
described in Section 3. In addition to this, the following needs to described in Section 3. In addition to this, the following needs to
be defined: be defined:
* The key management protocol identifier to be used as the protocol * The key management protocol identifier to be used as the protocol
identifier should be registered at IANA according to Section 8. identifier should be registered at IANA according to Section 8.
* The information that the key management needs from SDP and RTSP, * The information that the key management needs from SDP and RTSP,
skipping to change at page 20, line 31 skipping to change at page 20, line 31
Finally, it is obviously crucial to analyze possible security Finally, it is obviously crucial to analyze possible security
implications induced by the introduction of a new key management implications induced by the introduction of a new key management
protocol in the described framework. protocol in the described framework.
Today, the MIKEY protocol [MIKEY] has adopted the key management Today, the MIKEY protocol [MIKEY] has adopted the key management
extensions to work together with SIP and RTSP (see Section 6). Other extensions to work together with SIP and RTSP (see Section 6). Other
protocols MAY use the described attribute and header, e.g. Kerberos protocols MAY use the described attribute and header, e.g. Kerberos
[KERB], however this is subject to future standardization. [KERB], however this is subject to future standardization.
6. Integration of MIKEY 7. Integration of MIKEY
[MIKEY] describes a key management protocol for real-time [MIKEY] describes a key management protocol for real-time
applications (both for peer-to-peer communication and group applications (both for peer-to-peer communication and group
communication). MIKEY carries the security parameters needed for communication). MIKEY carries the security parameters needed for
setting up the security protocol (e.g., SRTP) protecting the media setting up the security protocol (e.g., SRTP) protecting the media
stream. MIKEY can be integrated within SDP and RTSP, following the stream. MIKEY can be integrated within SDP and RTSP, following the
rules and guidelines described in this document. rules and guidelines described in this document.
MIKEY satisfies the requirements described in Section 3. The MIKEY MIKEY satisfies the requirements described in Section 3. The MIKEY
message is formed as defined in [MIKEY], then passed from MIKEY to message is formed as defined in [MIKEY], then passed from MIKEY to
skipping to change at page 21, line 17 skipping to change at page 21, line 16
included in SDP and SHOULD (according to policy) if they differ, or included in SDP and SHOULD (according to policy) if they differ, or
if integrity/signature verification fails, reject the offer. if integrity/signature verification fails, reject the offer.
The server will need to be able to know the identity of the Client The server will need to be able to know the identity of the Client
before creating and sending a MIKEY message. To signal the (MIKEY) before creating and sending a MIKEY message. To signal the (MIKEY)
identity of the client to the server in the DESCRIBE, it is identity of the client to the server in the DESCRIBE, it is
RECOMMENDED to include the From header field in RTSP. Other methods RECOMMENDED to include the From header field in RTSP. Other methods
to establish the identity could be using the IP address or retrieving to establish the identity could be using the IP address or retrieving
the identity from the RTSP authentication if used. the identity from the RTSP authentication if used.
6.1 MIKEY Interface 7.1 MIKEY Interface
This subsection describes some aspects, which implementers SHOULD This subsection describes some aspects, which implementers SHOULD
consider. If the MIKEY implementation is separate from the consider. If the MIKEY implementation is separate from the
SDP/SIP/RTSP, an application programming interface (API) between SDP/SIP/RTSP, an application programming interface (API) between
MIKEY and those protocols is needed with certain functionality MIKEY and those protocols is needed with certain functionality
(however, exactly what it looks like is implementation dependent). (however, exactly what it looks like is implementation dependent).
The following aspects need to be considered: The following aspects need to be considered:
* the possibility for MIKEY to receive information about the sessions * the possibility for MIKEY to receive information about the sessions
skipping to change at page 22, line 8 skipping to change at page 22, line 5
and the rollover counter (ROC, see [SRTP]) for SRTP usage. It is and the rollover counter (ROC, see [SRTP]) for SRTP usage. It is
also RECOMMENDED that extra information about errors can be also RECOMMENDED that extra information about errors can be
received. received.
* the possibility for the SIP or RTSP application to receive outgoing * the possibility for the SIP or RTSP application to receive outgoing
MIKEY messages. MIKEY messages.
* the possibility to tear down a MIKEY CSB (e.g. if the SIP session * the possibility to tear down a MIKEY CSB (e.g. if the SIP session
is closed, the CSB SHOULD also be closed). is closed, the CSB SHOULD also be closed).
7. Security Considerations 8. Security Considerations
The framework for transfer of key management data as described here The framework for transfer of key management data as described here
is intended to provide the security parameters for the end-to-end is intended to provide the security parameters for the end-to-end
protection of the media session. It is furthermore good practice to protection of the media session. It is furthermore good practice to
secure the session setup (e.g. SDP, SIP, RTSP, SAP). However, it secure the session setup (e.g. SDP, SIP, RTSP, SAP). However, it
might be that the security of the session setup is not possible to might be that the security of the session setup is not possible to
achieve end-to-end, but only hop-by-hop. For example, SIP requires achieve end-to-end, but only hop-by-hop. For example, SIP requires
intermediate proxies to have access to part of the SIP message, and intermediate proxies to have access to part of the SIP message, and
sometimes also to the SDP description (c.f. [E2M]), although end-to- sometimes also to the SDP description (c.f. [E2M]), although end-to-
end confidentiality can hide bodies from intermediaries. General end confidentiality can hide bodies from intermediaries. General
skipping to change at page 23, line 47 skipping to change at page 23, line 46
bidding-down attack prevention, as described above, would not work in bidding-down attack prevention, as described above, would not work in
this case (as the answerer receives no key management attribute). this case (as the answerer receives no key management attribute).
Also here it is impossible to assure the authenticity of a declined Also here it is impossible to assure the authenticity of a declined
offer, though here the reason is the "peeling-off" attack. It is up offer, though here the reason is the "peeling-off" attack. It is up
to the local policy to decide the behavior in the case that the to the local policy to decide the behavior in the case that the
response declines any security (therefore there is impossibility of response declines any security (therefore there is impossibility of
authenticating it). If for example the local policy requires a secure authenticating it). If for example the local policy requires a secure
communication and cannot accept an unsecured one, then the session communication and cannot accept an unsecured one, then the session
setup SHALL be aborted. setup SHALL be aborted.
8. IANA Considerations 9. IANA Considerations
8.1. SDP Attribute Registration 9.1. SDP Attribute Registration
The IANA is hereby requested to create a new subregistry for the The IANA is hereby requested to create a new subregistry for the
purpose of key management protocol integration with SDP. purpose of key management protocol integration with SDP.
SDP Attribute Field ("att-field"): SDP Attribute Field ("att-field"):
Name: key-mgmt-att-field Name: key-mgmt-att-field
Long form: key management protocol attribute field Long form: key management protocol attribute field
Type of name: att-field Type of name: att-field
Type of attribute: Media and session level Type of attribute: Media and session level
Purpose: See RFC xxxx, Section 2. Purpose: See RFC xxxx, Section 2.
Reference: RFC xxxx, Section 2.1 Reference: RFC xxxx, Section 2.1
Values: See RFC xxxx, Section 2.1 and 8.3. Values: See RFC xxxx, Section 2.1 and 8.3.
8.2. RTSP Registration 9.2. RTSP Registration
The IANA is hereby requested to create a new subregistry for the The IANA is hereby requested to create a new subregistry for the
purpose of key management protocol integration with RTSP. purpose of key management protocol integration with RTSP.
Following the guidelines of [RTSP], the registration is defined as Following the guidelines of [RTSP], the registration is defined as
follows: follows:
Header name: keymgmt Header name: keymgmt
Header syntax: see RFC xxxx, Section 2.2 Header syntax: see RFC xxxx, Section 2.2
Intended usage: see RFC xxxx, Section 2.2 Intended usage: see RFC xxxx, Section 2.2
Proxy treatment: Proxies SHALL NOT add, change, or delete the Proxy treatment: Proxies SHALL NOT add, change, or delete the
header. The proxy does not need to read this header. The proxy does not need to read this
header. header.
Purpose: see RFC xxxx, Section 2 Purpose: see RFC xxxx, Section 2
The RTSP Status-Code "463" [RFC xxxx], with the default string "Key The RTSP Status-Code "463" [RFC xxxx], with the default string "Key
management failure", needs to be registered. management failure", needs to be registered.
8.3. Protocol Identifier Registration 9.3. Protocol Identifier Registration
This document defines one new name space, the "SDP/RTSP key This document defines one new name space, the "SDP/RTSP key
management protocol identifier", associated with the protocol management protocol identifier", associated with the protocol
identifier, KMPID, defined in Section 2 to be used with the above identifier, KMPID, defined in Section 2 to be used with the above
registered attributes in SDP and RTSP. registered attributes in SDP and RTSP.
The IANA is hereby requested to create a new subregistry for the The IANA is hereby requested to create a new subregistry for the
KMPID parameter, with the following registration created initially: KMPID parameter, with the following registration created initially:
"mikey". "mikey".
skipping to change at page 25, line 27 skipping to change at page 25, line 27
* Contact: the contact name and email address * Contact: the contact name and email address
* Value name: the name of the value being registered (which MUST * Value name: the name of the value being registered (which MUST
comply with the KMPID as defined in Section 2) comply with the KMPID as defined in Section 2)
* Long Name: long-form name in English * Long Name: long-form name in English
* Purpose: short explanation of the purpose of the registered name. * Purpose: short explanation of the purpose of the registered name.
* Reference: a reference to the specification (e.g. RFC number) * Reference: a reference to the specification (e.g. RFC number)
providing the usage guidelines in accordance to Section 5 (and providing the usage guidelines in accordance to Section 5 (and
also complying to the specified requirements). also complying to the specified requirements).
9. Acknowledgments 10. Acknowledgments
The authors would like to thank Francois Audet, Rolf Blom, Johan The authors would like to thank Francois Audet, Rolf Blom, Johan
Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries, Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries,
Joerg Ott, Jon Peterson, and Jon-Olov Vatn. A special thanks to Colin Joerg Ott, Jon Peterson, and Jon-Olov Vatn. A special thanks to Colin
Perkins and Magnus Westerlund, who contributed in many sections. Perkins and Magnus Westerlund, who contributed in many sections.
10. Author's Addresses 11. Author's Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
02420 Jorvas Phone: +358 40 5079256 02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com Finland Email: jari.arkko@ericsson.com
Elisabetta Carrara Elisabetta Carrara
Ericsson Ericsson
SE-16480 Stockholm Phone: +46 8 50877040 SE-16480 Stockholm Phone: +46 8 50877040
Sweden EMail: elisabetta.carrara@ericsson.com Sweden EMail: elisabetta.carrara@ericsson.com
skipping to change at page 26, line 11 skipping to change at page 26, line 11
Mats Naslund Mats Naslund
Ericsson Research Ericsson Research
SE-16480 Stockholm Phone: +46 8 58533739 SE-16480 Stockholm Phone: +46 8 58533739
Sweden EMail: mats.naslund@ericsson.com Sweden EMail: mats.naslund@ericsson.com
Karl Norrman Karl Norrman
Ericsson Research Ericsson Research
SE-16480 Stockholm Phone: +46 8 4044502 SE-16480 Stockholm Phone: +46 8 4044502
Sweden EMail: karl.norrman@ericsson.com Sweden EMail: karl.norrman@ericsson.com
11. References 12. References
11.1. Normative References 12.1. Normative References
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Norrman, K., "MIKEY: Multimedia Internet KEYing", IETF, RFC 3830. Norrman, K., "MIKEY: Multimedia Internet KEYing", IETF, RFC 3830.
[OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with
the Session Description Protocol (SDP)", IETF, RFC 3264. the Session Description Protocol (SDP)", IETF, RFC 3264.
[RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
Streaming Protocol (RTSP)", IETF, RFC 2326. Streaming Protocol (RTSP)", IETF, RFC 2326.
skipping to change at page 26, line 43 skipping to change at page 26, line 43
[RFC2234] Crocker, D. and Overell, P., "Augmented BNF for Syntax [RFC2234] Crocker, D. and Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing an [RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", IETF, RFC 2434. IANA Considerations Section in RFCs", IETF, RFC 2434.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", IETF, RFC 3548. Encodings", IETF, RFC 3548.
11.2. Informative References 12.2. Informative References
[E2M] Ono, K. and Tachimoto, S., "End-to-middle security in the [E2M] Ono, K. and Tachimoto, S., "End-to-middle security in the
Session Initiation Protocol (SIP)", Internet Draft, IETF, draft-ono- Session Initiation Protocol (SIP)", Internet Draft, IETF, draft-ono-
sipping-end2middle-security-03. sipping-end2middle-security-03.
[KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication [KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication
Service (V5)", IETF, RFC 1510. Service (V5)", IETF, RFC 1510.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", IETF, RFC 3851. (S/MIME) Version 3.1 Message Specification", IETF, RFC 3851.
skipping to change at page 27, line 45 skipping to change at page 27, line 45
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires in September 2005. This Internet-Draft expires in December 2005.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/