[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-msec-mikey-applicability

MSEC                                                            S. Fries
Internet-Draft                                                   Siemens
Expires: August 30, 2006                                     D. Ignjatic
                                                                 Polycom
                                                       February 26, 2006


       On the applicability of various MIKEY modes and extensions
              draft-fries-msec-mikey-applicability-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 30, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Multimedia Internet Keying - MIKEY - is a key management scheme that
   can be used for real-time applications.  In particular, it has been
   defined focusing on the support of the Secure Real-time Transport
   Protocol.  MIKEY itself defines four key distribution schemes.
   Moreover, it is defined to allow extensions of the protocol.  As
   MIKEY becomes more and more accepted, extensions to the base protocol
   arose, especially in terms of additional key distribution schemes,



Fries & Ignjatic         Expires August 30, 2006                [Page 1]

Internet-Draft          MIKEY modes applicability          February 2006


   but also in terms of payload enhancements.

   This document provides an overview about MIKEY in general as well as
   the existing extensions in MIKEY, which have been defined or are in
   the process of definition.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Definitions  . . . . . . . . . . . . . . . . .  4
   3.  MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Symmetric key distribution . . . . . . . . . . . . . . . .  6
     3.2.  Asymmetric key distribution  . . . . . . . . . . . . . . .  6
     3.3.  Diffie-Hellman key agreement protected with digital
           signatures . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Unprotected key distribution . . . . . . . . . . . . . . .  7
   4.  MIKEY Extensions . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Diffie-Hellman key agreement protected with pre-shared
           secrets  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  SAML assisted DH-key agreement . . . . . . . . . . . . . .  9
     4.3.  Asymmetric key distribution with in-band certificate
           exchange . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  ECC algorithms support . . . . . . . . . . . . . . . . . . 11
       4.4.1.  Elliptic Curve Integrated Encryption Scheme
               application in MIKEY . . . . . . . . . . . . . . . . . 12
       4.4.2.  Elliptic Curve Menezes-Qu-Vanstone Scheme
               application in MIKEY . . . . . . . . . . . . . . . . . 12
     4.5.  New Payload for bootstrapping TESLA  . . . . . . . . . . . 12
     4.6.  New Key ID information type  . . . . . . . . . . . . . . . 13
   5.  Selection and interworking of MIKEY modes  . . . . . . . . . . 13
   6.  Transport of MIKEY messages  . . . . . . . . . . . . . . . . . 14
   7.  Summary of MIKEY related IANA Registrations  . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20










Fries & Ignjatic         Expires August 30, 2006                [Page 2]

Internet-Draft          MIKEY modes applicability          February 2006


1.  Introduction

   Key distribution describes the process of delivering cryptographic
   keys to the required parties.  MIKEY [RFC3830], the Multimedia
   Internet Keying, has been defined focusing on support for the
   establishment of security context for the Secure Real-time Transport
   Protocol [RFC3711].  Note that MIKEY is not restricted to be used for
   SRTP only, as it features a generic approach and allows for
   extensions to the key distribution schemes, but also for the payload
   associated with the protocol using the distributed security context.

   MIKEY defines four key distribution schemes as there are:

   o  Symmetric key distribution
   o  Asymmetric key distribution
   o  Diffie-Hellman key agreement protected by digital signatures
   o  Unprotected key distribution

   There have been scenarios where none of the above schemes fits
   perfectly, so extensions have been defined.  These extensions
   comprise new key distribution schemes, algorithm enhancements, new
   payload definitions supporting other protocols than SRTP.  The key
   distribution scheme extensions are defined in the following
   documents:

   o  Diffie-Hellman key agreement protected by symmetric pre-shared
      keys as defined in [I-D.ietf-msec-mikey-dhhmac]
   o  SAML assisted Diffie-Hellman key agreement as defined [Reference
      to draft-moskowitz-MIKEY-SAML-DH]
   o  Asymmetric key distribution (based on asymmetric encryption) with
      in-band certificate provision as defined in [I-D.ietf-msec-mikey-
      rsa-r]

   Algorithm extensions are defined in the following document:

   o  ECC algorithms for MIKEY as defined in [I-D.ietf-msec-mikey-ecc]

   Payload extensions are defined in the following documents:

   o  Bootstrapping TESLA, defining a new payload for the Timed
      Efficient Stream Loss-tolerant Authentication protocol [RFC4082]
      as defined in [I-D.ietf-msec-bootstrapping-tesla]
   o  The Key ID information type for the general extension payload as
      defined in [I-D.ietf-msec-newtype-keyid]

   This document provides an overview about MIKEY and the relations to
   the different extensions to provide a framework when using MIKEY.  It
   is intended as additional source of information for developers or



Fries & Ignjatic         Expires August 30, 2006                [Page 3]

Internet-Draft          MIKEY modes applicability          February 2006


   architects to provide more insight in use case scenarios and
   motivations as well as advantages and disadvantages for the different
   key distribution schemes.  This document may be enhanced as soon as
   new extensions to MIKEY appear.  It has been seen that enhancing the
   overview document requires much less effort than enhancing an
   established standard.


2.  Terminology and Definitions

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

   The following definitions have mostly been taken from [RFC3830]:

   (Data) Security Protocol: the security protocol used to protect the
   actual data traffic.  Examples of security protocols are IPsec and
   SRTP.

   Data Security Association (Data SA): information for the security
   protocol, including a TEK and a set of parameters/policies.

   Crypto Session (CS): uni- or bi-directional data stream(s), protected
   by a single instance of a security protocol.

   Crypto Session Bundle (CSB): collection of one or more Crypto
   Sessions, which can have common TGKs (see below) and security
   parameters.

   Crypto Session ID: unique identifier for the CS within a CSB.

   Crypto Session Bundle ID (CSB ID): unique identifier for the CSB.

   TEK Generation Key (TGK): a bit-string agreed upon by two or more
   parties, associated with CSB.  From the TGK, Traffic-encrypting Keys
   can then be generated without needing further communication.

   Traffic-Encrypting Key (TEK): the key used by the security protocol
   to protect the CS (this key may be used directly by the security
   protocol or may be used to derive further keys depending on the
   security protocol).  The TEKs are derived from the CSB's TGK.

   TGK re-keying: the process of re-negotiating/updating the TGK (and
   consequently future TEK(s)).

   Initiator: the initiator of the key management protocol, not
   necessarily the initiator of the communication.



Fries & Ignjatic         Expires August 30, 2006                [Page 4]

Internet-Draft          MIKEY modes applicability          February 2006


   Responder: the responder in the key management protocol.

   Salting key: a random or pseudo-random (see [RAND, HAC]) string used
   to protect against some off-line pre-computation attacks on the
   underlying security protocol.

   HDR: denotes the protocol header

   PRF(k,x): a keyed pseudo-random function

   E(k,m): encryption of m with the key k

   RAND: Random value

   T: Timestamp

   CERTx: the certificate of x

   SIGNx: the signature from x using the private key of x

   PKx: the public key of x

   IDx: the identity of x

   [] an optional piece of information

   {} denotes zero or more occurrences

   || concatenation

   | OR (selection operator)

   ^ exponentiation

   XOR exclusive or


3.  MIKEY Overview

   This section will provide an overview about the MIKEY base document.
   The focus lies here on the key distribution schemes as well as the
   discussion about advantages and disadvantages of the different
   schemes.  Note that the MIKEY key distribution schemes rely on
   loosely synchronized clocks.  Thus should be realized by a secure
   network clock synchronization protocol.  MIKEY recommends for this
   the ISO time synchronization protocol [ISO_sec_time].  The format
   applied to the timestamps submitted in the MIKEY have to match the
   NTP format described in [RFC1305].  In other cases, such as of a SIP



Fries & Ignjatic         Expires August 30, 2006                [Page 5]

Internet-Draft          MIKEY modes applicability          February 2006


   endpoint clock synchronization by deriving time from a trusted
   outbound proxy may be appropriate.

3.1.  Symmetric key distribution

   This option of the key management uses a pre-shared secret key to
   derive key material for integrity protection and encryption to
   protect the actual exchange of key material.  The response message is
   optional and may be used for mutual authentication.


   Initiator                                  Responder

   I_MESSAGE =
   HDR, T, RAND, [IDi],[IDr],
       {SP}, KEMAC                --->
                                              R_MESSAGE =
                                 [<---]       HDR, T, [IDr], V

   The advantages of this approach lay in the fact that there is no
   dependency on a PKI (Public Key Infrastructure), the solution
   consumes low bandwidth and enables high performance, and is all in
   all a simple straightforward master key provisioning.  The
   disadvantages are that no perfect forward secrecy is provided and key
   generation is just performed by the initiator.  Furthermore, the
   approach is not scaleable to larger configurations but acceptable in
   small-sized groups.  Note, according to [RFC3830] this option is
   mandatory to implement.

3.2.  Asymmetric key distribution

   Using the asymmetric option of the key management, the initiator
   generates the key material to be transmitted and sends it encrypted
   with the responder's public key.  Additionally a so-called envelope
   key is transmitted, encrypted with the receiver's public key.  The
   envelope key env-key is used to derive the auth-key and the enc-key.
   Moreover, the envelope key may be used as a pre-shared key to
   establish further crypto sessions.  The response message is optional
   and may be used for mutual authentication.


   Initiator                                    Responder

   I_MESSAGE =
   HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
     KEMAC, [CHASH], PKE, SIGNi         --->
                                                R_MESSAGE =
                                       [<---]   HDR, T, [IDr], V



Fries & Ignjatic         Expires August 30, 2006                [Page 6]

Internet-Draft          MIKEY modes applicability          February 2006


   An advantage of this approach are that the usage of self-signed
   certificates can avoid PKI.  Note that using self-signed certificates
   may result in limited scalability and complex provisioning.  The
   disadvantages comprise the necessity of a PKI for fully scalability,
   the performance of the key generation just by the initiator, and no
   provision of perfect forward secrecy.  Furthermore, the verification
   of certificates may not be done in real-time.  This could be the case
   in scenarios where the revocation status of certificates is checked
   through a further component.  Note, according to [RFC3830] this
   option is mandatory to implement.

3.3.  Diffie-Hellman key agreement protected with digital signatures

   The Diffie-Hellman option of the key management enables a shared
   secret establishment between initiator and responder in a way where
   both parties contribute to the shared secret.  The Diffie-Hellman key
   agreement is authenticated (and integrity protected) using digital
   signatures.


   Initiator                                 Responder

   I_MESSAGE =
   HDR, T, RAND, [IDi|CERTi],[IDr]
        {SP}, DHi, SIGNi           --->
                                             R_MESSAGE =
                                   <---      HDR, T, [IDr|CERTr],
                                               IDi, DHr, DHi, SIGNr

   [RFC3830] does not mandate any specific asymmetric algorithm for the
   signature calculation.  The algorithm used for signature or public
   key encryption is rather defined by, and dependent on the certificate
   used.  Besides the use of X.509v3 certificates it is mandatory to
   support the Diffie-Hellmann group "OAKLEY5" [RFC2412].  The
   advantages of this approach are a fair, mutual key agreement, perfect
   forward secrecy, and the option to use self-signed certificates to
   avoid PKI (would result in limited scalability and more complex
   provisioning).  Negatively to remark is that this approach just
   scales to point-to-point groups and depends on PKI for full
   scalability.  Moreover, it has a limited performance since expensive,
   non-real time certificate validation has to be done.

3.4.  Unprotected key distribution

   MIKEY also supports a mode to provide a key in an unprotected manner.
   This is based on the pre-shared key option depicted in Section 3.1
   and may be compared with the plain approach in sdescriptions
   [I-D.ietf-mmusic-sdescriptions].  Here, MIKEY completely relies on



Fries & Ignjatic         Expires August 30, 2006                [Page 7]

Internet-Draft          MIKEY modes applicability          February 2006


   the underlying security and may be used with the NULL encryption and
   the NULL authentication algorithm.  This option should be used with
   caution as it does not protect the key management.


4.  MIKEY Extensions

   This section will provide an overview about the MIKEY extensions for
   key distribution schemes, crypto algorithms and payloads which have
   been defined in several documents.

4.1.  Diffie-Hellman key agreement protected with pre-shared secrets

   This is an additional option which has been defined in [I-D.ietf-
   msec-mikey-dhhmac].  In contrast to the method described in
   Section 3.3 here the Diffie-Hellmann key agreement is authenticated
   (and integrity protected) using a pre-shared secret and keyed hash
   function.


   Initiator                                  Responder

   I_MESSAGE =
   3D HDR, T, RAND, [IDi], IDr,
          {SP}, DHi, KEMAC         --->
                                              R_MESSAGE =
                                    <---      3D HDR, T,[IDr], IDi,
                                                 DHr, DHi, KEMAC

   TGK =3D g^(xi * yi)                        TGK =3D g^(xi * yi)

   For the integrity protection of the Diffie-Hellman key agreement
   [I-D.ietf-msec-mikey-dhhmac] mandates the use of HMAC SHA-1.
   Regarding Diffie-Hellman groups [RFC3830] is referenced.  Thus, it is
   mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412].
   This option has also several advantages, as there are the fair mutual
   key agreement, the perfect forward secrecy, and no dependency on a
   PKI and PKI standards.  Moreover, this scheme has a sound performance
   and reduced bandwidth requirements and provides a simple and
   straightforward master key provisioning.  The scalability of this
   approach just to point-to-point groups is a disadvantage.

   This mode of operation provides an efficient scheme in deployments
   where there is a central trusted server that is provisioned with
   shared secrets for many clients.  Such setups could for example be
   enterprise PBXs, service provider proxies, etc.





