[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fries-msec-mikey-applicability) 00 01 02 03 04 05 06 07 08 09 RFC 5197

MSEC                                                            S. Fries
Internet-Draft                                                   Siemens
Intended status: Informational                               D. Ignjatic
Expires: August 1, 2008                                          Polycom
                                                        January 29, 2008


       On the applicability of various MIKEY modes and extensions
               draft-ietf-msec-mikey-applicability-07.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 1, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).













Fries & Ignjatic         Expires August 1, 2008                 [Page 1]

Internet-Draft          MIKEY modes applicability           January 2008


Abstract

   Multimedia Internet Keying - MIKEY - is a key management protocol
   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 is standardized within RFC3830 and
   defines four key distribution methods.  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 methods, but also in terms of payload
   enhancements.

   This document provides an overview about the MIKEY base document in
   general as well as the existing extensions for MIKEY, which have been
   defined or are in the process of definition.  It is intended as
   additional source of information for developers or architects to
   provide more insight in use case scenarios and motivations as well as
   advantages and disadvantages for the different key distribution
   schemes.  The use cases discussed in this document are strongly
   related to dedicated SIP call scenarios providing challenges for key
   management in general among them media before SDP answer, forking,
   and shared key conferencing.





























Fries & Ignjatic         Expires August 1, 2008                 [Page 2]

Internet-Draft          MIKEY modes applicability           January 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology and Definitions  . . . . . . . . . . . . . . . . .  6
   3.  MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Pre-shared key protected distribution  . . . . . . . . . .  9
     3.2.  Public Key encrypted key distribution  . . . . . . . . . . 10
     3.3.  Diffie-Hellman key agreement protected with digital
           signatures . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.4.  Unprotected key distribution . . . . . . . . . . . . . . . 12
     3.5.  Diffie-Hellman key agreement protected with pre-shared
           secrets  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.6.  SAML assisted DH-key agreement . . . . . . . . . . . . . . 13
     3.7.  Asymmetric key distribution with in-band certificate
           exchange . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Further MIKEY Extensions . . . . . . . . . . . . . . . . . . . 17
     4.1.  ECC algorithms support . . . . . . . . . . . . . . . . . . 17
       4.1.1.  Elliptic Curve Integrated Encryption Scheme
               application in MIKEY . . . . . . . . . . . . . . . . . 18
       4.1.2.  Elliptic Curve Menezes-Qu-Vanstone Scheme
               application in MIKEY . . . . . . . . . . . . . . . . . 18
     4.2.  New MIKEY Payload for bootstrapping TESLA  . . . . . . . . 18
     4.3.  MBMS extensions to the Key ID information type . . . . . . 19
     4.4.  OMA BCAST MIKEY General Extension Payload Specification  . 19
     4.5.  Supporting Integrity Transform carrying the Rollover
           Counter  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   5.  Selection and interworking of MIKEY modes  . . . . . . . . . . 21
     5.1.  MIKEY and Early Media  . . . . . . . . . . . . . . . . . . 22
     5.2.  MIKEY and Forking  . . . . . . . . . . . . . . . . . . . . 23
     5.3.  MIKEY and Call Transfer/Redirect/Retarget  . . . . . . . . 24
     5.4.  MIKEY and Shared Key Conferencing  . . . . . . . . . . . . 25
   6.  Transport of MIKEY messages  . . . . . . . . . . . . . . . . . 26
   7.  MIKEY alternatives for SRTP security parameter negotiation . . 27
   8.  Summary of MIKEY related IANA Registrations  . . . . . . . . . 29
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     12.2. Informative References . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 37









Fries & Ignjatic         Expires August 1, 2008                 [Page 3]

Internet-Draft          MIKEY modes applicability           January 2008


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 RFC3830 is not restricted to be used
   for SRTP only, as it features a generic approach and allows for
   extensions to the key distribution schemes.  Thus, it may also be
   used for security parameter negotiation for other protocols.

   For MIKEY meanwhile seven key distribution methods are described as
   there are:

   o  Symmetric key distribution as defined in [RFC3830] (MIKEY-PSK)

   o  Asymmetric key distribution as defined in [RFC3830] (MIKEY-RSA)

   o  Diffie-Hellman key agreement protected by digital signatures as
      defined in [RFC3830] (MIKEY-DHSIGN)

   o  Unprotected key distribution (MIKEY-NULL)

   o  Diffie-Hellman key agreement protected by symmetric pre-shared
      keys as defined in [RFC4650] (MIKEY-DHHMAC)

   o  SAML assisted Diffie-Hellman key agreement as defined (not
      available as seperate document, but discussions are reflected
      within this document (MIKEY-DHSAML))

   o  Asymmetric key distribution (based on asymmetric encryption) with
      in-band certificate provision as defined in [RFC4738]
      (MIKEY-RSA-R)

   Note that the latter three modes are extensions to MIKEY as there
   have been scenarios where none of the first four modes defined in
   [RFC3830] fits perfectly.  There are further extensions to MIKEY
   comprising algorithm enhancements and a new payload definition
   supporting other protocols than SRTP.

   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]



