Internet Engineering Task Force J. Arkko MMUSIC Working Group E. Carrara INTERNET-DRAFT F. Lindholm Expires: May 2002 M. Naslund K. Norrman Ericsson November, 2001 Key Management Extensions for SDP and RTSP Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Work for securing real-time applications have started. It has also brought toward the need for a key management infrastructure to support the security protocol. This document defines extensions for SDP and RTSP to carry the security information needed by a key management protocol, in order to secure the media stream itself. Arkko, et al. [Page 1] INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001 TABLE OF CONTENTS 1. Introduction..................................................2 1.1. Notational Conventions......................................3 2. SDP Attribute Fields for Key Management.......................3 2.1. SDP Grammar.................................................4 2.2. SDP in SIP and RTSP.........................................5 3. RTSP Header and Grammar.......................................5 4. Security Considerations.......................................6 5. IANA Considerations...........................................6 6. Conclusions...................................................7 7. Acknowledgments...............................................7 8. Author's Addresses............................................7 9. References....................................................7 1. Introduction There has recently been work to define a security framework for the protection of real-time applications running over RTP, [SRTP]. However, a security protocol needs a key management infrastructure to exchange keys and security parameters, managing and refreshing keys, etc. The Session Description Protocol [SDP] is used to convey advertisements of conference sessions and communicate the relevant conference setup information to prospective participants. SDP is intended to use different transport protocols as appropriate, e.g. the Session Initiation Protocol [SIP] and the Real-Time Streaming Protocol [RTSP]. An efficient way of performing key management is to integrate it into SDP. This approach may reduce the number of roundtrips compared to a standalone key management scheme (and in some cases it could also reduce the total bandwidth consumption). However, to make it possible to integrate the key management protocol (e.g. [MIKEY]) into SDP, a set of attributes in SDP is needed. Such a set of attributes is defined in this document to support integrated media stream key management. Currently in SDP, one field exists to transport keys, i.e. the "key=" field. However, this is not enough for a key management protocol. There MUST exist the possibility to include not only the key, but also the key encrypted, encryption parameters, security protocol parameters, and at the same time have it all authenticated. This can not be done with the "key=" field as specified today. In RTSP, the SDP description is mainly used in the response to the DESCRIBE method. This makes it hard to send key management messages back from the client to the server. Therefore, this draft also Arkko, et al. [Page 2] INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001 defines an RTSP header that may be used to carry additional key management messages. 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 RFC-2119. 2. SDP Attributes for Key Management This subsection describes common attributes that are to be included in the SDP description when an integrated key management protocol is used. All attribute values MUST follow the general SDP guidelines. The attributes are designed to give a minimal impact on SDP, i.e. only a minimal set of "knowledge" MUST be built into an existing SDP stack in order to support the key management. Three SDP attributes are defined. To be able to detect the key management protocol applied, this MUST be signaled by: a=keymgmt-prot: The key management protocol data MUST be provided in the following field: a=keymgmt-data: Note that the data MUST be encoded in a way so that it complies with the normal SDP rules. In case the key management mechanism does not provide authentication of the key management part, additional authentication data MAY be provided in the "keymgmt-auth" field. a=keymgmt-auth: The key management attributes may be defined both at the session level (i.e. before the media descriptor lines) and at the media level of the SDP description. If the key management attributes are defined at media level, it will only apply to that specific media. If the key management attributes are defined at both session and media level, the media level definition overrides the session level definition for that specific media. Arkko, et al. [Page 3] INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001 Example 1 (session level) a=keymgmt-prot:MIKEY a=keymgmt-data:uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... m=audio 49000 RTP/SAVP 98 a=rtpmap:98 AMR/8000 m=video 2232 RTP/SAVP 31 In this example, MIKEY is negotiating the crypto suite for both streams at session level. It is recommended to use this approach if possible to save both bandwidth and computational resources. Example 2 (media level) m=audio 49000 RTP/SAVP 98 a=keymgmt-prot:MIKEY a=keymgmt-data:uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... a=rtpmap:98 AMR/8000 m=video 2232 RTP/AVP 31 Note that the video part in this example is not protected by any security protocol. 2.1. SDP Grammar This section provides an Augmented Backus-Naur Form (ABNF) grammar (as used in [SDP]) 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 Three new attributes are defined, keymgmt-prtcl, keymgmt-data, and key-extra-auth. keymgmt-prtcl = "keymgmt-prot:" prtcl-name prtcl-name = 1*(alpha-numeric|SAFE) ; e.g. "MIKEY" keymgmt-data = "keymgmt-data:" byte-string key-extra-auth = "keymgmt-auth:" byte-string byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff) ;any byte except NUL, CR or LF Arkko, et al. [Page 4] INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001 alpha-numeric = ALPHA | DIGIT DIGIT = "0" | POS-DIGIT POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"| "l"|"m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"| "w"|"x"|"y"|"z"|"A"|"B"|"C"|"D"|"E"|"F"|"G"| "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|"Q"|"R"| "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z" SAFE = "\$" | "-" | "_" | "." | "+" 2.2. SDP in SIP and RTSP Both SIP and RTSP provide means to transport SDP descriptions. This section gives a recommendation of how/when to include key management initiated SDP descriptions in SIP and RTSP. For SIP, the recommendation is to use the Invite message (and the following response) to transport the SDP description with the key management parameters. For RTSP, the recommendation is to let the server include a SDP description with the key management parameters in the response to a DESCRIBE message. A problem with RTSP is that no SDP description can be assumed to be sent back to the server. Therefore, other means to send key management messages between client and server is needed. This may be solved by using the new RTSP header defined in Section 3. In general, any key management protocol using SDP as a mean of transport, MUST not require a great number of exchange messages. It is RECOMMENDED that the key management protocol does not use more than one roundtrip. This is to create as small (if any) impact as possible on the underlying transporting mechanism (e.g., SIP and RTSP). 3. RTSP Header and Grammar To support the three different parameters described in Section 2, a new RTSP header is defined. KeyMgmt = "KeyMgmt" ":" [stream-url] protocol data [auth] stream-url = "url" "=" url ";" protocol = "Prot" "=" prtcl-name Arkko, et al. [Page 5] INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001 data = ";" "Data" "=" string auth = ";" "Auth" "=" string string = 1*(alpha-numeric|SAFE|"=") alpha-numeric, SAFE and prtcl-name are as defined in Section 2.1. The url indicates the stream URL for which the parameters correspond to. It is recommended that the string is a base64 encoded value. The new key management header should be possible to use in both request and response messages of the following methods: * ANNOUNCE * SETUP * PLAY * RECORD * SET_PARAMETER * GET_PARAMETER * OPTIONS When a key management protocol is enabled in the RTSP implementation, it MUST for each message to be sent (that may contain the KeyMgmt header), check with the key management protocol if any parameters(s) should be include in the header (i.e. the Data or Auth parameter). For each message received (that contains the KeyMgmt header), the key management parameters (Data and Auth) are passed to the key management protocol for processing. 4. Security Considerations The nature of this document is to allow SDP and RTSP support for security of the media sessions. It is therefore not the intention of this document to describe possible security solution nor define possible security problems. The defined SDP and RTSP extensions are not believed to introduce any new security risks to SDP and RTSP. Note that the purpose of the key management fields is to secure the media streams themselves. Provided that the key management schemes are secure, the SDP payloads can be passed along unprotected, and the media streams will still be secure even if some attackers gained knowledge of the SDP contents. There may, however, be other reasons to protect the SDP payloads such as preventing attackers from gaining any information regarding the session or the used equipment. 5. IANA Considerations Three new attributes fields for SDP (see Section 2) and one new RTSP header are registered (see Section 3). Arkko, et al. [Page 6] INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001 6. Conclusions A security solution for real-time applications needs a key management infrastructure. Integrating the key management scheme with the session establishment protocol could be done efficiently in most of the scenarios. This document defines extensions to SDP and RTSP so that it will be possible to integrate a key management protocol (e.g. MIKEY) into protocol such as SIP and RTSP. 7. Acknowledgments Thanks to: Joerg Ott, Colin Perkins, Magnus Westerlund, and the rest involved in the MMUSIC WG and the MSEC WG. 8. Author's Addresses Jari Arkko Ericsson 02420 Jorvas Phone: +358 40 5079256 Finland Email: jari.arkko@ericsson.com Elisabetta Carrara Ericsson Research SE-16480 Stockholm Phone: +46 8 50877040 Sweden EMail: elisabetta.carrara@era.ericsson.se Fredrik Lindholm Ericsson Research SE-16480 Stockholm Phone: +46 8 58531705 Sweden EMail: fredrik.lindholm@era.ericsson.se Mats Naslund Ericsson Research SE-16480 Stockholm Phone: +46 8 58533739 Sweden EMail: mats.naslund@era.ericsson.se Karl Norrman Ericsson Research SE-16480 Stockholm Phone: +46 8 4044502 Sweden EMail: karl.norrman@era.ericsson.se 9. References [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and Norrman, K., "MIKEY: Multimedia Internet KEYing", Internet Draft, IETF, Work in progress (MSEC). Arkko, et al. [Page 7] INTERNET-DRAFT mmusic-kmgmt-ext-00 November 2001 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [SDP] Handley, M., and Jacobson, V., "Session Description Protocol (SDP)", IETF, RFC2327 [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., "SIP: Session Initiation Protocol", IETF, RFC2543. [SRTP] Blom, R., Carrara, E., McGrew, D., Naslund, M, Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", Internet Draft, IETF, Work in Progress (AVT). This Internet-Draft expires in May 2002. Arkko, et al. [Page 8]