Fries & Ignjatic         Expires August 30, 2006                [Page 8]

Internet-Draft          MIKEY modes applicability          February 2006


4.2.  SAML assisted DH-key agreement

   This document [Reference to draft-moskowitz-MIKEY-SAML-DH] is
   targeted to fulfill the general requirements on key management
   approaches repeated here:

   1.  Mutual authentication of involved parties
   2.  Both parties involved contribute to the session key generation
   3.  Provide perfect forward secrecy
   4.  Support distribution of group session keys
   5.  Provide liveliness tests when involved parties do not have a
       reliable clock
   6.  Support of limited parties involved

   To fullfill all of the requirements, the document proposes the use of
   a classic Diffie-Hellman key agreement protocol for key establishment
   in conjunction with UA's SIP server signed element authenticating the
   Diffie-Hellman key and the ID using the SAML (Security Association
   Markup Language, [SAML_overview]) approach.  Here the client's public
   Diffie-Hellman-credentials are signed by the server to form a SAML
   assertion [CRED], which may be used for later sessions with other
   clients.  This assertion needs at least to convey the ID, public DH
   key, Expiry, and the signature from the server.  This provides the
   involved clients with mutual authentication and message integrity of
   the key management messages exchanged.


   Initiator                             Responder

   I_MESSAGE =
   HDR, T, RAND1, [CREDi],
   IDr, {SP}                    --->
                                         R_MESSAGE =
                                <---     HDR, T, [CREDr], IDi, DHr,
                                         RAND2, (SP)
          TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr).

   Additionally the document proposes a second roundtrip to avoid the
   dependence on synchronized clocks and provide liveliness checks.
   This is achieved by exchanging nonces, protected with the session
   key.  This second roundtrip can also be used for distribution of
   group keys or for the leverage of a weak DH key for a stronger
   session key.  The trigger for the second round trip would be handled
   via SP, the Security Policy communicated via MIKEY.