Fries & Ignjatic         Expires August 1, 2008                 [Page 4]

Internet-Draft          MIKEY modes applicability           January 2008


      as defined in [RFC4442]

   o  The Key ID information type for the general extension payload as
      defined in [RFC4563]

   o  OMA BCAST MIKEY General Extension Payload Specification, as
      defined in [RFC4909]

   o  Integrity Transform Carrying Roll-over Counter for SRTP, as
      defined in [RFC4771].  Note that this is rather an extension to
      SRTP and requires MIKEY to carry a new parameter, but is stated
      here for completeness.

   This document provides an overview about RFC3830 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
   architects to provide more insight in use case scenarios and
   motivations as well as advantages and disadvantages for the different
   key distribution schemes.  The use cases discussed in this document
   are strongly related to dedicated SIP call scenarios providing
   challenges for key management in general, as there are:

   o  Early Media respectively Media before SDP answer

   o  Forking

   o  Call Transfer/Redirect/Retarget

   o  Shared Key Conferencing






















Fries & Ignjatic         Expires August 1, 2008                 [Page 5]

Internet-Draft          MIKEY modes applicability           January 2008


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 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 SA        Data Security Association information for the security
                  protocol, including a TEK and a set of parameters/
                  policies.

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

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

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

   CSB ID         Crypto Session Bundle ID, unique identifier for the
                  CSB.

   TGK            TEK Generation Key, 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.

   TEK            Traffic-Encrypting Key, 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 1, 2008                 [Page 6]

Internet-Draft          MIKEY modes applicability           January 2008


   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

   The following definition has been added to the ones from [RFC3830]:

   SSRC           Synchronization Source Identifier












Fries & Ignjatic         Expires August 1, 2008                 [Page 7]

Internet-Draft          MIKEY modes applicability           January 2008


3.  MIKEY Overview

   This section will provide an overview about MIKEY.  MIKEY focuses on
   the setup of cryptographic context to secure multimedia sessions in a
   heterogeneous environment.  MIKEY is mainly intended to be used for
   peer-to-peer, simple one-to-many, and small-size (interactive)
   groups.  One objective of MIKEY is to produce a Data security
   association (SA) for the security protocol, including a traffic-
   encrypting key (TEK), which is derived from a TEK Generation Key
   (TGK), and used as input for the security protocol.

   MIKEY supports the possibility of establishing keys and parameters
   for more than one security protocol (or for several instances of the
   same security protocol) at the same time.  The concept of Crypto
   Session Bundle (CSB) is used to denote a collection of one or more
   Crypto Sessions that can have common TGK and security parameters, but
   which obtain distinct TEKs from MIKEY.

   MIKEY as defined in RFC3830 may proceed with one roundtrip at most,
   using a so-called Initiator message for the forward direction and a
   Responder message for the backward direction.  Note that there exist
   MIKEY schemes, which may proceed within a half roundtrip (e.g., based
   on a pre-shared key), while other schemes require a full roundtrip
   (e.g., Diffie Hellman based schemes).  The main objective of the
   Initiator's message (I_MESSAGE) is to transport one or more TGKs
   (carried in the KEMAC field) and a set of security parameters (SPs)
   to the Responder in a secure manner.  As the verification message
   from the Responder is optional for some schemes, the Initiator
   indicates whether it requires a verification message or not from the
   Responder.

   The focus of the following subsections lies on the key distribution
   methods 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.  A secure network clock
   synchronization protocol should realize this.  RFC3830 recommends 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 endpoint,
   clock synchronization by deriving time from a trusted outbound proxy
   may be appropriate.

   The different MIKEY related schemes are compared regarding following
   criteria:

   o  Mandatory for implementation: provides information, if RFC3830
      requires the implementation of this scheme.




Fries & Ignjatic         Expires August 1, 2008                 [Page 8]

Internet-Draft          MIKEY modes applicability           January 2008


   o  Scalability: describes the technical feasibility to easily deploy
      a solution based on the considered scheme

   o  Dependency on PKI: states if the support of a PKI is required to
      support this scheme.  Note, that PKI here relates to PKI services
      like key generation, distribution and revocation.

   o  Provision of Perfect Forward Secrecy (PFS): Describes the support
      of PFS, which is, according to RFC4949 [RFC4949] the the property
      that compromising the long-term keying material does not
      compromise session keys that were previously derived from the
      long-term material.

   o  Key generation involvement: Describes if both or just one of the
      participants are actively involved in key generation.  The option
      to involve both parties in the key generation is interesting to
      avoid that one communication partner generates (intentionally or
      unintentionally) weak keys.

   o  Support of group keying: Analysis the option to use the considered
      scheme also for group keying in, e.g., conferencing scenarios.

   If MIKEY is used for SRTP [RFC3711] bootstrapping, it also uses the
   SSRC to associate security policies with actual sessions.  The SSRC
   identifies the synchronization source.  The value is chosen randomly,
   with the intent that no two synchronization sources within the same
   SRTP session will have the same SSRC.  Although the probability of
   multiple sources choosing the same identifier is low, all (S)RTP
   implementations must be prepared to detect and resolve collisions.
   Nevertheless in multimedia communication scenarios supporting forking
   (see Section 5.2), collisions may occur leading to so-called two-time
   pads, i.e., the same key is used for media streams to different
   destinations.  Note that two time pads may also occur for media
   streams to the same destination.

