draft-ietf-mmusic-kmgmt-ext-13.txt   draft-ietf-mmusic-kmgmt-ext-14.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: August 2005 M. Naslund Expires: September 2005 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
February 2005 Mars 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-13.txt> <draft-ietf-mmusic-kmgmt-ext-14.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am (we are) aware have been of section 3 of RFC 3667. By submitting this Internet-Draft, each
disclosed, and any of which I (we) become aware will be disclosed, in author represents that any applicable patent or other IPR claims of
accordance with RFC 3668 (BCP 79). which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
By submitting this Internet-Draft, I accept the provisions of Section RFC 3668.
3 of RFC 3667 (BCP 78).
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
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 cite them other than as "work in progress". material or to 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/lid-abstracts.txt http://www.ietf.org/ietf/1id-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 (2004). 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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.....................................................3
1.1. Notational Conventions.........................................4 1.1. Notational Conventions.........................................4
2. Extensions to SDP and RTSP.......................................4 2. Extensions to SDP and RTSP.......................................4
2.1. SDP Extensions.................................................5 2.1. SDP Extensions.................................................5
2.2. RTSP Extensions................................................5 2.2. RTSP Extensions................................................6
3. Usage with SDP, SIP, RTSP, and SAP...............................6 3. Usage with SDP, SIP, RTSP, and SAP...............................6
3.1. Use of SDP.....................................................7 3.1. Use of SDP.....................................................7
3.1.1 General processing............................................7 3.1.1 General processing............................................7
3.1.2 Use of SDP with offer/answer and SIP..........................9 3.1.2 Use of SDP with offer/answer and SIP..........................9
3.1.3 Use of SDP with SAP..........................................11 3.1.3 Use of SDP with SAP..........................................12
3.1.4 Bidding-down attack prevention...............................12 3.1.4 Bidding-down attack prevention...............................12
3.2. RTSP usage....................................................13 3.2. RTSP usage....................................................13
4. Example scenarios...............................................15 4. Example scenarios...............................................15
5. Adding further Key management protocols.........................19 5. Adding further Key management protocols.........................19
6. Integration of MIKEY............................................20 6. Integration of MIKEY............................................20
6.1 MIKEY Interface................................................21 6.1 MIKEY Interface................................................21
7. Security Considerations.........................................21 7. Security Considerations.........................................22
8. IANA Considerations.............................................23 8. IANA Considerations.............................................23
8.1. SDP Attribute Registration....................................23 8.1. SDP Attribute Registration....................................23
8.2. RTSP Registration.............................................23 8.2. RTSP Registration.............................................24
8.3. Protocol Identifier Registration..............................24 8.3. Protocol Identifier Registration..............................24
9. Acknowledgments.................................................25 9. Acknowledgments.................................................25
10. Author's Addresses.............................................25 10. Author's Addresses.............................................25
11. References.....................................................25 11. References.....................................................26
11.1. Normative References.........................................25 11.1. Normative References.........................................26
11.2. Informative References.......................................26 11.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
skipping to change at page 4, line 11 skipping to change at page 4, line 11
Currently in SDP [SDPnew], there exists one field to transport keys, Currently in SDP [SDPnew], there exists one field to transport keys,
the "k=" field. However, this is not enough for a key management the "k=" field. However, this is not enough for a key management
protocol as there are many more parameters that need to be protocol as there are many more parameters that need to be
transported, and the "k=" field is not extensible. The approach used transported, and the "k=" field is not extensible. The approach used
is to extend the SDP description through a number of attributes that is to extend the SDP description through a number of attributes that
transport the key management offer/answer and also to associate it transport the key management offer/answer and also to associate it
with the media sessions. SIP uses the offer/answer model [OAM] with the media sessions. SIP uses the offer/answer model [OAM]
whereby extensions to SDP will be enough. However, RTSP [RTSP] does 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 not use the offer/answer model with SDP, so a new RTSP header is
introduced to convey key management data. 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 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].
skipping to change at page 4, line 40 skipping to change at page 4, line 48
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
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, KMID, 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].
KMID = 1*(ALPHA / DIGIT) KMPID = 1*(ALPHA / DIGIT)
Values for the identifier, KMPID, are registered and defined in
Values for the identifier, KMID, 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 KMID 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 2.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-
field and att-value) are as follow: field and att-value) are as follow:
key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value
key-mgmt-att-field = "key-mgmt" key-mgmt-att-field = "key-mgmt"
key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data
prtcl-id = KMID prtcl-id = KMPID
; e.g. "mikey" ; e.g. "mikey"
keymgmt-data = base64 keymgmt-data = base64
SP = 0x20 SP = 0x20
where KMID is as defined in Section 2 of this memo, base64 is as where KMPID is as defined in Section 2 of this memo, base64 is as
defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined
for KMID in Section 8. for KMPID in Section 8.
The attribute MAY be used at session level, media level, or at both The attribute MAY be used at session level, media level, or at both
levels. An attribute defined at media level overrides an attribute levels. An attribute defined at media level overrides an attribute
defined at session level. In other words, if the media level defined at session level. In other words, if the media level
attribute is present, the session level attribute MUST be ignored for attribute is present, the session level attribute MUST be ignored for
this media. Section 3.1 describes in detail how the attributes are this media. Section 3.1 describes in detail how the attributes are
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
skipping to change at page 6, line 4 skipping to change at page 6, line 11
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 2.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" "=" KMID ";" ["uri" "=" <"> rtsp_URL <"> ";"]
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" <"> rtsp_URL <"> ";"]
"data" "=" base64 "data" "=" base64
where KMID 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].
The "uri" parameter identifies the context for which the key The "uri" parameter identifies the context for which the key
management data applies, and the RTSP URI SHALL match a (session or management data applies, and the RTSP URI SHALL match a (session or
media) URI present in the description of the session. If the RTSP media) URI present in the description of the session. If the RTSP
aggregated control URI is included it indicates that the key aggregated control URI is included it indicates that the key
management message is on session level (and similarly the RTSP media management message is on session level (and similarly the RTSP media
control URI, that it applies to the media level). If no "uri" control URI, that it applies to the media level). If no "uri"
parameter is present in a key-mgmt-spec the specification applies to parameter is present in a key-mgmt-spec the specification applies to
the context identified by the RTSP request URI. the context identified by the RTSP request URI.
skipping to change at page 6, line 48 skipping to change at page 7, line 8
3. Usage with SDP, SIP, RTSP, and SAP 3. 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:
* It MUST be possible to execute the key management protocol in at * At the current time, it MUST be possible to execute the key
most one request-response message exchange. 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 * It MUST be possible from the SIP/SDP and RTSP application, using
the key management API, to receive key management data, and the key management API, to receive key management data, and
information of whether a message is accepted or not. information of whether a message is accepted or not.
The content of the key management messages depends on the key The content of the key management messages depends on the key
management protocol that is used. However, the content of such key management protocol that is used. However, the content of such key
management messages might be expected to be roughly as follow: the management messages might be expected to be roughly as follow: the
key management Initiator (e.g. the offerer) includes the key key management Initiator (e.g. the offerer) includes the key
management data in a first message, containing the media description management data in a first message, containing the media description
skipping to change at page 11, line 39 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 answerers choice brings issues, as the offer does not know yet the answerer's 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 3.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.
skipping to change at page 12, line 35 skipping to change at page 12, line 45
that still MUST authenticate its own protocol identifier. that still MUST authenticate its own protocol identifier.
The list of protocol identifiers MUST then be given to each of the The list of protocol identifiers MUST then be given to each of the
selected (offered) key management protocols by the application with selected (offered) key management protocols by the application with
";" separated identifiers. All the offered protocol identifiers MUST ";" separated identifiers. All the offered protocol identifiers MUST
be included, in the same order as they appear in the corresponding be included, in the same order as they appear in the corresponding
SDP description. SDP description.
The protocol list can formally be described as The protocol list can formally be described as
prtcl-list = KMID *(";" KMID) prtcl-list = KMPID *(";" KMPID)
where KMID is as defined in Section 2. where KMPID is as defined in Section 2.
For example, if the offered protocols are MIKEY and two yet-to-be- For example, if the offered protocols are MIKEY and two yet-to-be-
invented protocols KEYP1, KEYP2, the SDP is: invented protocols KEYP1, KEYP2, the SDP is:
v=0 v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=Secret discussion s=Secret discussion
t=0 0 t=0 0
c=IN IP4 lost.example.com c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
skipping to change at page 20, line 27 skipping to change at page 20, line 35
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 6. 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 can be integrated within SDP and RTSP, communication). MIKEY carries the security parameters needed for
following the rules and guidelines described in this document. setting up the security protocol (e.g., SRTP) protecting the media
stream. MIKEY can be integrated within SDP and RTSP, following the
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
the SDP application that base64 encodes it, and encapsulates it in the SDP application that base64 encodes it, and encapsulates it in
the keymgmt-data attribute. The examples in Section 4 use MIKEY, the keymgmt-data attribute. The examples in Section 4 use MIKEY,
where the semantic of the exchange is also briefly explained. where the semantic of the exchange is also briefly explained.
The key management protocol identifier (KMID) to be used as the The key management protocol identifier (KMPID) to be used as the
protocol identifier SHALL be "mikey" and is registered at IANA, see protocol identifier SHALL be "mikey" and is registered at IANA, see
in detail Section 8. in detail Section 8.
The information that the key management needs from SDP and RTSP, and The information that the key management needs from SDP and RTSP, and
vice versa, follows Section 3. To avoid bidding-down attacks, the vice versa, follows Section 3. To avoid bidding-down attacks, the
directives in Section 3.1.4 are followed. The list of protocol directives in Section 3.1.4 are followed. The list of protocol
identifiers is authenticated within MIKEY by placing the list in a identifiers is authenticated within MIKEY by placing the list in a
General Extension Payload (of type "SDP IDs", [MIKEY]), which then General Extension Payload (of type "SDP IDs", [MIKEY]), which then
automatically will be integrity protected/signed. The receiver SHALL automatically will be integrity protected/signed. The receiver SHALL
then match the list in the General Extension Payload with the list then match the list in the General Extension Payload with the list
skipping to change at page 22, line 16 skipping to change at page 22, line 26
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
security considerations for the session setup can be found in SDP security considerations for the session setup can be found in SDP
[SDPnew], SIP [SIP], and RTSP [RTSP]. The framework defined in this [SDPnew], SIP [SIP], and RTSP [RTSP]. The framework defined in this
memo is useful when the session setup is not protected in an end-to- memo is useful when the session setup is not protected in an end-to-
end fashion, but the media streams needs to be end-to-end protected, end fashion, but the media streams needs to be end-to-end protected,
hence the security parameters (such as keys) are not wanted revealed hence the security parameters (such as keys) are not wanted revealed
to nor manipulated by intermediaries. to nor manipulated by intermediaries.
The security will also depend on the encapsulated level of security The security will also depend on the level of security the key
the key management protocol offers. It follows that, under the management protocol offers. It follows that, under the assumption
assumption that the key management schemes are secure, the SDP can be that the key management schemes are secure, the SDP can be passed
passed along unencrypted without affecting the key management as along unencrypted without affecting the key management as such, and
such, and the media streams will still be secure even if some the media streams will still be secure even if some attackers gained
attackers gained knowledge of the SDP contents. Further security knowledge of the SDP contents. Further security considerations can be
considerations can be found for each key management protocol (for found for each key management protocol (for MIKEY these can be found
MIKEY these can be found in [MIKEY]). However, if the SDP messages in [MIKEY]). However, if the SDP messages are not sent integrity
are not sent integrity protected between the parties, it is possible protected between the parties, it is possible for an active attacker
for an active attacker to change attributes without being detected. to change attributes without being detected. As the key management
As the key management protocol may (indirectly) rely on some of the protocol may (indirectly) rely on some of the session information
session information from SDP (e.g., address information), an attack from SDP (e.g., address information), an attack on SDP may have
on SDP may have indirect consequences on the key management. Even if indirect consequences on the key management. Even if the key
the key management protocol does not rely on parameters of SDP and management protocol does not rely on parameters of SDP and will not
will not be affected by manipulation of these, different DoS attacks be affected by manipulation of these, different DoS attacks aimed at
aimed at SDP may lead to undesired interruption in the setup. See SDP may lead to undesired interruption in the setup. See also the
also the attacks described at the end of this section. attacks described at the end of this section.
The only integrity protected attribute of the media stream is, in the
framework proposed here, the set of key management protocols. It is
for instance possible to (1) swap key management offers across SDP
messages, or, (2) inject a previous key management offer into a new
SDP message. Making the (necessary) assumption that all involved key
management protocols are secure, the second attack will be detected
by replay protection mechanisms of the key management protocol(s).
Making the further assumption that, according to normal best current
practice, the production of each key management offer is done with
independent (pseudo)random choices (for session keys and other
parameters), the first attack will either be detected in the
Responder's (now incorrect) verification reply message (if such is
used), or, be a pure DoS attack, resulting in Initiator and Responder
using different keys.
It is RECOMMENDED for the identity at the SPD level to be the one
authenticated at the key management protocol level. This might
however need to keep into consideration privacy aspects, which are
out of scope for this famework.
The use of multiple key management protocols in the same offer may The use of multiple key management protocols in the same offer may
open up the possibility of a bidding-down attack, as specified in open up the possibility of a bidding-down attack, as specified in
Section 3.1.4. To exclude such possibility, the authentication of the Section 3.1.4. To exclude such possibility, the authentication of the
protocol identifier list is used. Note though, that the security protocol identifier list is used. Note though, that the security
level of the authenticated protocol identifier will be as high (or level of the authenticated protocol identifier will be as high (or
low), as the "weakest" protocol. Therefore, it is discouraged to low), as the "weakest" protocol. Therefore, the offer MUST NOT
offer protocols with too different security levels. contain any security protocols (or configurations thereof) weaker
than permitted by local security policy.
Note that it is impossible to assure the authenticity of a declined Note that it is impossible to assure the authenticity of a declined
offer, since even if it comes from the true respondent, the fact that offer, since even if it comes from the true respondent, the fact that
the answerer declines the offer usually means that he does not the answerer declines the offer usually means that he does not
support the protocol(s) offered, and consequently cannot be expected support the protocol(s) offered, and consequently cannot be expected
to authenticate the response either. This means that if the Initiator to authenticate the response either. This means that if the Initiator
is unsure of which protocol(s) the Responder supports, we RECOMMEND is unsure of which protocol(s) the Responder supports, we RECOMMEND
that the Initiator offers all acceptable protocols in a single offer. that the Initiator offers all acceptable protocols in a single offer.
If not, this opens up the possibility for a "man-in-the-middle" If not, this opens up the possibility for a "man-in-the-middle"
(MITM) to affect the outcome of the eventually agreed upon protocol, (MITM) to affect the outcome of the eventually agreed upon protocol,
skipping to change at page 23, line 21 skipping to change at page 23, line 51
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 8. IANA Considerations
8.1. SDP Attribute Registration 8.1. SDP Attribute Registration
A new SDP attribute needs to be registered for the purpose of key The IANA is hereby requested to create a new subregistry for the
management protocol integration with SDP. purpose of key management protocol integration with SDP.
Contact: Fredrik Lindholm
mailto: fredrik.lindholm@ericsson.com
tel: +46 8 58531705
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 8.2. RTSP Registration
A new RTSP Header needs to be registered for the purpose of key The IANA is hereby requested to create a new subregistry for the
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.
skipping to change at page 24, line 4 skipping to change at page 24, line 30
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 8.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, KMID, 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.
A new registry needs to be set up for the KMID parameter, with the The IANA is hereby requested to create a new subregistry for the
following registration created initially: "mikey". KMPID parameter, with the following registration created initially:
"mikey".
Contact: Fredrik Lindholm
mailto: fredrik.lindholm@ericsson.com
tel: +46 8 58531705
Value name: mikey Value name: mikey
Long name: Multimedia Internet KEYing Long name: Multimedia Internet KEYing
Purpose: Usage of MIKEY with the key-mgmt-att-field Purpose: Usage of MIKEY with the key-mgmt-att-field
attribute and the keymgmt RTSP header attribute and the keymgmt RTSP header
Reference: Section 7 in RFC 3830 Reference: Section 7 in RFC 3830
Note that this registration implies that the protocol identifier, Note that this registration implies that the protocol identifier,
KMID, name space will be shared between SDP and RTSP. KMPID, name space will be shared between SDP and RTSP.
Further values may be registered according to the "Specification Further values may be registered according to the "Specification
Required" policy as defined in [RFC2434]. Each new registration needs Required" policy as defined in [RFC2434]. Each new registration needs
to indicate the parameter name, and register it within IANA. Note to indicate the parameter name, and register it within IANA. Note
that the parameter name is case sensitive and it is RECOMMENDED that that the parameter name is case sensitive and it is RECOMMENDED that
the name to be in lower case letters. For each new registration, it the name to be in lower case letters. For each new registration, it
is mandatory that a permanent, stable, and publicly accessible is mandatory that a permanent, stable, and publicly accessible
document exists that specifies the semantics of the registered document exists that specifies the semantics of the registered
parameter and the requested details of interaction between the key parameter and the requested details of interaction between the key
management protocol and SDP, as specified in RFC xxxx. management protocol and SDP, as specified in RFC xxxx.
New values MUST be register with IANA. Registrations SHALL include New values MUST be register with IANA. Registrations SHALL include
the following information: the following information:
* 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 KMID 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 9. 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,
skipping to change at page 25, line 20 skipping to change at page 25, line 42
Perkins and Magnus Westerlund, who contributed in many sections. Perkins and Magnus Westerlund, who contributed in many sections.
10. Author's Addresses 10. 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 Research 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
Fredrik Lindholm Fredrik Lindholm
Ericsson Research Ericsson
SE-16480 Stockholm Phone: +46 8 58531705 SE-16480 Stockholm Phone: +46 8 58531705
Sweden EMail: fredrik.lindholm@ericsson.com Sweden EMail: fredrik.lindholm@ericsson.com
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
skipping to change at page 26, line 33 skipping to change at page 27, line 8
[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.
[SDES] Andreasen, F., Baugher, M., Wing, D., "Session Description
Protocol Security Descriptions for Media Streams", work in progress,
February 2005.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman, [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman,
K., "The Secure Real-time Transport Protocol", IETF, RFC 3711. K., "The Secure Real-time Transport Protocol", IETF, RFC 3711.
[SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security [SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security
Preconditions for Session Description Protocol Media Streams", work Preconditions for Session Description Protocol Media Streams", work
in progress, February 2004. in progress, February 2004.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). 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 August 2005. This Internet-Draft expires in September 2005.
 End of changes. 

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