Fries & Ignjatic         Expires August 30, 2006                [Page 9]

Internet-Draft          MIKEY modes applicability          February 2006


   Initiator                             Responder

   I_MESSAGE =
   HDR, SIGN(ENC(RAND3))        --->
                                         R_MESSAGE =
                                <---     SIGN(ENC(RAND4))

   Note if group keys are to be provided RAND would be substituted by
   that group key.

   With the second roundtrip, this approach also provides an option for
   all of the other key distribution methods, when liveliness checks are
   needed.  The drawback of the second roundtrip is that these messages
   need to be integrated into the call flow of the signaling protocol.
   In straight forward call one roundtrip may be enough to setup a
   session.  Thus this second roundtrip would require additional
   messages to be exchanged.

4.3.  Asymmetric key distribution with in-band certificate exchange

   This is an additional option which has been defined in [I-D.ietf-
   msec-mikey-rsa-r].  It describes the asymmetric key distribution with
   optional in-band certificate exchange.


   Initiator                             Responder

   I_MESSAGE =
   HDR, T, [IDi|CERTi], [IDr],
         {SP}, SIGNi            --->
                                         R_MESSAGE =
                                <---     HDR, [GenExt(CSB-ID)], T,
                                           RAND, [IDr|CERTr], [SP],
                                           KEMAC, PKE, SIGNr

   This option has some advantages compared to the asymmetric key
   distribution stated in Section 3.2.  Here, the sender and receiver do
   not need to know the certificate of the other peer in advance as it
   may be sent in the MIKEY initiator message.  Thus, the receiver of
   this message can utilize the received key material to encrypt the
   session parameter and send them back as part of the MIKEY response
   message.  The certificate check may be done depending on the signing
   authority.  If the certificate is signed by an publicly accepted
   authority the certificate validation is done on the common base.  In
   the other case additional steps may be necessary.  The disadvantage
   is that no perfect forward secrecy is provided.

   This mode is meant to provide a low cost solution when PKI is present