3.1.  Pre-shared key protected 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.  Note that the pre-
   shared secret is agreed upon before the session, e.g., by out-of-band
   means.  The response message is optional and may be used for mutual
   authentication (proof of possession of the pre-shared secret) or
   error signaling.







Fries & Ignjatic         Expires August 1, 2008                 [Page 9]

Internet-Draft          MIKEY modes applicability           January 2008


   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 perfect forward secrecy is not provided and
   key generation is just performed by the initiator.  Furthermore, the
   approach is not scalable to larger configurations but is acceptable
   in small-sized groups.  Note that according to [RFC3830] this option
   is mandatory to implement.

3.2.  Public Key encrypted key distribution

   Using the asymmetric option of the key management, the initiator
   generates the key material (TGK's) to be transmitted and sends it
   encrypted with a so-called envelope key, which in turn is encrypted
   with the receiver's public key.  The envelope key, env-key, which is
   a random number, 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 or error signaling.

   Initiator                                    Responder

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

   An advantage of this approach is that it allows the usage of self-
   signed certificates, which in turn can avoid a full blown PKI.  Note
   that using self-signed certificates may result in limited scalability
   and also require additional means for authentication such as exchange
   of fingerprints of the certificates or similar techniques.  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.  Additionally, the responder
   certificate needs to be available in advance at the sender's side.
   Furthermore, the verification of certificates may not be done in



Fries & Ignjatic         Expires August 1, 2008                [Page 10]

Internet-Draft          MIKEY modes applicability           January 2008


   real-time.  This could be the case in scenarios where the revocation
   status of certificates is checked through a further component.
   Depending on the initiator role this scheme may can also be applied
   in group based communication, where a central server distributes the
   group key protected with the public keys of the associated clients.
   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 mandate the support of RSA as specific asymmetric
   algorithm for the signature generation.  Additionally the algorithm
   used for signature or public key encryption is 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 (both parties provide to the key), perfect
   forward secrecy, and the absence of the need to fetch a certificate
   in advance as needed for the MIKEY-RSA method depicted above.
   Moreover, it provides also the option to use self-signed certificates
   to avoid PKI (would result in limited scalability and more complex
   provisioning).  Note that, depending on the security policy, self-
   signed certificates may not be suitable for every use case.

   Negatively to remark is that this approach scales mainly to point-to-
   point and depends on PKI for full scalability.  Multiparty
   conferencing is not supported using just MIKEY-DHSIGN.  Nevertheless,
   the established Diffie-Hellman-Secret may serve as a pre-shared key
   to bootstrap group-related security parameter.  Furthermore, as for
   the MIKEY-RSA mode described above, the verification of certificates
   may not be necessarily 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] it is
   optional to implement this scheme.



Fries & Ignjatic         Expires August 1, 2008                [Page 11]

Internet-Draft          MIKEY modes applicability           January 2008


3.4.  Unprotected key distribution

   RFC3830 also supports a mode to provide a key in an unprotected
   manner (MIKEY-NULL).  This is based on the symmetric key encryption
   option depicted in Section 3.1 but is used with the NULL encryption
   and the NULL authentication algorithm.  It may be compared with the
   plain approach in sdescriptions [RFC4568].  MIKEY-NULL completely
   relies on the security of the underlying layer, e.g., provided by
   TLS.  This option should be used with caution as it does not protect
   the key management.

   Based on the missing cryptographic protection of this method, it is
   obvious that perfect forward secrecy is not provided.  As it is based
   on the pre-shared secret mode only the initiator provides to the key
   management.  The method itself is highly scalable but again, without
   proper protection through an underlying security layers it is not
   advisable to be used.

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

   This is an additional option which has been defined in [RFC4650].  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 =
       HDR, T, RAND, [IDi],
       IDr, {SP}, DHi, KEMAC      --->
                                             R_MESSAGE =
                                  <---           HDR, T,[IDr], IDi,
                                                 DHr, DHi, KEMAC

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

   For the integrity protection of the Diffie-Hellman key agreement
   [RFC4650] 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.  Lack of support for group keying is a
   disadvantage.

   This mode of operation provides an efficient scheme in deployments



Fries & Ignjatic         Expires August 1, 2008                [Page 12]

Internet-Draft          MIKEY modes applicability           January 2008


   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.  In contrast to the
   plain pre-shared key encryption based mode, described in Section 3.1,
   this mode offers perfect forward secrecy as well as active
   involvement in the key generation of both parties involved.

