diff options
Diffstat (limited to 'doc/rfc/rfc4567.txt')
| -rw-r--r-- | doc/rfc/rfc4567.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc4567.txt b/doc/rfc/rfc4567.txt new file mode 100644 index 0000000..35f65ca --- /dev/null +++ b/doc/rfc/rfc4567.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group J. Arkko +Request for Comments: 4567 F. Lindholm +Category: Standards Track M. Naslund + K. Norrman + Ericsson + E. Carrara + Royal Institute of Technology + July 2006 + + + Key Management Extensions for Session Description + Protocol (SDP) and Real Time Streaming Protocol (RTSP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines general extensions for Session Description + Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry + messages, as specified by a key management protocol, in order to + secure the media. These extensions are presented as a framework, to + be used by one or more key management protocols. As such, their use + is meaningful only when complemented by an appropriate key management + protocol. + + General guidelines are also given on how the framework should be used + together with SIP and RTSP. The usage with the Multimedia Internet + KEYing (MIKEY) key management protocol is also defined. + + + + + + + + + + + + + +Arkko, et al. Standards Track [Page 1] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Notational Conventions .....................................4 + 2. Applicability ...................................................4 + 3. Extensions to SDP and RTSP ......................................5 + 3.1. SDP Extensions .............................................5 + 3.2. RTSP Extensions ............................................6 + 4. Usage with SDP, SIP, RTSP, and SAP ..............................7 + 4.1. Use of SDP .................................................8 + 4.1.1. General Processing ..................................8 + 4.1.2. Use of SDP with Offer/Answer and SIP ...............10 + 4.1.3. Use of SDP with SAP ................................13 + 4.1.4. Bidding-Down Attack Prevention .....................13 + 4.2. RTSP Usage ................................................14 + 5. Example Scenarios ..............................................17 + 5.1. Example 1 (SIP/SDP) .......................................17 + 5.2. Example 2 (SDP) ...........................................18 + 5.3. Example 3 (RTSP) ..........................................18 + 5.4. Example 4 (RTSP) ..........................................20 + 6. Adding Further Key Management Protocols ........................21 + 7. Integration of MIKEY ...........................................22 + 7.1. MIKEY Interface ...........................................22 + 8. Security Considerations ........................................23 + 9. IANA Considerations ............................................25 + 9.1. SDP Attribute Registration ................................25 + 9.2. RTSP Registration .........................................26 + 9.3. Protocol Identifier Registration ..........................26 + 10. Acknowledgements ..............................................27 + 11. References ....................................................27 + 11.1. Normative References .....................................27 + 11.2. Informative References ...................................28 + + + + + + + + + + + + + + + + + + + +Arkko, et al. Standards Track [Page 2] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + +1. Introduction + + There has recently been work to define a security profile for the + protection of real-time applications running over RTP, [SRTP]. + However, a security protocol needs a key management solution to + exchange keys and security parameters, manage and refresh keys, etc. + + A key management protocol is executed prior to the security + protocol's execution. The key management protocol's main goal is to, + in a secure and reliable way, establish a security association for + the security protocol. This includes one or more cryptographic keys + and the set of necessary parameters for the security protocol, e.g., + cipher and authentication algorithms to be used. The key management + protocol has similarities with, e.g., SIP [SIP] and RTSP [RTSP] in + the sense that it negotiates necessary information in order to be + able to set up the session. + + The focus in the following sections is to describe a new SDP + attribute and RTSP header extension to support key management, and to + show how these can be integrated within SIP and RTSP. The resulting + framework is completed by one or more key management protocols, which + use the extensions provided. + + Some of the motivations to create a framework with the possibility to + include the key management in the session establishment are: + + * Just as the codec information is a description of how to encode and + decode the audio (or video) stream, the key management data is a + description of how to encrypt and decrypt the data. + + * The possibility to negotiate the security for the entire multimedia + session at the same time. + + * The knowledge of the media at session establishment makes it easy + to tie the key management to the multimedia sessions. + + * This approach may be more efficient than setting up the security + later, as that approach might force extra roundtrips, possibly also + a separate setup for each stream, hence implying more delay to the + actual setup of the media session. + + * The possibility to negotiate keying material end-to-end without + applying end-to-end protection of the SDP (instead, hop-by-hop + security mechanisms can be used, which may be useful if + intermediate proxies need access to the SDP). + + + + + + +Arkko, et al. Standards Track [Page 3] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + Currently in SDP [SDPnew], there exists one field to transport keys, + the "k=" field. However, this is not enough for a key management + protocol as there are many more parameters that need to be + transported, and the "k=" field is not extensible. The approach used + is to extend the SDP description through a number of attributes that + transport the key management offer/answer and also to associate it + with the media sessions. SIP uses the offer/answer model [OAM] + whereby extensions to SDP will be enough. However, RTSP [RTSP] does + not use the offer/answer model with SDP, so a new RTSP header is + introduced to convey key management data. [SDES] uses the approach + of extending SDP, to carry the security parameters for the media + streams. However, the mechanism defined in [SDES] requires end-to- + end protection of the SDP by some security protocol such as S/MIME, + in order to get end-to-end protection. The solution described here + focuses only on the end-to-end protection of key management + parameters and as a consequence does not require external end-to-end + protection means. It is important to note though, and we stress this + again, that only the key management parameters are protected. + + The document also defines the use of the described framework together + with the key management protocol Multimedia Internet KEYing (MIKEY) + [MIKEY]. + +1.1. Notational Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Applicability + + [SDES] provides similar cryptographic key distribution capabilities, + and it is intended for use when keying material is protected along + with the signaling. + + In contrast, this specification expects endpoints to have + preconfigured keys or common security infrastructure. It provides + its own security and is independent of the protection of signaling + (if any). As a result, it can be applied in environments where + signaling protection is not turned on, or used hop-by-hop (i.e., + scenarios where the SDP is not protected end-to-end). This + specification will, independently of the signaling protection + applied, ensure end-to-end security establishment for the media. + + + + + + + + +Arkko, et al. Standards Track [Page 4] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + +3. Extensions to SDP and RTSP + + This section describes common attributes that can be included in SDP + or RTSP when an integrated key management protocol is used. The + attribute values follow the general SDP and RTSP guidelines (see + [SDPnew] and [RTSP]). + + For both SDP and RTSP, the general method of adding the key + management protocol is to introduce new attributes, one identifier to + identify the specific key management protocol, and one data field + where the key management protocol data is placed. The key management + protocol data contains the necessary information to establish the + security protocol, e.g., keys and cryptographic parameters. All + parameters and keys are protected by the key management protocol. + + The key management data SHALL be base64 [RFC3548] encoded and comply + with the base64 grammar as defined in [SDPnew]. The key management + protocol identifier, KMPID, is defined as below in Augmented Backus- + Naur Form grammar (ABNF) [RFC4234]. + + KMPID = 1*(ALPHA / DIGIT) + + Values for the identifier, KMPID, are registered and defined in + accordance to Section 9. Note that the KMPID is case sensitive, and + it is RECOMMENDED that values registered are lowercase letters. + +3.1. SDP Extensions + + This section provides an ABNF grammar (as used in [SDPnew]) for the + key management extensions to SDP. + + Note that the new definitions are compliant with the definition of an + attribute field, i.e., + + attribute = (att-field ":" att-value) / att-field + + The ABNF for the key management extensions (conforming to the + att-field and att-value) are as follows: + + key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value + + key-mgmt-att-field = "key-mgmt" + key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data + + prtcl-id = KMPID + ; e.g., "mikey" + + + + + +Arkko, et al. Standards Track [Page 5] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + keymgmt-data = base64 + SP = %x20 + + where KMPID is as defined in Section 3 of this memo, and base64 is as + defined in SDP [SDPnew]. Prtcl-id refers to the set of values + defined for KMPID in Section 9. + + The attribute MAY be used at session level, media level, or at both + levels. An attribute defined at media level overrides an attribute + defined at session level. In other words, if the media-level + attribute is present, the session level attribute MUST be ignored for + this media. Section 4.1 describes in detail how the attributes are + used and how the SDP is handled in different usage scenarios. The + choice of the level depends, for example, on the particular key + management protocol. Some protocols may not be able to derive enough + key material for all the sessions; furthermore, possibly a different + protection to each session could be required. The particular + protocol might achieve this only by specifying it at the media level. + Other protocols, such as MIKEY, have instead those capabilities (as + it can express multiple security policies and derive multiple keys), + so it may use the session level. + +3.2. RTSP Extensions + + To support the key management attributes, the following RTSP header + is defined: + + KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec) + + key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %x22 URI %x22 ";"] + + where KMPID is as defined in Section 3 of this memo, "base64" as + defined in [SDPnew], and "URI" as defined in Section 3 of [RFC3986]. + + The "uri" parameter identifies the context for which the key + management data applies, and the RTSP URI SHALL match a (session or + media) URI present in the description of the session. If the RTSP + aggregated control URI is included, it indicates that the key + management message is on session level (and similarly the RTSP media + control URI that it applies to the media level). If no "uri" + parameter is present in a key-mgmt-spec the specification applies to + the context identified by the RTSP request URI. + + The KeyMgmt header MAY be used in the messages and directions + described in the table below. + + + + + + +Arkko, et al. Standards Track [Page 6] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + Method | Direction | Requirement + --------------------------------------------- + DESCRIBE response | S->C | RECOMMENDED + SETUP | C->S | REQUIRED + SETUP Response | S->C | REQUIRED (error) + + Note: Section 4.2 describes in detail how the RTSP extensions are + used. + + We define one new RTSP status code to report error due to any failure + during the key management processing (Section 4.2): + + Status-Code = "463" ; Key management failure + + A 463 response MAY contain a KeyMgmt header with a key management + protocol message that further indicates the nature of the error. + +4. Usage with SDP, SIP, RTSP, and SAP + + This section gives rules and recommendations of how/when to include + the defined key management attribute when SIP and/or RTSP are used + together with SDP. + + When a key management protocol is integrated with SIP/SDP and RTSP, + the following general requirements are placed on the key management: + + * At the current time, it MUST be possible to execute the key + management protocol in at most one request-response message + exchange. Future relaxation of this requirement is possible but + would introduce significant complexity for implementations + supporting multi-roundtrip mechanisms. + + * It MUST be possible from the SIP/SDP and RTSP application, using + the key management API, to receive key management data and + information of whether or not a message is accepted. + + The content of the key management messages depends on the key + management protocol that is used. However, the content of such key + management messages might be expected to be roughly as follows: the + key management Initiator (e.g., the offerer) includes the key + management data in a first message, containing the media description + it should apply to. This data in general consists of the security + parameters (including key material) needed to secure the + communication, together with the necessary authentication information + (to ensure that the message is authentic). + + + + + + +Arkko, et al. Standards Track [Page 7] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + At the Responder's side, the key management protocol checks the + validity of the key management message, together with the + availability of the parameters offered, and then provides the key + management data to be included in the answer. This answer may + typically authenticate the Responder to the Initiator, and also state + if the initial offer was accepted or not. Certain protocols might + require the Responder to include a selection of the security + parameters that he is willing to support. Again, the actual content + of such responses is dependent on the particular key management + protocol. + + Section 7 describes a realization of the MIKEY protocol using these + mechanisms. Procedures to be used when mapping new key management + protocols onto this framework are described in Section 6. + +4.1. Use of SDP + + This section describes the processing rules for the different + applications that use SDP for the key management. + +4.1.1. General Processing + + The processing when SDP is used is slightly different according to + the way SDP is transported, and if it uses an offer/answer or + announcement. The processing can be divided into four different + steps: + + 1) How to create the initial offer. + 2) How to handle a received offer. + 3) How to create an answer. + 4) How to handle a received answer. + + It should be noted that the last two steps may not always be + applicable, as there are cases where an answer cannot or will not be + sent back. + + The general processing for creating an initial offer SHALL follow the + following actions: + + * The identifier of the key management protocol used MUST be placed + in the prtcl-id field of SDP. A table of legal protocols + identifiers is maintained by IANA (see Section 9). + + + + + + + + + +Arkko, et al. Standards Track [Page 8] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + * The keymgmt-data field MUST be created as follows: the key + management protocol MUST be used to create the key management + message. This message SHALL be base64 encoded [RFC3548] by the SDP + application and then encapsulated in the keymgmt-data attribute. + Note though that the semantics of the encapsulated message is + dependent on the key management protocol that is used. + + The general processing for handling a received offer SHALL follow the + following actions: + + * The key management protocol is identified according to the prtcl-id + field. A table of legal protocols identifiers is maintained by + IANA (Section 9). + + * The key management data from the keymgmt-data field MUST be + extracted, base64 decoded to reconstruct the original message, and + then passed to the key management protocol for processing. Note + that depending on key management protocol, some extra parameters + might also be requested by the specific API, such as the + source/destination network address/port(s) for the specified media + (however, this will be implementation specific depending on the + actual API). The extra parameters that a key management protocol + might need (other than the ones defined here) MUST be documented, + describing their use, as well as the interaction of that key + management protocol with SDP and RTSP. + + * If errors occur, or the key management offer is rejected, the + session SHALL be aborted. Possible error messages are dependent on + the specific session establishment protocol. + + At this stage, the key management will have either accepted or + rejected the offered parameters. This MAY cause a response message + to be generated, depending on the key management protocol and the + application scenario. + + If an answer is to be generated, the following general actions SHALL + be performed: + + * The identifier of the key management protocol used MUST be placed + in the prtcl-id field. + + * The keymgmt-data field MUST be created as follows. The key + management protocol MUST be used to create the key management + message. This message SHALL be base64 encoded [RFC3548] by the SDP + application and then encapsulated in the keymgmt-data attribute. + The semantics of the encapsulated message is dependent on the key + management protocol that is used. + + + + +Arkko, et al. Standards Track [Page 9] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + The general processing for handling a received answer SHALL follow + the following actions: + + * The key management protocol is identified according to the prtcl-id + field. + + * The key management data from the keymgmt-data field MUST be + extracted, base64 decoded to reconstruct the original message, and + then passed to the key management protocol for processing. + + * If the key management offer is rejected and the intent is to re- + negotiate it, it MUST be done through another Offer/Answer + exchange. It is RECOMMENDED to NOT abort the session in that case, + but to re-negotiate using another Offer/Answer exchange. For + example, in [SIP], the "security precondition" as defined in + [SPREC] solves the problem for a session initiation. The + procedures in [SPREC] are outside the scope of this document. In + an established session, an additional Offer/Answer exchange using a + re-INVITE or UPDATE as appropriate MAY be used + + * If errors occur, or the key management offer is rejected and there + is no intent to re-negotiate it, the session SHALL be aborted. If + possible, an error message indicating the failure SHOULD be sent + back. + + Otherwise, if all the steps are successful, the normal setup + proceeds. + +4.1.2. Use of SDP with Offer/Answer and SIP + + This section defines additional processing rules, to the general + rules defined in Section 4.1.1, applicable only to applications using + SDP with the offer/answer model [OAM] (and in particular SIP). + + When an initial offer is created, the following offer/answer-specific + procedure SHALL be applied: + + * Before creating the key management data field, the list of protocol + identifiers MUST be provided by the SDP application to (each) key + management protocol, as defined in Section 4.1.4 (to defeat + bidding-down attacks). + + For a received SDP offer that contains the key management attributes, + the following offer/answer-specific procedure SHALL be applied: + + + + + + + +Arkko, et al. Standards Track [Page 10] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + * Before, or in conjunction with, passing the key management data to + the key management protocol, the complete list of protocol + identifiers from the offer message is provided by the SDP + application to the key management protocol (as defined in Section + 4.1.4). + + When an answer is created, the following offer/answer-specific + procedure SHALL be applied: + + * If the key management rejects the offer and the intent is to re- + negotiate it, the Answer SHOULD include the cause of failure in an + included message from the key management protocol. The + renegotiation MUST be done through another Offer/Answer exchange + (e.g., using [SPREC]). In an established session, it can also be + done through a re-INVITE or UPDATE as appropriate. + + * If the key management rejects the offer and the session needs to be + aborted, the answerer SHOULD return a "488 Not Acceptable Here" + message, optionally also including one or more Warning headers (a + "306 Attribute not understood" when one of the parameters is not + supported, and a "399 Miscellaneous warning" with arbitrary + information to be presented to a human user or logged; see Section + 20.43 in [SIP]). Further details about the cause of failure MAY be + described in an included message from the key management protocol. + The session is then aborted (and it is up to local policy or end + user to decide how to continue). + + Note that the key management attribute (related to the same key + management protocol) MAY be present both at session level and at + media level. Consequently, the process SHALL be repeated for each + such key management attribute detected. In case the key management + processing of any such attribute does not succeed (e.g., + authentication failure, parameters not supported, etc.), on either + session or media level, the entire session setup SHALL be aborted, + including those parts of the session that successfully completed + their part of the key management. + + If more than one key management protocol is supported, multiple + instances of the key management attribute MAY be included in the + initial offer when using the offer/answer model, each transporting a + different key management protocol, thus indicating supported + alternatives. + + If the offerer includes more than one key management protocol + attribute at session level (analogous for the media level), these + SHOULD be listed in order of preference (the first being the + preferred). The answerer selects the key management protocol it + wishes to use, and processes only it, on either session or media + + + +Arkko, et al. Standards Track [Page 11] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + level, or on both, according to where located. If the answerer does + not support any of the offerer's suggested key management protocols, + the answerer indicates this to the offerer so a new Offer/Answer can + be triggered; alternatively, it may return a "488 Not Acceptable + Here" error message, whereby the sender MUST abort the current setup + procedure. + + Note that the placement of multiple key management offers in a single + message has the disadvantage that the message expands and the + computational workload for the offerer will increase drastically. + Unless the guidelines of Section 4.1.4 are followed, multiple lines + may open up bidding-down attacks. Note also that the multiple-offer + option has been added to optimize signaling overhead in case the + Initiator knows some key (e.g., a public key) that the Responder has, + but is unsure of what protocol the Responder supports. The mechanism + is not intended to negotiate options within one and the same + protocol. + + The offerer MUST include the key management data within an offer that + contains the media description it applies to. + + Re-keying MUST be handled as a new offer, with the new proposed + parameters. The answerer treats this as a new offer where the key + management is the issue of change. The re-keying exchange MUST be + finalized before the security protocol can change the keys. The same + key management protocol used in the original offer SHALL also be used + in the new offer carrying re-keying. If the new offer carrying re- + keying fails (e.g., the authentication verification fails), the + answerer SHOULD send a "488 Not Acceptable Here" message, including + one or more Warning headers (at least a 306). The offerer MUST then + abort the session. + + Note that, in multicast scenarios, unlike unicast, there is only a + single view of the stream [OAM], hence there MUST be a uniform + agreement of the security parameters. + + After the offer is issued, the offerer SHOULD be prepared to receive + media, as the media may arrive prior to the answer. However, this + brings issues, as the offerer does not know yet the answerer's choice + in terms of, e.g., algorithms, or possibly the key is known. This + can cause delay or clipping can occur; if this is unacceptable, the + offerer SHOULD use mechanisms outside the scope of this document, + e.g., the security preconditions for SIP [SPREC]. + + + + + + + + +Arkko, et al. Standards Track [Page 12] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + +4.1.3. Use of SDP with SAP + + There are cases where SDP is used without conforming to the + offer/answer model; instead, it is a one-way SDP distribution (i.e., + without back channel), such as when used with SAP and HTTP. + + The processing follows the two first steps of the general SDP + processing (see Section 4.1.1). It can be noted that the processing + in this case differs from the offer/answer case in that only one key + management protocol SHALL be offered (i.e., no negotiation will be + possible). This implies that the bidding-down attack is not an + issue; therefore, the countermeasure is not needed. The key + management protocol used MUST support one-way messages. + +4.1.4. Bidding-Down Attack Prevention + + The possibility to support multiple key management protocols may, + unless properly handled, introduce bidding-down attacks. + Specifically, a man-in-the-middle could "peel off" cryptographically + strong offers (deleting the key management lines from the message), + leaving only weaker ones as the Responder's choice. To avoid this, + the list of identifiers of the proposed key management protocols MUST + be authenticated. The authentication MUST be done separately by each + key management protocol. + + Accordingly, it MUST be specified (in the key management protocol + specification itself or in a companion document) how the list of key + management protocol identifiers can be processed to be authenticated + from the offerer to the answerer by the specific key management + protocol. Note that even if only one key management protocol is + used, that still MUST authenticate its own protocol identifier. + + The list of protocol identifiers MUST then be given to each of the + selected (offered) key management protocols by the application 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 = KMPID *(";" KMPID) + + where KMPID is as defined in Section 3. + + For example, if the offered protocols are MIKEY and two yet-to-be- + invented protocols KEYP1, KEYP2, the SDP is: + + + + + +Arkko, et al. Standards Track [Page 13] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + v=0 + o=alice 2891092738 2891092738 IN IP4 lost.example.com + s=Secret discussion + t=0 0 + c=IN IP4 lost.example.com + a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... + a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD... + a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD... + 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 each specified key management + protocol (together with the data for that protocol). Each of the + three protocols includes this protocol identifier list in its + authentication coverage (according to its protocol specification). + + If more than one protocol is supported by the offerer, it is + RECOMMENDED that all acceptable protocols are included in the first + offer, rather than making single, subsequent alternative offers in + response to error messages; see "Security Considerations". + + End-to-end integrity protection of the key-mgmt attributes + altogether, provided externally to the key management itself, also + protects against this bidding-down attack. This is, for example, the + case if SIP uses S/MIME [RFC3851] to end-to-end integrity protect the + SDP description. However, as this end-to-end protection is not an + assumption of the framework, the mechanisms defined in this section + SHALL be applied. + +4.2. RTSP Usage + + RTSP does not use the offer/answer model, as SIP does. This causes + some problems, as it is not possible (without modifying RTSP) to send + back an answer. To solve this, a new header has been introduced + (Section 3.2). This also assumes that the key management also has + some kind of binding to the media, so that the response to the server + will be processed as required. + + The server SHALL be the Initiator of the key management exchange for + sessions in PLAY mode, i.e., transporting media from server to + client. The below text describes the behavior for PLAY mode. For + any other mode, the behavior is not defined in this specification. + + + + + + +Arkko, et al. Standards Track [Page 14] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + To obtain a session description, the client initially contacts the + server via a DESCRIBE message. The initial key management message + from the RTSP server is sent to the client in the SDP of the 200 OK + in response to the DESCRIBE. Note that only one key management + protocol SHALL be used per session/media level. A server MAY allow + the SDP with key management attribute(s) to be distributed to the + client through other means than RTSP, although this is not specified + here. + + The "uri" parameter of the KeyMgmt header is used to indicate for the + key management protocol on what context the carried message applies. + For key management messages on the SDP session level, the answer MUST + contain the RTSP aggregated control URL to indicate this. For key + management messages initially on SDP media level, the key management + response message in the KeyMgmt header MAY use the RTSP media-level + URL. For RTSP sessions not using aggregated control, i.e., no + session-level control URI is defined, the key management protocol + SHALL only be invoked on individual media streams. In this case + also, the key management response SHALL be on individual media + streams (i.e., one RTSP key management header per media). + + When responding to the initial key management message, the client + uses the new RTSP header (KeyMgmt) to send back an answer. How this + is done depends on the usage context: + + * Key management protocol responses for the initial establishment of + security parameters for an aggregated RTSP session SHALL be sent in + the first SETUP of the session. This means that if the key + management is declared for the whole session but is set up in non- + aggregated fashion (i.e., one media per RTSP session), each SETUP + MUST carry the same response for the session-level context. When + performing a setup of the second or any subsequent media in an RTSP + session, the same key management parameters as established for the + first media also apply to these setups. + + * Key management responses for the initial establishment of security + parameters for an individual media SHALL only be included in SETUP + for the corresponding media stream. + + If a server receives a SETUP message in which it expects a key + management message, but none is included, a "403 Forbidden" SHOULD be + returned to the client, whereby the current setup MUST be aborted. + + When the server creates an initial SDP message, the procedure SHALL + be the same as described in Section 4.1.1. + + + + + + +Arkko, et al. Standards Track [Page 15] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + The client processing of the initial SDP message from the server + SHALL follow the same procedures as described in Section 4.1.1, + except that, if there is an error, the session is aborted (no error + is sent back). + + The client SHALL create the response, using the key management header + in RTSP, as follows: + + * The identifier of the key management protocol used (e.g., MIKEY) + MUST be placed in the "prot" field of the header. The prot values + are maintained by IANA (Section 9). + + * The keymgmt-data field MUST be created as follows: the key + management protocol MUST be used to create the key management + message. This message SHALL be base64 encoded by the RTSP + application and then encapsulated in the "data" field of the + header. The semantics of the encapsulated message is dependent on + the key management protocol that is used. + + * Include, if necessary, the URL to indicate the context in the "uri" + parameter. + + The server SHALL process a received key management header in RTSP as + follows: + + * The key management protocol is identified according to the "prot" + field. + + * The key management data from the "data" field MUST be extracted, + base64 decoded to reconstruct the original message, and then passed + to the key management protocol for processing. + + * If the key management protocol is successful, the processing can + proceed according to normal rules. + + * Otherwise, if the key management fails (e.g., due to authentication + failure or parameter not supported), an error is sent back as the + SETUP response using RTSP error code 463 (see Section 3.2) and the + session is aborted. It is up to the key management protocol to + specify (within the RTSP status code message or through key + management messages) details about the type of error that occurred. + + Re-keying within RTSP is for further study, given that media updating + mechanisms within RTSP are unspecified at the time this document was + written. + + + + + + +Arkko, et al. Standards Track [Page 16] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + +5. Example Scenarios + + The following examples utilize MIKEY [MIKEY] as the key management + protocol to be integrated into SDP and RTSP. + +5.1. Example 1 (SIP/SDP) + + A SIP call is taking place between Alice and Bob. Alice sends an + INVITE message consisting of the following offer: + + v=0 + o=alice 2891092738 2891092738 IN IP4 w-land.example.com + s=Cool stuff + e=alice@w-land.example.com + t=0 0 + c=IN IP4 w-land.example.com + a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEEoo2pee4hp2 + UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaVkDaawi9whVBtBt + 0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUOSrzKTAv9zV + m=audio 49000 RTP/SAVP 98 + a=rtpmap:98 AMR/8000 + m=video 52230 RTP/SAVP 31 + a=rtpmap:31 H261/90000 + + That is, Alice proposes to set up one audio stream and one video + stream that run over SRTP (signaled by the use of the SAVP profile). + She uses MIKEY to set up the security parameters for SRTP (Section + 7). The MIKEY message contains the security parameters, together + with the necessary key material. Note that MIKEY is exchanging the + crypto suite for both streams, as it is placed at the session level. + Also, MIKEY provides its own security, i.e., when Bob processes + Alice's MIKEY message, he will also find the signaling of the + security parameters used to secure the MIKEY exchange. Alice's + endpoint's authentication information is also carried within the + MIKEY message, to prove that the message is authentic. The above + MIKEY message is an example of message when the pre-shared method + MIKEY is used. + + Upon receiving the offer, Bob checks the validity of the received + MIKEY message, and, in case of successful verification, he accepts + the offer and sends an answer back to Alice (with his authentication + information, and, if necessary, also some key material from his + side): + + v=0 + o=bob 2891092897 2891092897 IN IP4 foo.example.com + s=Cool stuff + e=bob@foo.example.com + + + +Arkko, et al. Standards Track [Page 17] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + t=0 0 + c=IN IP4 foo.example.com + a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAAAQbWlja2 + V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5cc= + m=audio 49030 RTP/SAVP 98 + a=rtpmap:98 AMR/8000 + m=video 52230 RTP/SAVP 31 + a=rtpmap:31 H261/90000 + + Upon receiving the answer, Alice verifies the correctness of it. In + case of success, at this point Alice and Bob share the security + parameters and the keys needed for a secure RTP communication. + +5.2. Example 2 (SDP) + + This example shows what Alice would have done if she wished to + protect only the audio stream. She would have placed the MIKEY line + at media level for the audio stream only (also specifying the use of + the SRTP profile there, SAVP). The semantics of the MIKEY messages + is as in the previous case, but applies only to the audio stream. + + v=0 + o=alice 2891092738 2891092738 IN IP4 w-land.example.com + s=Cool stuff + e=alice@w-land.example.com + t=0 0 + c=IN IP4 w-land.example.com + m=audio 49000 RTP/SAVP 98 + a=rtpmap:98 AMR/8000 + a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... + m=video 52230 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + Bob would then act as described in the previous example, including + the MIKEY answer at the media level for the audio stream (as Alice + did). + + Note that even if the key management attribute were specified at the + session level, the video part would not be affected by this (as a + security profile is not used, instead the RTP/AVP profile is + signaled). + +5.3. Example 3 (RTSP) + + A client wants to set up a streaming session and requests a media + description from the streaming server. + + DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 + + + +Arkko, et al. Standards Track [Page 18] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + CSeq: 312 + Accept: application/sdp + From: user@example.com + + The server sends back an OK message including an SDP description, + together with the MIKEY message. The MIKEY message contains the + necessary security parameters that the server is willing to offer to + the client, together with authentication information (to prove that + the message is authentic) and the key material. The SAVP profile + also signals the use of SRTP for securing the media sessions. + + RTSP/1.0 200 OK + CSeq: 312 + Date: 23 Jan 1997 15:35:06 GMT + Content-Type: application/sdp + Content-Length: 478 + + v=0 + o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com + s=Action Movie + e=action@movie.example.com + t=0 0 + c=IN IP4 movie.example.com + a=control:rtsp://movie.example.com/action + a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... + m=audio 0 RTP/SAVP 98 + a=rtpmap:98 AMR/8000 + a=control:rtsp://movie.example.com/action/audio + m=video 0 RTP/SAVP 31 + a=rtpmap:31 H261/90000 + a=control:rtsp://movie.example.com/action/video + + The client checks the validity of the received MIKEY message, and, in + case of successful verification, it accept the message. The client + then includes its key management data in the SETUP request going back + to the server, the client authentication information (to prove that + the message is authentic), and, if necessary, some key material. + + SETUP rtsp://movie.example.com/action/audio RTSP/1.0 + CSeq: 313 + Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 + keymgmt: prot=mikey; uri="rtsp://movie.example.com/action"; + data="AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g..." + + The server processes the request including checking the validity of + the key management header. + + + + + +Arkko, et al. Standards Track [Page 19] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + RTSP/1.0 200 OK + CSeq: 313 + Session: 12345678 + Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057; + server_port=5000-5001 + + Note that in this case the key management line was specified at the + session level, and the key management information only goes into the + SETUP related to the first stream. The "uri" indicates to the server + that the context is for the whole aggregated session the key + management applies. The RTSP client then proceeds setting up the + second media (video) in aggregation with the audio. As the two media + are run in aggregation and the key context was established in the + first exchange, no more key management messages are needed. + +5.4. Example 4 (RTSP) + + The use of the MIKEY message at the media level would change the + previous example as follows. + + The 200 OK would contain the two distinct SDP attributes for MIKEY at + the media level: + + RTSP/1.0 200 OK + CSeq: 312 + Date: 23 Jan 1997 15:35:06 GMT + Content-Type: application/sdp + Content-Length: 561 + + v=0 + o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com + s=Action Movie + e=action@movie.example.com + t=0 0 + c=IN IP4 movie.example.com + a=control:rtsp://movie.example.com/action + m=audio 0 RTP/SAVP 98 + a=rtpmap:98 AMR/8000 + a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAA... + a=control:rtsp://movie.example.com/action/audio + m=video 0 RTP/SAVP 31 + a=rtpmap:31 H261/90000 + a=key-mgmt:mikey AQAFgM0AdlABAAAAAAAAAAAAA... + a=control:rtsp://movie.example.com/action/video + + + + + + + +Arkko, et al. Standards Track [Page 20] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + Each RTSP header is inserted in the SETUP related to the audio and + video separately: + + SETUP rtsp://movie.example.com/action/audio RTSP/1.0 + CSeq: 313 + Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 + keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio"; + data="AQEFgM0XflABAAAAAAAAAAAAA..." + + and similarly for the video session: + + SETUP rtsp://movie.example.com/action/video RTSP/1.0 + CSeq: 315 + Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059 + keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video"; + data="AQEFgM0AdlABAAAAAAAAAAAAAA..." + + Note: The "uri" parameter could be excluded from the two SETUP + messages in this example. + +6. Adding Further Key Management Protocols + + This framework cannot be used with all key management protocols. The + key management protocol needs to comply with the requirements + described in Section 4. In addition to this, the following needs to + be defined: + + * The key management protocol identifier to be used as the protocol + identifier should be registered at IANA according to Section 9. + + * The information that the key management needs from SDP and RTSP, + and vice versa, as described in Section 4. The exact API is + implementation specific, but it MUST at least support the exchange + of the specified information. + + * The key management protocol to be added MUST be such that the + processing in Section 4 (describing its interactions with SDP and + RTSP) can be applied. Note in particular, Section 4.1.4 requires + each key management protocol to specify how the list of protocol + identifiers is authenticated inside that key management protocol. + The key management MUST always be given the protocol identifier(s) + of the key management protocol(s) included in the offer in the + correct order as they appear. + + Finally, it is obviously crucial to analyze possible security + implications induced by the introduction of a new key management + protocol in the described framework. + + + + +Arkko, et al. Standards Track [Page 21] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + Today, the MIKEY protocol [MIKEY] has adopted the key management + extensions to work together with SIP and RTSP (see Section 7). Other + protocols MAY use the described attribute and header, e.g., Kerberos + [KERB]; however, this is subject to future standardization. + +7. Integration of MIKEY + + [MIKEY] describes a key management protocol for real-time + applications (both for peer-to-peer communication and group + communication). MIKEY carries the security parameters needed for + 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 4. The MIKEY + message is formed as defined in [MIKEY], then passed from MIKEY to + the SDP application that base64 encodes it, and encapsulates it in + the keymgmt-data attribute. The examples in Section 5 use MIKEY, + where the semantics of the exchange is also briefly explained. + + The key management protocol identifier (KMPID) to be used as the + protocol identifier SHALL be "mikey" and is registered at IANA; see + Section 9 for details. + + The information that the key management needs from SDP and RTSP, and + vice versa, follows Section 4. To avoid bidding-down attacks, the + directives in Section 4.1.4 are followed. The list of protocol + identifiers is authenticated within MIKEY by placing the list in a + General Extension Payload (of type "SDP IDs", [MIKEY]), which then + automatically will be integrity protected/signed. The receiver SHALL + then match the list in the General Extension Payload with the list + included in SDP and SHOULD (according to policy) if they differ, or + if integrity/signature verification fails, reject the offer. + + The server will need to be able to know the identity of the client + before creating and sending a MIKEY message. To signal the (MIKEY) + identity of the client to the server in the DESCRIBE, it is + RECOMMENDED to include the From header field in RTSP. Other methods + to establish the identity could be using the IP address or retrieving + the identity from the RTSP authentication if used. + +7.1. MIKEY Interface + + This subsection describes some aspects, which implementers SHOULD + consider. If the MIKEY implementation is separate from the + SDP/SIP/RTSP, an application programming interface (API) between + MIKEY and those protocols is needed with certain functionality + (however, exactly what it looks like is implementation dependent). + + + +Arkko, et al. Standards Track [Page 22] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + The following aspects need to be considered: + + * the possibility for MIKEY to receive information about the sessions + negotiated. This is to some extent implementation dependent. But + 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 + RECOMMENDED to provide the destination addresses and ports to + MIKEY. When referring to streams described in SDP, MIKEY SHALL + allocate two consecutive numbers for the related Crypto Session + indexes (as each stream can be bi-directional). An example: if the + SDP contains two m lines (specifying whatever direction of the + streams), and MIKEY is at the session level, then MIKEY allocates, + 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. + + * the possibility for MIKEY to receive incoming MIKEY messages and + return a status code from/to the SIP/RTSP application. + + * the possibility for the SIP or RTSP applications to receive + information from MIKEY. This would typically include the receiving + of the Crypto Session Bundle Identifier (CSB ID; see [MIKEY], to + later be able to identify the active MIKEY session), and the SSRCs + and the rollover counter (ROC; see [SRTP]) for SRTP usage. It is + also RECOMMENDED that extra information about errors can be + received. + + * the possibility for the SIP or RTSP application to receive outgoing + MIKEY messages. + + * the possibility to tear down a MIKEY CSB (e.g., if the SIP session + is closed, the CSB SHOULD also be closed). + +8. Security Considerations + + The framework for transfer of key management data as described here + is intended to provide the security parameters for the end-to-end + protection of the media session. It is furthermore good practice to + secure the session setup (e.g., SDP, SIP, RTSP, SAP). However, it + might be that the security of the session setup is not possible to + achieve end-to-end, but only hop-by-hop. For example, SIP requires + intermediate proxies to have access to part of the SIP message, and + sometimes also to the SDP description (cf. [E2M]), although end-to- + end confidentiality can hide bodies from intermediaries. General + security considerations for the session setup can be found in SDP + [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- + + + + + +Arkko, et al. Standards Track [Page 23] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + end fashion, but the media streams need to be end-to-end protected; + hence the security parameters (such as keys) are not wanted revealed + to or manipulated by intermediaries. + + The security will also depend on the level of security the key + management protocol offers. It follows that, under the assumption + that the key management schemes are secure, the SDP can be passed + along unencrypted without affecting the key management as such, and + the media streams will still be secure even if some attackers gained + knowledge of the SDP contents. Further security considerations can + be found for each key management protocol (for MIKEY these can be + found in [MIKEY]). However, if the SDP messages are not sent + integrity protected between the parties, it is possible for an active + attacker to change attributes without being detected. As the key + management protocol may (indirectly) rely on some of the session + information from SDP (e.g., address information), an attack on SDP + may have indirect consequences on the key management. Even if the + key management protocol does not rely on parameters of SDP and will + not be affected by manipulation of these, different denial-of-service + (DoS) attacks aimed at SDP may lead to undesired interruption in the + setup. See also the 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. For + instance, it is 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. However, this + might need to keep into consideration privacy aspects, which are out + of scope for this framework. + + The use of multiple key management protocols in the same offer may + open up the possibility of a bidding-down attack, as specified in + Section 4.1.4. To exclude such possibility, the authentication of + the protocol identifier list is used. Note though, that the security + level of the authenticated protocol identifier will be as high (or + + + + +Arkko, et al. Standards Track [Page 24] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + low), as the "weakest" protocol. Therefore, the offer MUST NOT + contain any security protocols (or configurations thereof) weaker + than permitted by local security policy. + + Note that it is impossible to ensure the authenticity of a declined + offer, since even if it comes from the true respondent, the fact that + the answerer declines the offer usually means that he does not + support the protocol(s) offered, and consequently cannot be expected + to authenticate the response either. This means that if the + Initiator is unsure of which protocol(s) the Responder supports, we + RECOMMEND that the Initiator offers all acceptable protocols in a + single offer. If not, this opens up the possibility for a "man-in- + the-middle" (MITM) to affect the outcome of the eventually agreed + upon protocol, by faking unauthenticated error messages until the + Initiator eventually offers a protocol "to the liking" of the MITM. + This is not really a security problem, but rather a mild form of + denial of service that can be avoided by following the above + recommendation. Note also that the declined offer could be the + result of an attacker who sits on the path and removes all the key + management offers. The bidding-down attack prevention, as described + above, would not work in this case (as the answerer receives no key + management attribute). Also, here it is impossible to ensure the + authenticity of a declined offer, though here the reason is the + "peeling-off" attack. It is up to the local policy to decide the + behavior in the case that the response declines any security + (therefore, there is impossibility of authenticating it). For + example, if the local policy requires a secure communication and + cannot accept an unsecured one, then the session setup SHALL be + aborted. + +9. IANA Considerations + +9.1. SDP Attribute Registration + + The IANA has created a new subregistry for the purpose of key + management protocol integration with SDP. + + SDP Attribute Field ("att-field"): + + Name: key-mgmt-att-field + Long form: key management protocol attribute field + Type of name: att-field + Type of attribute: Media and session level + Purpose: See RFC 4567, Section 3. + Reference: RFC 4567, Section 3.1 + Values: See RFC 4567, Sections 3.1 and 9.3. + + + + + +Arkko, et al. Standards Track [Page 25] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + +9.2. RTSP Registration + + The IANA has created a new subregistry for the purpose of key + management protocol integration with RTSP. + + Following the guidelines of [RTSP], the registration is defined as + follows: + + Header name: keymgmt + Header syntax: see RFC 4567, Section 3.2 + Intended usage: see RFC 4567, Section 3.2 + Proxy treatment: Proxies SHALL NOT add, change, or delete the + header. The proxy does not need to read this + header. + Purpose: see RFC 4567, Section 3 + + The RTSP Status-Code "463" (RFC 4567), with the default string "Key + management failure", needs to be registered. + +9.3. Protocol Identifier Registration + + This document defines one new name space, the "SDP/RTSP key + management protocol identifier", associated with the protocol + identifier, KMPID, defined in Section 3 to be used with the above + registered attributes in SDP and RTSP. + + The IANA has created a new subregistry for the KMPID parameter, with + the following registration created initially: "mikey". + + Value name: mikey + Long name: Multimedia Internet KEYing + Purpose: Usage of MIKEY with the key-mgmt-att-field + attribute and the keymgmt RTSP header + Reference: Section 7 in RFC 3830 + + Note that this registration implies that the protocol identifier, + KMPID, name space will be shared between SDP and RTSP. + + Further values may be registered according to the "Specification + Required" policy as defined in [RFC2434]. Each new registration + needs to indicate the parameter name, and register it with IANA. + Note that the parameter name is case sensitive, and it is RECOMMENDED + that the name be in lowercase 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 and the requested details of interaction between the key + management protocol and SDP, as specified in RFC 4567. + + + + +Arkko, et al. Standards Track [Page 26] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + New values MUST be registered with IANA. Registrations SHALL include + the following information: + + * Contact: the contact name and email address + * Value name: the name of the value being registered (which MUST + comply with the KMPID as defined in Section 3) + * Long Name: long-form name in English + * Purpose: short explanation of the purpose of the registered name. + * Reference: a reference to the specification (e.g., RFC number) + providing the usage guidelines in accordance to Section 6 (and also + complying to the specified requirements). + +10. Acknowledgements + + The authors would like to thank Francois Audet, Rolf Blom, Johan + Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries, + Joerg Ott, Jon Peterson, and Jon-Olov Vatn. A special thanks to + Colin Perkins and Magnus Westerlund, who contributed in many + sections. + +11. References + +11.1. Normative References + + [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. + Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, + August 2004. + + [OAM] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, June + 2002. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 3548, July 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + + [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + + +Arkko, et al. Standards Track [Page 27] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + + [RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time + Streaming Protocol (RTSP)", RFC 2326, April 1998. + + [SDPnew] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + +11.2. Informative References + + [E2M] Ono, K. and S. Tachimoto, "Requirements for End-to-Middle + Security for the Session Initiation Protocol (SIP)", RFC + 4189, October 2005. + + [KERB] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + + [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail + Extensions (S/MIME) Version 3.1 Message Specification", + RFC 3851, July 2004. + + [SDES] Andreasen, F., Baugher, M., and D. Wing, "Session + Description Protocol (SDP) Security Descriptions for Media + Streams", RFC 4568, July 2006. + + [SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security + Preconditions for Session Description Protocol Media + Streams", Work in Progress, October 2005. + + [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, March 2004. + + + + + + + + + + + + + + + +Arkko, et al. Standards Track [Page 28] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + +Authors' Addresses + + Jari Arkko + Ericsson + 02420 Jorvas + Finland + + Phone: +358 40 5079256 + EMail: jari.arkko@ericsson.com + + + Elisabetta Carrara + Royal Institute of Technology + Stockholm + Sweden + + EMail: carrara@kth.se + + + Fredrik Lindholm + Ericsson + SE-16480 Stockholm + Sweden + + Phone: +46 8 58531705 + EMail: fredrik.lindholm@ericsson.com + + + Mats Naslund + Ericsson Research + SE-16480 Stockholm + Sweden + + Phone: +46 8 58533739 + EMail: mats.naslund@ericsson.com + + + Karl Norrman + Ericsson Research + SE-16480 Stockholm + Sweden + + Phone: +46 8 4044502 + EMail: karl.norrman@ericsson.com + + + + + + + +Arkko, et al. Standards Track [Page 29] + +RFC 4567 Key Management Extensions for SDP and RTSP July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Arkko, et al. Standards Track [Page 30] + |