Fries & Ignjatic         Expires August 30, 2006               [Page 10]

Internet-Draft          MIKEY modes applicability          February 2006


   and/or required.  Specifically in SIP, session invitations can be
   retargeted or forked.  MIKEY modes that require the Initiator to
   target a single well known Responder may be impractical here as they
   may require multiple roundtrips to do key negotiation.  By allowing
   the Responder to generate secret material used for key derivation
   this mode allows for an efficient key delivery scheme.  Note that the
   Initiator can contribute to the material the key is derived from
   through CSB-ID and RAND payloads in unicast use cases.  This mode is
   also useful in multicast scenarios where multiple clients are
   contacting a known server and are downloading the key.  Server
   workload is significantly reduced in these scenarios compared to
   MIKEY in public key mode.  Examples of deployments where this mode
   can be used are enterprises with PKI, service provider setups where
   the service provider decides to provision certificates to its users,
   etc.

4.4.  ECC algorithms support

   [I-D.ietf-msec-mikey-ecc] proposes extensions to the authentication,
   encryption and digital signature methods described for use in MIKEY,
   employing elliptic-curve cryptography (ECC).  These extensions are
   defined to align MIKEY with other ECC implementations and standards.

   The motivation for supporting ECC within the MIKEY stems from the
   following advantages:

   o  ECC support is generally added to security protocols
   o  ECC support requires considerably smaller keys by keeping the same
      security level compared to other asymmetric techniques (like RSA).
      Elliptic curve algorithms are capable of providing security
      consistent with AES keys of 128, 192, and 256 bits without
      extensive growth in asymmetric key sizes.
   o  As stated in [I-D.ietf-msec-mikey-ecc] implementations have shown
      that elliptic curve algorithms can significantly improve
      performance and security-per-bit over other recommended
      algorithms.

   These advantages make the usage of ECC especially interesting for
   embedded devices, which may have only limited performance and storage
   capabilities.

   [I-D.ietf-msec-mikey-ecc] proposes several ECC based mechanisms to
   enhance the MIKEY key distribution schemes, as there are:

   o  Use of ECC methods with public-key encryption (MIKEY-RSA); ECDSA
   o  Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES)