3.6.  SAML assisted DH-key agreement

   There has been a longer discussion during IETF meetings and also on
   the IETF MSEC mailing about a SAML assisted DH approach.  This idea
   has not been submitted as a separate draft.  Nevertheless, the
   discussion is reflected here as it is targeted to fulfill general
   requirements on key management approaches.  Those requirements can be
   summarized as:

   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 fulfill all of the requirements, it was proposed to use a classic
   Diffie-Hellman key agreement protocol for key establishment in
   conjunction with a User Agents (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 (referred to as CRED below), 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.  It provides the involved clients with
   mutual authentication and message integrity of the key management
   messages exchanged.










Fries & Ignjatic         Expires August 1, 2008                [Page 13]

Internet-Draft          MIKEY modes applicability           January 2008


   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 scheme 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.  The second roundtrip can also be used for distribution of group
   keys or to leverage 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.

   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.

   Regarding the different criteria discussed in the introduction of
   this section, the advantages of this approach are a fair, mutual key
   agreement (both parties provide to the key), perfect forward secrecy.
   Through the second roundtrip, the dependency on synchronized clocks
   can be avoided.  Moreover, this second roundtrip enables the
   distribution of a group key and thus enhances the scalability from
   mainly point-to-point to also multiparty conferencing.  The usage of
   SAML assisted DH may decrease the hidden latency cost through the
   credential validation necessary to be done for the signed DH scheme
   described in Section 3.3.  If the UA received its SAML assertion from
   its domain's SIP server, it is trusting the server implicitly thus it
   may extend that trust to relying on it to validate the other party's



Fries & Ignjatic         Expires August 1, 2008                [Page 14]

Internet-Draft          MIKEY modes applicability           January 2008


   SAML assertion.  This not only eliminates the hidden validation
   latency, but also its computational cost to the UA.

   Negatively to remark is that this proposal does have one significant
   security risk.  The UA's SIP server can cheat and create an extra
   authentication object for the UA where it has the Diffie-Hellman
   private key.  With this, the (SIP) server issuing the SAML assertion
   can successfully launch a MITM attack against two of its UAs.  Also
   two SIP servers can collude so that either can successfully launch a
   MITM attack against their UAs.  A UA can block this attack if its
   Diffie-Hellman key is authenticated by a trustworthy third party and
   this whole object is signed by the SIP server.  Moreover, this
   approach uses two roundtrips, increasing the necessary bandwidth and
   also the setup time, which may be crucial for many scenarios.  For
   the credential generation usually a seperate component (server) is
   necessary, so server less call setup is not supported.

3.7.  Asymmetric key distribution with in-band certificate exchange

   This is an additional option which has been defined in [RFC4738].  It
   describes the asymmetric key distribution with optional in-band
   certificate exchange.

   Initiator                             Responder

   I_MESSAGE =
   HDR, T, [IDi|CERTi], [IDr],
         {SP}, [RAND], SIGNi      --->
                                         R_MESSAGE =
                                  <---   HDR, [GenExt(CSB-ID)], T,
                                           RAND, [IDr|CERTr], [SP],
                                           KEMAC, 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 (if the receiver knows the
   certificate in advance, RFC3830's MIKEY-RSA mode may be used
   instead).  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 a publicly accepted authority the certificate validation
   can be done in a straightforward manner, by using the commonly known
   certificate authority's public key.  In the other case additional
   steps may be necessary.  The disadvantage is that no perfect forward
   secrecy is provided.




Fries & Ignjatic         Expires August 1, 2008                [Page 15]

Internet-Draft          MIKEY modes applicability           January 2008


   This mode is meant to provide an easy option for certificate
   provisioning when PKI is present 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
   key material since 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.  Responder workload is significantly reduced
   in these scenarios compared to MIKEY in public key mode.  This is due
   to the fact that the asymmetric encryption requires less effort
   compared to the decryption using the private key.  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.

































Fries & Ignjatic         Expires August 1, 2008                [Page 16]

Internet-Draft          MIKEY modes applicability           January 2008


4.  Further MIKEY Extensions

   This section will provide an overview about further MIKEY [RFC3830]
   extensions for crypto algorithms, generic payload enhancements, as
   well as enhancements to support the negotiation of security
   parameters for other security protocols than SRTP.  These extensions
   have been defined in several additional documents.

4.1.  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 modes are more and more 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 extending the Diffie-Hellman key exchange:
      MIKEY-DHSIGN with ECDSA or ECGDSA

   o  Use of ECC methods extending the Diffie-Hellman key exchange:
      MIKEY-DHSIGN with ECDH

   o  Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES)

   o  Use of Elliptic Curve Scheme Menezes-Qu-Vanstone (MIKEY-ECMQV)




Fries & Ignjatic         Expires August 1, 2008                [Page 17]

Internet-Draft          MIKEY modes applicability           January 2008


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

4.1.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}, KEMAC,
       [CHASH], PKE, SIGNi        --->
                                                   R_MESSAGE =
                                 [<---]            HDR, T, [IDr], V

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

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

   Initiator                                      Responder

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

4.2.  New MIKEY 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.

   [RFC4442] 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



Fries & Ignjatic         Expires August 1, 2008                [Page 18]

