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
                  <draft-ietf-mmusic-kmgmt-ext-00.txt>


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


. 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.


. 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:<protocol>

   The key management protocol data MUST be provided in the following
   field:

   a=keymgmt-data:<key-transport-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:<key-auth-data>


   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).


. 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.


. 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.


. 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



. 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.


. Acknowledgments

   Thanks to: Joerg Ott, Colin Perkins, Magnus Westerlund, and the rest
   involved in the MMUSIC WG and the MSEC WG.


. 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

. 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]