Fries & Ignjatic         Expires August 30, 2006               [Page 11]

Internet-Draft          MIKEY modes applicability          February 2006


   o  Use of ECC methods with Diffie-Hellman key exchange (MIKEY-DHSIGN)
   o  Use of Elliptic Curve Menezes-Qu-Vanstone (MIKEY-MQV)

   The following subsections will provide more detailed information
   about the message exchanges for MIKEY-ECIES and MIKEY-MQV.

4.4.1.  Elliptic Curve Integrated Encryption Scheme application in MIKEY

   The following figure shows the message exchange for the MIKEY-ECIES
   scheme:


   Initiator                                       Responder

   I_MESSAGE =
   HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
       ECCPT, KEMAC, [CHASH], SIGNi       --->
                                                   R_MESSAGE =
                                         [<---]    HDR, T, [IDr], V

4.4.2.  Elliptic Curve Menezes-Qu-Vanstone Scheme application in MIKEY

   The following figure shows the message exchange for the MIKEY-MQV
   scheme:


   Initiator                                      Responder

   I_MESSAGE =
   HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
      ECCPT, KEMAC, [CHASH], SIGNi       --->
                                                  R_MESSAGE =
                                        [<---]    HDR, T, [IDr], V

4.5.  New Payload for bootstrapping TESLA

   TESLA [RFC4082] is a protocol for providing source authentication in
   multicast scenarios.  TESLA is an efficient protocol with low
   communication and computation overhead, which scales to large numbers
   of receivers, and also tolerates packet loss.  TESLA is based on
   loose time synchronization between the sender and the receivers.
   Source authentication is realized in TESLA by using Message
   Authentication Code (MAC) chaining.  The use of TESLA within the
   Secure Real-time Transport Protocol (SRTP) has been published in
   [RFC4383] targeting multicast authentication in scenarios, where SRTP
   is applied to protect the multimedia data.  This solution assumes
   that TESLA parameters are made available by out-of-band mechanisms.