Internet-Draft          MIKEY modes applicability           January 2008


   described above by sending the MIKEY message via unicast, multicast
   or broadcast.  This approach provides the necessary parameter payload
   extensions for the usage of TESLA in SRTP.  Nevertheless, if the
   parameter set is also sufficient for other TESLA use cases, it can be
   applied as well.

4.3.  MBMS extensions to the 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 ability to
   perform frequent updates of the keys.  The rationale behind this is
   that it will be costly for subscribers to re-distribute the
   decryption keys to non-subscribers.  The cost for re-distributing the
   keys using the unicast channel should be higher than the cost of
   purchasing the keys for this scheme to have an effect.  To achieve
   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 keys are
   involved in the MIKEY message and their identity.

   [RFC4563] specifies a new Type for the General Extension Payload in
   MIKEY, to identify the type and identity of involved keys.  Moreover,
   as MBMS uses MIKEY both as a registration protocol and a re-key
   protocol, this RFC specifies the necessary additions that allow MIKEY
   to function both as a unicast and multicast re-key protocol in the
   MBMS setting.

4.4.  OMA BCAST MIKEY General Extension Payload Specification

   The document [RFC4909] specifies a new general extension payload type
   for use in the Open Mobile Alliance's (OMA) Browser and Content
   Broadcast (BCAST) group.  OMA BCAST's service and content protection
   specification uses short term key message and long term key message
   payloads that in certain broadcast distribution systems are carried
   in MIKEY.  The document defines a general extensions payload to allow
   possible extensions to MIKEY without defining a new payload.  The
   general extension payload can be used in any MIKEY message and is
   part of the authenticated or signed data part.  Note, that only a
   parameter description is included, but no key information.






Fries & Ignjatic         Expires August 1, 2008                [Page 19]

Internet-Draft          MIKEY modes applicability           January 2008


4.5.  Supporting Integrity Transform carrying the Rollover Counter

   The document [RFC4771] defines a new integrity transform for SRTP
   [RFC3711] providing the option to also transmit the Roll Over Counter
   (ROC) as part of dedicated SRTP packets.  This extension has been
   defined for the use in the 3GPP multicast/broadcast service.  While
   the communicating parties did agree on a starting ROC, in some cases
   the receiver may not be able to synchronize his ROC with the one used
   by the sender even if it is signaled to him out of band.  Here the
   new extension provides the possibility for the receiver to re-
   synchronize to the sender's ROC.  To signal the use of the new
   integrity transform new definitions for certain MIKEY payloads need
   to be done.  These new definition comprise the integrity transforms
   itself as well as new integrity transform parameter.  Moreover, the
   document specifies additional parameter, to enable the usage of
   different integrity transforms for SRTP and SRTCP.



































Fries & Ignjatic         Expires August 1, 2008                [Page 20]

Internet-Draft          MIKEY modes applicability           January 2008


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 and 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.  An implementation that does not support
   shared key mode can mimic behavior of 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 one of the DH modes
   exclusively.

   Forward MIKEY modes, were the initiator provides the key material,
   like public key or shared key mode when used in SIP/SDP may lead to
   complications in some calls scenarios, for example forking scenarios
   were 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).

   The following list gives an idea how the different MIKEY modes may be
   used or combined, depending on available key material at the
   initiator side.

   1.  If the Initiator has a PSK with the Responder, it uses the PSK
       mode.

   2.  If the Initiator has a PSK with the Responder, but needs PFS or
       knows that the responder has a policy that both parties should
       provide entropy to the key, then it uses the DH-HMAC mode.





Fries & Ignjatic         Expires August 1, 2008                [Page 21]

Internet-Draft          MIKEY modes applicability           January 2008


   3.  If the Initiator has the RSA key of the Responder, it uses the
       RSA mode to establish the TGK.  Note that the TGK may be used as
       PSK together with Option 1 for further key management operations.

   4.  If the Initiator does not expect the receiver to have his
       certificate he may use RSA-R.  Using RSA-R he can provide the
       initiators certificate information in-band to the receiver.
       Moreover, the initiator may also provide a random number which
       can be used by the receiver for key generation.  Thus both
       parties can be involved in the key management.  But as the
       inclusion of the random number cannot be forced by the initiator,
       true PFS cannot be provided.  Note that in this mode, after
       establishing the TGK, it may be used as PSK with other MIKEY
       modes.

   5.  The Initiator uses DH-SIGN when PFS is required by his policy and
       he knows that the responder has a policy that both parties should
       provide entropy.  Note that also in this mode, after establishing
       the TGK, it may be used as PSK with other MIKEY modes.

   6.  If no PSK or certificate is available at the initiators side (and
       likewise at the receivers side) but lower level security (like
       TLS ot IPSec) is in place the user may use the unprotected mode
       of MIKEY.

   Besides the available key material choosing between the different
   modes of MIKEY depends strongly on the use case.  This section will
   depict dedicated scenarios to discuss the feasibility of the
   different modes in these scenarios.  A comparison of the different
   modes of operation regarding the influences and requirements to the
   deploying infrastructure as well as the cryptographic strength can be
   found in [I-D.ietf-sip-media-security-requirements] The following
   list provides the most prominent call scenarios and are matter of
   further discussion:

   o  Early Media

   o  Forking

   o  Call Transfer/Redirect/Retarget

   o  Shared key conferencing

