draft-ietf-mmusic-kmgmt-ext-06.txt   draft-ietf-mmusic-kmgmt-ext-07.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 2003 M. Naslund Expires: August 2003 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
February, 2003 February, 2003
Key Management Extensions for SDP and RTSP Key Management Extensions for Session Description
<draft-ietf-mmusic-kmgmt-ext-06.txt> Protocol (SDP) and Real Time Streaming Protocol (RTSP)
<draft-ietf-mmusic-kmgmt-ext-07.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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. together with SIP and RTSP.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.....................................................2 1. Introduction.....................................................2
1.1. Notational Conventions.........................................3 1.1. Notational Conventions.........................................3
2. Extensions to SDP and RTSP.......................................3 2. Extensions to SDP and RTSP.......................................3
2.1. SDP Extensions.................................................4 2.1. SDP Extensions.................................................4
2.2. RTSP Extensions................................................4 2.2. RTSP Extensions................................................5
3. Usage with SIP and RTSP..........................................5 3. Usage with SIP and RTSP..........................................5
3.1. General SDP processing.........................................5 3.1. General SDP processing.........................................5
3.2. SIP usage......................................................6 3.2. SIP usage......................................................7
3.3. RTSP usage.....................................................7 3.3. RTSP usage.....................................................8
3.4. Example scenarios..............................................7 3.4. Example scenarios..............................................9
4. Adding further Key management protocols.........................10 4. Adding further Key management protocols.........................11
5. Security Considerations.........................................10 5. Security Considerations.........................................11
6. IANA Considerations.............................................11 6. IANA Considerations.............................................12
7. Conclusions.....................................................11 6.1. SDP Attribute Registration....................................12
8. Acknowledgments.................................................11 6.2. Protocol Identifier Registration..............................13
9. Author's Addresses..............................................11 7. Conclusions.....................................................13
10. References.....................................................12 8. Acknowledgments.................................................13
10.1. Normative References.........................................12 9. Author's Addresses..............................................14
10.2. Informative References.......................................12 10. References.....................................................14
10.1. Normative References.........................................14
10.2. Informative References.......................................15
1. Introduction 1. Introduction
[Editor remark] All instances of RFC xxxx should be replaced with
the RFC number of this document, when published. Furthermore, all
instances of RFC yyyy should be replaced with the RFC number of
the MIKEY (Multimedia Internet KEYing) document [MIKEY], when
published.
There has recently been work to define a security framework for the There has recently been work to define a security framework 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 infrastructure to However, a security protocol needs a key management infrastructure to
exchange keys and security parameters, managing and refreshing keys, exchange keys and security parameters, managing and refreshing keys,
etc. etc.
A key management protocol is executed prior to the security protocol A key management protocol is executed prior to the security protocol
execution. The key management protocol's main goal is to, in a secure execution. The key management protocol's main goal is to, in a secure
and reliable way, establish a so-called security association for the and reliable way, establish a so-called security association for the
security protocol. This includes one or several cryptographic keys security protocol. This includes one or several cryptographic keys
skipping to change at page 4, line 40 skipping to change at page 4, line 50
key-mgmt = "key-mgmt: " prtcl-id keymgmt-data key-mgmt = "key-mgmt: " prtcl-id keymgmt-data
prtcl-id = non-ws-string prtcl-id = non-ws-string
; e.g. "mikey" ; e.g. "mikey"
keymgmt-data = text keymgmt-data = text
where non-ws-string and text are as defined in SDP [SDPnew]. The where non-ws-string and text are as defined in SDP [SDPnew]. The
attribute may be used at session level, media level or at both 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. defined at session level. Note that the prtcl-id name will be case
sensitive and it is therefore RECOMMENDED that attributes registered
be in lower case letters.
2.2. RTSP Extensions 2.2. RTSP Extensions
To support the needed attribute described, the following RTSP header To support the needed attribute described, the following RTSP header
is defined: is defined:
KeyMgmt = "keymgmt" ":" 1#key-mgmt-spec KeyMgmt = "keymgmt" ":" 1#key-mgmt-spec
key-mgmt-spec = "prot" "=" token ";" "data" "=" quoted-string key-mgmt-spec = "prot" "=" token ";" "data" "=" quoted-string
skipping to change at page 5, line 39 skipping to change at page 6, line 5
use the described attribute and header, e.g. Kerberos [KERB]. use the described attribute and header, e.g. Kerberos [KERB].
3.1. General SDP processing 3.1. General SDP processing
When an SDP message is created, the following procedure should be When an SDP message is created, the following procedure should be
applied: applied:
* The identifier of the key management protocol used (e.g. MIKEY or * The identifier of the key management protocol used (e.g. MIKEY or
Kerberos) MUST be put in the prtcl-id field. Kerberos) MUST be put in the prtcl-id field.
* The keymgmt-data field MUST be created with the data received from * The keymgmt-data field MUST be created as follows. The key
the key management protocol (this data MUST be base64 encoded). management protocol MUST be used to create the key management
The data may e.g. be a MIKEY message or Kerberos ticket. message. This message SHALL be base64 encoded by SDP and then
encapsulated in the keymgmt-data attribute. The data may e.g. be a
MIKEY message (see [MIKEY], Section 7) or Kerberos ticket.
A received SDP message that contains the key management attributes A received SDP message that contains the key management attributes
SHOULD process these attributes in the following manner: SHOULD process these attributes in the following manner:
* The key management protocol used MUST be identified by checking the * The key management protocol used MUST be identified by checking the
prtcl-id field in the key management attribute. prtcl-id field in the key management attribute.
* The key management data from the keymgmt-data field MUST be * The key management data from the keymgmt-data field MUST be
extracted and given to the key management protocol. Note that extracted, base64 decoded to reconstruct the original message, and
depending on key management protocol, some extra parameters might then passed to the key management protocol for further processing.
of course be requested, such as the source/destination network Note that depending on key management protocol, some extra
address/port(s) for the specified media. parameters might of course be requested by the API, such as the
source/destination network address/port(s) for the specified media
(however, the key management interface specification should
specify this).
* Depending on the outcome of the key management processing (i.e. * Depending on the outcome of the key management processing (i.e.
whether it was accepted or not), the processing can proceed whether it was accepted or not), the processing can proceed
according to normal processing (e.g. according to the offer/answer according to normal processing (e.g. according to the offer/answer
model, see also Section 3.2). model, see also Section 3.2).
Note that the attribute MAY be repeated more than once (e.g., one at Note that the attribute MAY be repeated more than once (e.g., one at
session level and one at media level). Consequently, the process is session level and one at media level). Consequently, the process is
repeated for each key management attribute detected. repeated for each key management attribute detected.
skipping to change at page 6, line 29 skipping to change at page 6, line 50
If the sender includes more than one key management protocol If the sender includes more than one key management protocol
attributes at session level (analogous for the media level), these attributes at session level (analogous for the media level), these
SHOULD be listed in order of preference (with the first being the SHOULD be listed in order of preference (with the first being the
preferred). The receiver chooses the key management protocol it preferred). The receiver chooses the key management protocol it
supports. When answering, only the accepted key management protocol supports. When answering, only the accepted key management protocol
attribute MUST be included. If the receiver does not support any of attribute MUST be included. If the receiver does not support any of
the sender's suggested key management protocols, the receiver answers the sender's suggested key management protocols, the receiver answers
with an error message (see SIP and RTSP), whereby the sender MUST put with an error message (see SIP and RTSP), whereby the sender MUST put
down the current setup procedure. down the current setup procedure.
Note that by placing multiple key management offers in a single Note that the placement of multiple key management offers in a single
message has the disadvantage that the message expands and the message has the disadvantage that the message expands and the
computational workload for the offerer will increase drastically. The computational workload for the offerer will increase drastically. The
possibility to support multiple key management protocols may possibility to support multiple key management protocols may
introduce bidding down attacks. To avoid this, the list of introduce bidding down attacks. To avoid this, the list of
identifiers of the proposed key management protocols MUST be identifiers of the proposed key management protocols MUST be
authenticated, which MUST be done by each key management. This puts authenticated, which MUST be done by each key management.
the requirement that it MUST be specified (in the key management
protocol itself or in a companion document) how the protocol This puts the requirement that it MUST be specified (in the key
identifiers could be authenticated from the offerer to the responder management protocol itself or in a companion document) how the
by the use of the specific key management protocol. Note that even if protocol identifiers could be authenticated from the offerer to the
only one key management protocol is used, that still must responder by the use of the specific key management protocol. Note
authenticate its own protocol identifier. that even if only one key management protocol is used, that still
must authenticate its own protocol identifier. If the key management
protocol fails to authenticate the protocol list, it MUST return an
error message to SDP.
The list of protocol identifiers MUST be given to the selected key
management protocol by SDP with ";" separated identifiers. All the
offered protocol identifiers MUST be included, in the same order as
they appear in the corresponding SDP description.
The protocol list can formally be described as
prtcl-list = prtcl-id *(";" prtcl-id)
prtcl-id = non-ws-string
Example
v=0
o=alice 2891092738 2891092738 IN IP4 lost.downunder.dom
s=Secret discussion
t=0 0
c=IN IP4 lost.downunder.dom
a=key-mgmt:mikey <data1>
a=key-mgmt:keyp1 <data2>
a=key-mgmt:keyp2 <data3>
m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 42000 RTP/SAVP 31
a=rtpmap:31 H261/90000
The protocol list, "mikey;keyp1;keyp2", would be generated from
the SDP description and used as input to the selected key
management protocol (together with the data for that protocol).
If more than one protocol is supported by the offerer, it is If more than one protocol is supported by the offerer, it is
RECOMMENDED that he offers all to him acceptable protocols in the RECOMMENDED that he offers all to him acceptable protocols in the
first offer, rather than making single, subsequent alternative offers first offer, rather than making single, subsequent alternative offers
in response to error messages, see "Security Considerations". in response to error messages, see "Security Considerations".
3.2. SIP usage 3.2. SIP usage
The offerer SHOULD include the key management data within an offer The offerer SHOULD include the key management data within an offer
that contains the media description it should apply to. The answerer that contains the media description it should apply to. The answerer
skipping to change at page 7, line 17 skipping to change at page 8, line 18
If the offer is not accepted, the answerer SHOULD return a "606 Not If the offer is not accepted, the answerer SHOULD return a "606 Not
Acceptable" message, including one or more Warning headers (at least Acceptable" message, including one or more Warning headers (at least
a 306). The offer MUST then abort the security setup. a 306). The offer MUST then abort the security setup.
Re-keying can be handled as a new offer, i.e. a re-INVITE should be Re-keying can be handled as a new offer, i.e. a re-INVITE should be
sent with the new proposed parameters. The answerer treats this as a sent with the new proposed parameters. The answerer treats this as a
new offer where the key management is the issue of change. In new offer where the key management is the issue of change. In
general, the re-INVITE (and the key exchange) must be finalized general, the re-INVITE (and the key exchange) must be finalized
before the security protocol can change the keys. The synchronization before the security protocol can change the keys. The synchronization
method used when changing keys are dependent on the security and key method used when changing keys are dependent on the security and key
management protocol used. management protocol used. The same protocol used in the original
INVITE SHALL also be used in the re-INVITE carrying re-keying. If the
re-INVITE carrying re-keying fails (e.g., the authentication
verification fails), the answerer SHOULD send a "606 Not Acceptable"
message, including one or more Warning headers (at least a 306). The
offer MUST then abort the security setup.
3.3. RTSP usage 3.3. 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 abusing RTSP) to send some problems, as it is not possible (without abusing RTSP) to send
back an answer to the server (as the server will in most cases be the back an answer to the server (as the server will in most cases be the
one initiating the security parameter exchange). To solve this, a new one initiating the security parameter exchange). To solve this, a new
header has been introduced (Section 2.2). This also assumes that the header has been introduced (Section 2.2). This also assumes that the
key management also has some kind of binding to the media, so that key management also has some kind of binding to the media, so that
the response to the server will be processed as required. the response to the server will be processed as required.
skipping to change at page 10, line 50 skipping to change at page 12, line 13
the key management schemes are secure, the SDP can be passed along the key management schemes are secure, the SDP can be passed along
unprotected without affecting the key management, and the media unprotected without affecting the key management, and the media
streams will still be secure even if some attackers gained knowledge streams will still be secure even if some attackers gained knowledge
of the SDP contents. of the SDP contents.
However, if the SDP messages are not sent authenticated between the However, if the SDP messages are not sent authenticated between the
parties, it is possible for an active attacker to change attributes parties, it is possible for an active attacker to change attributes
without being detected. As the key management protocol may without being detected. As the key management protocol may
(indirectly) rely on some of the session information from SDP (e.g., (indirectly) rely on some of the session information from SDP (e.g.,
address information), an attack on SDP may have indirect consequences address information), an attack on SDP may have indirect consequences
on the key management. In general, it is therefore a good thing, not on the key management. Even if the key management protocol does not
only to try to secure the session, but also to secure the session rely on parameters of SDP and will not be affected by manipulation of
setup. these, different DoS attacks aimed at SDP (e.g. the SIMCAP
extensions) may lead to undesired interruption in the setup. In
general, it is therefore a good thing, not only to try to secure the
session, but also to secure the session setup. However, a solution
for this might not necessarily need to be end-to-end, but could also
be hop-by-hop depending on the trust model for the specific use case.
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
he/she declines the offer usually means that he/she does not support the answerer declines the offer usually means that he does not
the protocol(s) offered, and consequently cannot be expected to support the protocol(s) offered, and consequently cannot be expected
authenticate the response either. This means that if the initiator is to authenticate the response either. This means that if the initiator
unsure of which protocol(s) the responder supports, we RECOMMEND that is unsure of which protocol(s) the responder supports, we RECOMMEND
the initiator offers all acceptable protocols in a single offer. If that the initiator offers all acceptable protocols in a single offer.
not, this opens up the possibility for a "man-in-the-middle" (MITM) If not, this opens up the possibility for a "man-in-the-middle"
to affect the outcome of the eventually agreed upon protocol, by (MITM) to affect the outcome of the eventually agreed upon protocol,
faking unauthenticated error messages until the initiator eventually by faking unauthenticated error messages until the initiator
offers a protocol "to the liking" of the MITM. This is not really a eventually offers a protocol "to the liking" of the MITM. This is not
security problem, but rather a mild form of denial of service that really a security problem, but rather a mild form of denial of
can be avoided by following the above recommendation. service that can be avoided by following the above recommendation.
6. IANA Considerations 6. IANA Considerations
New attribute fields for SDP (see Section 2.1) and RTSP header are 6.1. SDP Attribute Registration
registered (see Section 2.2).
A new SDP attribute needs to be defined for the purpose of key
management protocol integration with SDP.
Contact: Fredrik Lindholm
mailto: fredrik.lindholm@era.ericsson.se
tel: +46 8 58531705
SDP Attribute ("att-field"):
Name: key-mgmt
Long form: key management protocol
Type of name: att-field
Type of attribute: Media and session level
Purpose: See RFC xxxx, Section 2.
Reference: RFC xxxx, Section 2.1
Values: See registrations below
6.2. Protocol Identifier Registration
This document defines one new name space associated with the above
registered key-mgmt attribute i.e., the protocol identifier (see also
Section 2.1 and Section 2.2).
A new registry needs to be set up for "prtcl-id" parameter of the
"key-mgmt" attribute, with the following registration created
initially: "mikey".
Contact: Fredrik Lindholm
mailto: fredrik.lindholm@era.ericsson.se
tel: +46 8 58531705
Value name: mikey
Long name: Multimedia Internet KEYing
Purpose: Usage of MIKEY with the key-mgmt attribute
Reference: Section 7 in RFC yyyy
Further entries may be registered according to the "Specification
Required" policy as defined in RFC 2434 [GWISC]. Each new
registration needs to indicate the parameter name and the syntax of
possible additional arguments. Note that the parameter name is case
sensitive and it is recommended that the name should be in lower case
letters. For each new registration, it is mandatory that a permanent,
stable, and publicly accessible document exists that specifies the
semantics of the registered parameter, the syntax and semantics of
its parameters as well as all the requested details of interaction
between the key management protocol and SDP, as specified in this
document.
7. Conclusions 7. Conclusions
A security solution for real-time applications needs a key management A security solution for real-time applications needs a key management
infrastructure. Integrating the key management scheme with the infrastructure. Integrating the key management scheme with the
session establishment protocol could be done efficiently in most of session establishment protocol could be done efficiently in most of
the scenarios. This draft proposes a framework that integrates a key the scenarios. This draft proposes a framework that integrates a key
management protocol (e.g., MIKEY) into SIP and RTSP, and which can be management protocol (e.g., MIKEY) into SIP and RTSP, and which can be
accompanied by different key management protocols. A set of new accompanied by different key management protocols. A set of new
attributes and headers has been defined in SDP and RTSP to support attributes and headers has been defined in SDP and RTSP to support
skipping to change at page 12, line 39 skipping to change at page 14, line 51
[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.
[SDPnew] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session [SDPnew] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session
Description Protocol", Internet Draft, IETF, Work in progress Description Protocol", Internet Draft, IETF, Work in progress
(MMUSIC). (MMUSIC).
[SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J.,
"SIP: Session Initiation Protocol", IETF, RFC 2543. "SIP: Session Initiation Protocol", IETF, RFC 2543.
[GWISC] Narten, T. and Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", IETF, RFC 2434.
10.2. Informative References 10.2. Informative References
[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.
[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", Internet Draft, Norrman, K., "MIKEY: Multimedia Internet KEYing", IETF, RFC yyyy,
IETF, Work in progress (MSEC). [Internet Draft, Work in progress (MSEC)].
[SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M, [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M,
Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol",
Internet Draft, IETF, Work in Progress (AVT). Internet Draft, IETF, Work in Progress (AVT).
This Internet-Draft expires in August 2003. This Internet-Draft expires in August 2003.
 End of changes. 

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