Fries & Ignjatic         Expires August 30, 2006               [Page 12]

Internet-Draft          MIKEY modes applicability          February 2006


   [I-D.ietf-msec-bootstrapping-tesla] specifies payloads for MIKEY to
   bootstrap TESLA for source authentication of secure group
   communications using SRTP.  TESLA may be bootstrapped using one of
   the MIKEY key management approaches described above sent via unicast,
   multicast or broadcast.  This approach provides the necessary
   parameter payload extensions for the usage of TESLA in SRTP but is
   not limited to this.

4.6.  New Key ID information type

   This extension specifies a new Type (the Key ID Information Type) for
   the General Extension Payload.  This is used in, e.g., the Multimedia
   Broadcast/Multicast Service (MBMS) specified in the 3rd Generation
   Partnership Project (3GPP).  MBMS requires the use of MIKEY to convey
   the keys and related security parameters needed to secure the
   multimedia that is multicast or broadcast.

   One of the requirements that MBMS puts on security is the possibility
   to perform frequent updates of the keys.  The rationale behind this
   is that it should be inconvenient for subscribers to publish the
   decryption keys enabling non-subscribers to view the content.  To
   implement this, MBMS uses a three level key management, to distribute
   group keys to the clients, and be able to re-key by pushing down a
   new group key.  MBMS has the need to identify, which types of key are
   involved in the MIKEY message, and their identity.

   [I-D.ietf-msec-newtype-keyid] specifies a new Type for the General
   Extension Payload in MIKEY, to identify the type and identity of
   involved keys.


5.  Selection and interworking of MIKEY modes

   While MIKEY and its extensions provide plenty of choice in terms of
   modes of operation an implementation may choose to simplify its
   behavior.  This can be achieved by operating in a single mode of
   operation when in Initiator's role.  Where PKI is available and/or
   required an implementation may choose for example to start all
   sessions in RSA-R mode but it would be trivial for it to act as a
   Responder in public key mode.  If envelope keys are cached it can
   then also choose to do re-keying in shared key mode.  In general,
   modes of operation where the Initiator generates keying material are
   useful when two peers are aware of each other before the MIKEY
   communication takes place.  If an implementation chooses not to
   operate in shared key mode its behavior may be identical to a peer
   that does but lacks the shared key.  Similarly, if a peer chooses not
   to operate in the public key mode it may reject the certificate of
   the Initiator.  The same applies to peers that choose to operate in