5.1.  MIKEY and Early Media

   The term early media describes two different scenarios.  The first
   one relates to the case where media data are received before the
   actual SDP signaling answer has been received.  This may arise



Fries & Ignjatic         Expires August 1, 2008                [Page 22]

Internet-Draft          MIKEY modes applicability           January 2008


   through the different latency on the signaling and media path.  This
   case is often referred to as media before signaling answer.  The
   second scenario describes the case were media data are send from the
   callee before sending the final SIP 200 OK nessage.  This situation
   appears usually in call center scenarios, when queueing a waiting
   loop or when providing personal ring tones.

   In early media scenarios, SRTP data may be received before the answer
   over the SIP signaling arrives.  The two MIKEY modes, which only
   require one message to be transported (Section 3.1 and Section 3.2),
   work nicely in early media situations, as both, sender and receiver
   have all the necessary parameters in place before actually sending/
   receiving encrypted data.  The other modes, featuring either Diffie-
   Hellman key agreement (Section 3.3, Section 3.5, and Section 3.6) or
   the enhanced asymmetric variant (Section 3.7) suffer from the
   requirements that the initiator has to wait for the response before
   being able to decrypt the incoming SRTP media.  In fact, even if
   early media is not used, in other words if media is not sent before
   the SDP answer a similar problem may arise from the fact that SIP/SDP
   signaling has to traverse multiple proxies on its way back and media
   may arrive before the SDP answer.  It is expected that this delay
   would be significantly shorter than in the case of early media
   though.

   It is worth mentioning here that security descriptions [RFC4568] has
   basically the same problem as the initiating end needs the SDP answer
   before it can start decrypting SRTP media.

   To cope with the early media problem there are further approaches to
   describe security preconditions [RFC5027], i.e., certain
   preconditions need to be met to enable voice data encryption.  One
   example is for instance that a scenario where a provisional response,
   containing the required MIKEY parameter, is sent before encrypted
   media is processed.

5.2.  MIKEY and Forking

   In SIP forking scenarios a SIP proxy server sends an INVITE request
   to more than one location.  This means that also the MIKEY payload,
   which is part of the SDP is sent to several (different) locations.
   MIKEY modes supporting signatures may be used in forking scenarios
   (Section 3.3 and Section 3.7) as here the receiver can validate the
   signature.  There are limitations with the symmetric key encryption
   as well as the asymmetric key encryption modes (Section 3.1 and
   Section 3.2).  This is due to the fact that in symmetric encryption
   the recipient needs to possess the symmetric key before handling the
   MIKEY data.  For asymmetric MIKEY modes, if the sender is aware of
   the forking he may not know in advance to which location the INVITE



Fries & Ignjatic         Expires August 1, 2008                [Page 23]

Internet-Draft          MIKEY modes applicability           January 2008


   is forked and thus may not use the right receiver certificate to
   encrypt the MIKEY envelope key.  Note, the sender may include several
   MIKEY containers into the same INVITE message to cope with forking,
   but this requires the knowledge of all forking targets in advance and
   also requires the possession of the target certificates.  It is out
   of the scope of MIKEY to specify behavior in such a case.  DH modes
   or the Section 3.7 do not have this problem.  In scenarios, where the
   sender is not aware of forking, only the intended receiver is able to
   decrypt the MIKEY container.

   If forking is combined with early media the situation gets
   aggravated.  If MIKEY modes requiring a full roundtrip are used, like
   the signed Diffie-Hellman, multiple responses may overload the end
   device.  An example is forking to 30 destinations (group pickup),
   while MIKEY is used with the signed Diffie-Hellman mode together with
   security preconditions.  Here, every target would answer with a
   provisional response, leading to 30 signature validations and Diffie-
   Hellman calculations at the senders site.  This may lead to a
   prolonged media setup delay.

   Moreover, depending on the MIKEY mode chosen, a two-time pad may
   occur in dependence of the negotiated key material and the SSRC.  For
   the non Diffie-Hellman modes other than RSA-R, a two-time pad may
   occur when multiple receivers pick the same SSRC.

5.3.  MIKEY and Call Transfer/Redirect/Retarget

   In a SIP environment MIKEY exchange is tied to SDP offer/answer and
   irrespective of the implementation model used for call transfer the
   same properties and limitations of MIKEY modes apply as in a normal
   call setup scenarios.

   In certain SIP scenarios the functionality of redirect is supported.
   In redirect scenarios the call initiator gets a response that the
   called party for instance has temporarily moved and may be reached at
   a different destination.  The caller can now perform a call
   establishment with the new destination.  Depending on the originally
   chosen MIKEY mode, the caller may not be able to perform this mode
   with the new destination.  To be more precise MIKEY-PSK, and MIKEY-
   DHHMAC require a pre-shared secret in advance.  MIKEY-RSA requires
   the knowledge about the target's certificate.  Thus, these modes may
   influence the ability of the caller to initiate a session.

   Another functionality, which may be supported in SIP is retargeting.
   In contrast to redirect, the call initiator does not get a response
   about the different target.  The SIP proxy sends the request to a
   different target about receiving a redirect response from the
   originally called target.  This most likely will lead to problems



