draft-ietf-mmusic-kmgmt-ext-12.txt   draft-ietf-mmusic-kmgmt-ext-13.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: April 2005 M. Naslund Expires: August 2005 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
November 2004 February 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-12.txt> <draft-ietf-mmusic-kmgmt-ext-13.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am (we are) aware have been patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79). accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I accept the provisions of Section By submitting this Internet-Draft, I accept the provisions of Section
3 of RFC 3667 (BCP 78). 3 of RFC 3667 (BCP 78).
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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................................................5
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..........................................11
3.1.4 Bidding-down attack prevention...............................11 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................................................20 6.1 MIKEY Interface................................................21
7. Security Considerations.........................................21 7. Security Considerations.........................................21
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.............................................23
8.3. Protocol Identifier Registration..............................23 8.3. Protocol Identifier Registration..............................24
9. Acknowledgments.................................................24 9. Acknowledgments.................................................25
10. Author's Addresses.............................................25 10. Author's Addresses.............................................25
11. References.....................................................25 11. References.....................................................25
11.1. Normative References.........................................25 11.1. Normative References.........................................25
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.
skipping to change at page 9, line 19 skipping to change at page 9, line 19
The general processing for handling a received answer SHALL follow The general processing for handling a received answer SHALL follow
the following actions: the following actions:
* The key management protocol is identified according to the prtcl-id * The key management protocol is identified according to the prtcl-id
field. field.
* The key management data from the keymgmt-data field MUST be * The key management data from the keymgmt-data field MUST be
extracted, base64 decoded to reconstruct the original message, and extracted, base64 decoded to reconstruct the original message, and
then passed to the key management protocol for processing. then passed to the key management protocol for processing.
* If errors occur, or the key management offer is rejected, the * If the key management offer is rejected and the intent is to re-
session SHALL be aborted. If possible an error message indicating negotiate it, it MUST be done through another Offer/Answer
the failure SHOULD be sent back. exchange. It is RECOMMENDED to NOT abort the session in that case,
but to re-negotiate using another Offer/Answer exchange. For
example, in SIP [RFC3261], the "security precondition" as defined
in [SPREC} solves the problem for a session initiation. The
procedures in [SPREC] are outside the scope of this document. In
an established session, an additional Offer/Answer exchange using
a re-INVITE or UPDATE as appropriate MAY be used.
* If errors occur, or the key management offer is rejected and there
is no intent to re-negotiate it, the session SHALL be aborted. If
possible an error message indicating the failure SHOULD be sent
back.
Otherwise, if all the steps are successful, the normal setup Otherwise, if all the steps are successful, the normal setup
proceeds. proceeds.
3.1.2 Use of SDP with offer/answer and SIP 3.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).
skipping to change at page 9, line 52 skipping to change at page 10, line 14
* Before, or in conjunction with, passing the key management data to * Before, or in conjunction with, passing the key management data to
the key management protocol, the complete list of protocol the key management protocol, the complete list of protocol
identifier from the offer message is provided by the SDP identifier from the offer message is provided by the SDP
application to the key management protocol (as defined in Section application to the key management protocol (as defined in Section
3.1.4). 3.1.4).
When an answer is created, the following offer-answer specific When an answer is created, the following offer-answer specific
procedure SHALL be applied: procedure SHALL be applied:
* If the key management rejects the offer, the answerer SHOULD return * If the key management rejects the offer and the intent is to re-
a "488 Not Acceptable Here" message, optionally also including one negotiate it, the Answer SHOULD include the cause of failure in an
or more Warning headers (a 306 "Attribute not understood" when one included message from the key management protocol. The
of the parameters is not supported, and a 399 "Miscellaneous renegotiation MUST be done through another Offer/Answer exchange
warning" with arbitrary information to be presented to a human (e.g, using [SPREC]). In an established session, it can also be
user or logged, see Section 20.43 in [SIP]). Further details about done through a re-INVITE or UPDATE as appropriate.
the cause of failure MAY be described in an included message from
the key management protocol. The session is then aborted (and it * If the key management rejects the offer and the session needs to be
is up to local policy or end user to decide how to continue). aborted, the answerer SHOULD return a "488 Not Acceptable Here"
message, optionally also including one or more Warning headers (a
306 "Attribute not understood" when one of the parameters is not
supported, and a 399 "Miscellaneous warning" with arbitrary
information to be presented to a human user or logged, see Section
20.43 in [SIP]). Further details about the cause of failure MAY be
described in an included message from the key management protocol.
The session is then aborted (and it is up to local policy or end
user to decide how to continue).
Note that the key management attribute (related to the same key Note that the key management attribute (related to the same key
management protocol) MAY be present both at session level and at management protocol) MAY be present both at session level and at
media level. Consequently, the process SHALL be repeated for each media level. Consequently, the process SHALL be repeated for each
such key management attribute detected. In case the key management such key management attribute detected. In case the key management
processing of any such attribute does not succeed (e.g. processing of any such attribute does not succeed (e.g.
authentication failure, parameters not supported etc.), on either authentication failure, parameters not supported etc.), on either
session or media level, the entire session setup SHALL be aborted, session or media level, the entire session setup SHALL be aborted,
including those parts of the session that successfully completed including those parts of the session that successfully completed
their part of the key management. their part of the key management.
skipping to change at page 10, line 35 skipping to change at page 10, line 55
different key management protocol, thus indicating supported different key management protocol, thus indicating supported
alternatives. alternatives.
If the offerer includes more than one key management protocol If the offerer includes more than one key management protocol
attribute at session level (analogous for the media level), these attribute at session level (analogous for the media level), these
SHOULD be listed in order of preference (the first being the SHOULD be listed in order of preference (the first being the
preferred). The answerer selects the key management protocol it preferred). The answerer selects the key management protocol it
wishes to use, and processes only it, on either session or media wishes to use, and processes only it, on either session or media
level, or on both, according to where located. If the answerer does level, or on both, according to where located. If the answerer does
not support any of the offerer's suggested key management protocols, not support any of the offerer's suggested key management protocols,
the receiver returns a "488 Not Acceptable Here" error message, the answerer indicates this to the offerer so a new Offer-Answer can
whereby the sender MUST abort the current setup procedure. be triggered; alternatevely, it may return a "488 Not Acceptable
Here" error message, whereby the sender MUST abort the current setup
procedure.
Note that the placement of multiple key management offers in a single 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. computational workload for the offerer will increase drastically.
Unless the guidelines of Section 3.1.4 are followed, multiple lines Unless the guidelines of Section 3.1.4 are followed, multiple lines
may open up bidding-down attacks. Note also that the multiple offer may open up bidding-down attacks. Note also that the multiple offer
option has been added to optimize signaling overhead in case the option has been added to optimize signaling overhead in case the
Initiator knows some key (e.g. a public key) that the Responder has, Initiator knows some key (e.g. a public key) that the Responder has,
but is unsure of what protocol the Responder supports. The mechanism but is unsure of what protocol the Responder supports. The mechanism
is not intended to negotiate options within one and the same is not intended to negotiate options within one and the same
skipping to change at page 20, line 47 skipping to change at page 21, line 15
the identity from the RTSP authentication if used. the identity from the RTSP authentication if used.
6.1 MIKEY Interface 6.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).
Implementers of MIKEY are RECOMMENDED to consider providing at least The following aspects need to be considered:
the following functionality:
* the possibility for MIKEY to receive information about the sessions * the possibility for MIKEY to receive information about the sessions
negotiated. This is to some extent implementation dependent. But negotiated. This is to some extent implementation dependent. But
it is RECOMMENDED that, in the case of SRTP streams, the number of it is RECOMMENDED that, in the case of SRTP streams, the number of
SRTP streams is included (and the direction of these). It is also SRTP streams is included (and the direction of these). It is also
RECOMMENDED to provide the destination addresses and ports to RECOMMENDED to provide the destination addresses and ports to
MIKEY. When referring to streams described in SDP, MIKEY allocated MIKEY. When referring to streams described in SDP, MIKEY SHALL
two consecutive numbers for the related Crypto Session indexes (as allocate two consecutive numbers for the related Crypto Session
each stream can be bi-directional). An example: if the SDP indexes (as each stream can be bi-directional). An example: if the
contains two m lines (specifying whatever direction of the SDP contains two m lines (specifying whatever direction of the
streams), and MIKEY is at the session level, then MIKEY allocates streams), and MIKEY is at the session level, then MIKEY allocates
e.g. the Crypto Sessions Identifiers (CS IDs, see [MIKEY)] '1' and e.g. the Crypto Sessions Identifiers (CS IDs, see [MIKEY)] '1' and
'2' for the first m line, and '3' and '4' for the second m line. '2' for the first m line, and '3' and '4' for the second m line.
* the possibility for MIKEY to receive incoming MIKEY messages and * the possibility for MIKEY to receive incoming MIKEY messages and
return a status code from/to the SIP/RTSP application. return a status code from/to the SIP/RTSP application.
* the possibility for the SIP or RTSP applications to receive * the possibility for the SIP or RTSP applications to receive
information from MIKEY. This would typically include the receiving information from MIKEY. This would typically include the receiving
of the Crypto Session Bundle Identifier (CSB ID, see [MIKEY], to of the Crypto Session Bundle Identifier (CSB ID, see [MIKEY], to
skipping to change at page 24, line 42 skipping to change at page 25, line 7
* 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 KMID 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 Rolf Blom, Johan Bilien, Magnus The authors would like to thank Francois Audet, Rolf Blom, Johan
Brolin, Erik Eliasson, Martin Euchner, Joerg Ott, Jon Peterson, and Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries,
Jon-Olov Vatn. A special thanks to Colin Perkins and Magnus Joerg Ott, Jon Peterson, and Jon-Olov Vatn. A special thanks to Colin
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 Research
skipping to change at page 26, line 49 skipping to change at page 27, line 7
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 April 2005. This Internet-Draft expires in August 2005.
 End of changes. 

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