Fries & Ignjatic         Expires August 30, 2006               [Page 13]

Internet-Draft          MIKEY modes applicability          February 2006


   one of the DH modes exclusively.

   Choosing between the different modes of MIKEY depends strongly on the
   use case.  This document may discuss further scenarios to argue for
   preferred modes.  The following call scenarios provide a list of
   potential call scenarios and are matter of discussion:

   o  Call Transfer
   o  Forking

   Forward MIKEY modes like public key or shared key mode when used in
   SIP/SDP may lead to complications in some calls scenarios, for
   example forking scenarios key derivation material gets distributed to
   multiple parties.  As mentioned earlier this may be impractical as
   some of the destinations may not have the resources to validate the
   message and may cause the initiator to drop the session invitation.
   Even in the case all parties involved have all the prerequisites for
   interpreting the MIKEY message received there is a possible problem
   with multiple responders starting media sessions using the same key.
   While the SSRCs will be different in most of the cases they are only
   sixteen bits long and there is a high probability of a two time pad
   problem.  As suggested earlier forward modes are most useful when the
   two peers are aware of each other before the communication takes
   place (as is the case in key renewal scenarios when costly public key
   operations can be avoided by using the envelope key).


6.  Transport of MIKEY messages

   MIKEY defines message formats to transport key information and
   security policies between communicating entities.  It does not define
   the embedding of these messages into the used signaling protocol.
   This definition is provided in separate documents, depending on the
   used signaling protocol.

   Several IETF defined protocols utilize the Session Description
   Protocol (SDP, [RFC2327]) to transport the session parameters.
   Examples are the Session Initiation Protocol (SIP, [RFC3261] or the
   Gateway Control Protocol (GCP, [RFC3525]).  The transport of MIKEY
   messages as part of SDP is described in [I-D.ietf-mmusic-kmgmt-ext].
   Here, the complete MIKEY message is base64 encoded and transmitted as
   part of the SDP part of the signaling protocol message.  Note, as
   several key distribution messages may be transported within one SDP
   container, [I-D.ietf-mmusic-kmgmt-ext] also comprises an integrity
   protection regarding all supplied key distribution attempts.  Thus,
   bidding down attacks will be recognized.

   MIKEY is also applied in ITU-T protocols like H.323, which is used to



Fries & Ignjatic         Expires August 30, 2006               [Page 14]

Internet-Draft          MIKEY modes applicability          February 2006


   establish communication sessions similar to SIP.  For H.323 a
   security framework exists, which is defined in H.235.  Within this
   framework H.235.7 [H.235.7] describes the usage of MIKEY and SRTP in
   the context of H.323.  In contrast to SIP H.323 uses ASN.1 (Abstract
   Syntax Notation).  Thus there is no need to encode the MIKEY
   container as base64.  Within H.323 the MIKEY container is binary
   encoded.


7.  Summary of MIKEY related IANA Registrations

   For MIKEY and the extensions to MIKEY IANA registrations have been
   made.  Here only a link to the appropriate IANA registration is
   provided to avoid inconsistencies.  The IANA registrations for MIKEY
   payloads can be found under
   http://www.iana.org/assignments/mikey-payloads These registrations
   comprise the MIKEY base registrations as well as registrations made
   by MIKEY extensions regarding the payload.

   The IANA registrations for MIKEY port numbers can be found under
   http://www.iana.org/assignments/port-numbers (search for MIKEY).


8.  Security Considerations

   This document does not define extensions to existing protocols.  It
   rather provides an overview about the set of MIKEY and available
   extensions.  Thus, the reader is referred to the original documents
   defining the base protocol and the extensions for the security
   considerations.


9.  IANA Considerations

   This document does not require any IANA registration.


10.  Acknowledgments

   The authors would like to thank Lakshminath Dondeti for his document
   reviews and for his guidance.


11.  References







Fries & Ignjatic         Expires August 30, 2006               [Page 15]

Internet-Draft          MIKEY modes applicability          February 2006


11.1.  Normative References

   [I-D.ietf-mmusic-kmgmt-ext]
              Arkko, J., "Key Management Extensions for Session
              Description Protocol (SDP) and Real  Time Streaming
              Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in
              progress), June 2005.

   [I-D.ietf-msec-bootstrapping-tesla]
              Fries, S. and H. Tschofenig, "Bootstrapping TESLA",
              draft-ietf-msec-bootstrapping-tesla-03 (work in progress),
              January 2006.

   [I-D.ietf-msec-mikey-dhhmac]
              Euchner, M., "HMAC-authenticated Diffie-Hellman for
              MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in
              progress), April 2005.

   [I-D.ietf-msec-mikey-ecc]
              Milne, A., "ECC Algorithms For MIKEY",
              draft-ietf-msec-mikey-ecc-00 (work in progress),
              February 2006.

   [I-D.ietf-msec-mikey-rsa-r]
              Ignjatic, D., "An additional mode of key distribution in
              MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-02 (work
              in progress), February 2006.

   [I-D.ietf-msec-newtype-keyid]
              Carrara, E., "The Key ID Information Type for the General
              Extension Payload in MIKEY",
              draft-ietf-msec-newtype-keyid-03 (work in progress),
              December 2005.

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

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.