Fries & Ignjatic         Expires August 1, 2008                [Page 24]

Internet-Draft          MIKEY modes applicability           January 2008


   when using MIKEY modes requiring a pre-shared key (MIKEY-PSK, MIKEY-
   DHHMAC) or were the caller used asymmetric key encryption (MIKEY-RSA)
   because the key management was originally targeted to a different
   destination.

5.4.  MIKEY and Shared Key Conferencing

   First of all, not all modes of MIKEY support shared key conferencing.
   Mainly the Diffie Hellman modes cannot be used straight forward for
   conferencing as this mechanism results in a pair wise shared secret
   key.  All other modes can be applied in conferencing scenarios by
   obeying the initiator and responder role, i.e., the half roundtrip
   modes need to be initiated by the conferencing unit, to be able to
   distribute the conferencing key.  The remaining full roundtrip mode,
   MIKEY RSA-R will be initiated by the client, while the conferencing
   unit provides the conferencing key based on the received certificate.

   An example conferencing architecture is defined in the IETF's XCON
   WG.  The scope of this working group relates to mechanism for
   membership and authorization control, a mechanism to manipulate and
   describe media "mixing" or "topology" for multiple media types
   (audio, video, text), a mechanism for notification of conference
   related events/changes (for example a floor change), and a basic
   floor control protocol.  A document describing possible use case
   scenarios is available in [RFC4597].


























Fries & Ignjatic         Expires August 1, 2008                [Page 25]

Internet-Draft          MIKEY modes applicability           January 2008


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.  Nevertheless, MIKEY can also be transported
   over plain UDP or TCP to port 2269.

   Several IETF defined protocols utilize the Session Description
   Protocol (SDP, [RFC4566]) 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 [RFC4567].  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,
   [RFC4567] 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
   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.






















Fries & Ignjatic         Expires August 1, 2008                [Page 26]

Internet-Draft          MIKEY modes applicability           January 2008


7.  MIKEY alternatives for SRTP security parameter negotiation

   Besides MIKEY there exists several approaches to handle the security
   parameter establishment.  This is due to the fact, that some
   limitations in certain scenarios have been seen.  Examples are early
   media and forking situations as described in Section 5.  The
   following list provides a short summary about possible alternatives:

   o  sdescription - [RFC4568] describes a key management scheme, which
      uses SDP for transport and completely relies on underlying
      protocol security.  For transport the documents defines a SDP
      attribute transmitting all necessary SRTP parameter in clear.  For
      security it references TLS and S/MIME.  In contrast to MIKEY in
      the message from the initiator to the responder the SRTP parameter
      for the direction initiator to responder is sent rather than vice
      versa.  This may lead to problems in early media scenarios.

   o  sdescription with early media support -
      [I-D.wing-mmusic-sdes-early-media] enhances the above scheme with
      the possibility to also be usable in early media scenarios, when
      security preconditions is not used.

   o  Encrypted Key Transport for Secure RTP - [I-D.mcgrew-srtp-ekt] is
      an extension to SRTP that provides for the secure transport of
      SRTP master keys, Rollover Counters, and other information, within
      SRTCP.  This facility enables SRTP to work for decentralized
      conferences with minimal control, and to handle situations caused
      by SIP forking and early media.  It may also be used in
      conjunction with MIKEY.

   o  Diffie Hellman support in SDP - [I-D.baugher-mmusic-sdp-dh]
      defines a new SDP attribute for exchanging Diffie-Hellman public
      keys.  The attribute is an SDP session-level attribute for
      describing DH keys, and there is a new media-level parameter for
      describing public keying material for SRTP key generation.

   o  DTLS-SRTP describing SRTP extensions for DTLS -
      [I-D.ietf-avt-dtls-srtp] describes a method of using DTLS key
      management for SRTP by using a new extension that indicates that
      SRTP is to be used for data protection, and which establishes SRTP
      keys.

   o  ZRTP - [I-D.zimmermann-avt-zrtp] This document defines ZRTP as RTP
      header extensions for a Diffie-Hellman exchange to agree on a
      session key and parameters for establishing SRTP sessions.  The
      ZRTP protocol is completely self-contained in RTP and does not
      require support in the signaling protocol or assume a PKI.




Fries & Ignjatic         Expires August 1, 2008                [Page 27]

Internet-Draft          MIKEY modes applicability           January 2008


   There has been a longer discussion regarding a preferred key
   management approach in the IETF coping with the different scenarios
   and requirements continuously sorting out key management approaches.
   During IETF 68 three options were considered: MIKEY in an updated
   version (referred to as MIKEYv2); ZRTP; and DTLS-SRTP.  The potential
   key management protocol for the standards track for media security
   was voted in favor of DTLS-SRTP.  Thus, the reader is pointed to the
   appropriate resources for further information.  Note that MIKEY has
   already been deployed and is also targeted for use in 3GPP and MBMS
   applications.









