Fries & Ignjatic         Expires August 30, 2006               [Page 16]

Internet-Draft          MIKEY modes applicability          February 2006


11.2.  Informative References

   [H.235.7]  ""ITU-T Recommendation H.235.7: Usage of the MIKEY Key
              Management Protocol for the Secure Real Time Transport
              Protocol (SRTP) within H.235"", 2005.

   [I-D.ietf-mmusic-sdescriptions]
              Andreasen, F., "Session Description Protocol Security
              Descriptions for Media Streams",
              draft-ietf-mmusic-sdescriptions-12 (work in progress),
              September 2005.

   [ISO_sec_time]
              ""ISO/IEC 18014 Information technology - Security
              techniques - Time-stamping services, Part 1-3."", 2002.

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

   [RFC2327]  Handley, M. and V. Jacobson, "SDP: Session Description
              Protocol", RFC 2327, April 1998.

   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
              RFC 2412, November 1998.

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

   [RFC3525]  Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
              "Gateway Control Protocol Version 1", RFC 3525, June 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4082]  Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
              Briscoe, "Timed Efficient Stream Loss-Tolerant
              Authentication (TESLA): Multicast Source Authentication
              Transform Introduction", RFC 4082, June 2005.

   [RFC4383]  Baugher, M. and E. Carrara, "The Use of Timed Efficient
              Stream Loss-Tolerant Authentication (TESLA) in the Secure
              Real-time Transport Protocol (SRTP)", RFC 4383,
              February 2006.

   [SAML_overview]



Fries & Ignjatic         Expires August 30, 2006               [Page 17]

Internet-Draft          MIKEY modes applicability          February 2006


              Huges, J. and E. Maler, ""Security Assertion Markup
              Language (SAML) 2.0 Technical Overview, Working Draft"",
              2005.
















































Fries & Ignjatic         Expires August 30, 2006               [Page 18]

Internet-Draft          MIKEY modes applicability          February 2006


Authors' Addresses

   Steffen Fries
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: steffen.fries@siemens.com


   Dragan Ignjatic
   Polycom
   1000 W. 14th Street
   North Vancouver, BC  V7P 3P3
   Canada

   Email: dignjatic@polycom.com

































Fries & Ignjatic         Expires August 30, 2006               [Page 19]

Internet-Draft          MIKEY modes applicability          February 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Fries & Ignjatic         Expires August 30, 2006               [Page 20]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/