Fries & Ignjatic         Expires August 1, 2008                [Page 28]

Internet-Draft          MIKEY modes applicability           January 2008


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







































Fries & Ignjatic         Expires August 1, 2008                [Page 29]

Internet-Draft          MIKEY modes applicability           January 2008


9.  Security Considerations

   This document does not define extensions to existing protocols.  It
   rather provides an overview about the set of MIKEY modes and
   available extensions and provides information about the applicability
   of the different modes in different scenarios to support the decision
   making for network architects regarding the appropriate MIKEY scheme
   or extension to be used in a dedicated target scenario.  Choosing
   between the different schemes described in this document strongly
   influences the security of the target system as the different schemes
   provide different level of security and also require different
   infrastructure support.

   As this document bases on the MIKEY base specification as well as the
   different specifications of the extensions the reader is referred to
   the original documents for the specific security considerations.



































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

Internet-Draft          MIKEY modes applicability           January 2008


10.  IANA Considerations

   This document does not require any IANA registration.
















































Fries & Ignjatic         Expires August 1, 2008                [Page 31]

Internet-Draft          MIKEY modes applicability           January 2008


11.  Acknowledgments

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















































Fries & Ignjatic         Expires August 1, 2008                [Page 32]

Internet-Draft          MIKEY modes applicability           January 2008


12.  References

12.1.  Normative References

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

12.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.baugher-mmusic-sdp-dh]
              Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for
              Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work
              in progress), February 2006.

   [I-D.ietf-avt-dtls-srtp]
              McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for  Secure
              Real-time Transport Protocol (SRTP)",
              draft-ietf-avt-dtls-srtp-01 (work in progress),
              November 2007.

   [I-D.ietf-msec-mikey-ecc]
              Milne, A., "ECC Algorithms for MIKEY",
              draft-ietf-msec-mikey-ecc-03 (work in progress),
              June 2007.

   [I-D.ietf-sip-media-security-requirements]
              Wing, D., Fries, S., Tschofenig, H., and F. Audet,
              "Requirements and Analysis of Media Security Management
              Protocols", draft-ietf-sip-media-security-requirements-02
              (work in progress), January 2008.

   [I-D.mcgrew-srtp-ekt]
              McGrew, D., "Encrypted Key Transport for Secure RTP",
              draft-mcgrew-srtp-ekt-03 (work in progress), July 2007.

   [I-D.wing-mmusic-sdes-early-media]
              Raymond, R. and D. Wing, "Security Descriptions Extension
              for Early Media", draft-wing-mmusic-sdes-early-media-00
              (work in progress), October 2005.

   [I-D.zimmermann-avt-zrtp]
              Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure



Fries & Ignjatic         Expires August 1, 2008                [Page 33]

Internet-Draft          MIKEY modes applicability           January 2008


              RTP", draft-zimmermann-avt-zrtp-04 (work in progress),
              July 2007.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4442]  Fries, S. and H. Tschofenig, "Bootstrapping Timed
              Efficient Stream Loss-Tolerant Authentication (TESLA)",
              RFC 4442, March 2006.

   [RFC4563]  Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID
              Information Type for the General Extension Payload in
              Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.



Fries & Ignjatic         Expires August 1, 2008                [Page 34]

Internet-Draft          MIKEY modes applicability           January 2008


   [RFC4567]  Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
              Carrara, "Key Management Extensions for Session
              Description Protocol (SDP) and Real Time Streaming
              Protocol (RTSP)", RFC 4567, July 2006.

   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol (SDP) Security Descriptions for Media
              Streams", RFC 4568, July 2006.

   [RFC4597]  Even, R. and N. Ismail, "Conferencing Scenarios",
              RFC 4597, August 2006.

   [RFC4650]  Euchner, M., "HMAC-Authenticated Diffie-Hellman for
              Multimedia Internet KEYing (MIKEY)", RFC 4650,
              September 2006.

   [RFC4738]  Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
              RSA-R: An Additional Mode of Key Distribution in
              Multimedia Internet KEYing (MIKEY)", RFC 4738,
              November 2006.

   [RFC4771]  Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
              Transform Carrying Roll-Over Counter for the Secure Real-
              time Transport Protocol (SRTP)", RFC 4771, January 2007.

   [RFC4909]  Dondeti, L., Castleford, D., and F. Hartung, "Multimedia
              Internet KEYing (MIKEY) General Extension Payload for Open
              Mobile Alliance BCAST LTKM/STKM Transport", RFC 4909,
              June 2007.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

   [RFC5027]  Andreasen, F. and D. Wing, "Security Preconditions for
              Session Description Protocol (SDP) Media Streams",
              RFC 5027, October 2007.

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










Fries & Ignjatic         Expires August 1, 2008                [Page 35]

Internet-Draft          MIKEY modes applicability           January 2008


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 1, 2008                [Page 36]

Internet-Draft          MIKEY modes applicability           January 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Fries & Ignjatic         Expires August 1, 2008                [Page 37]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/