Subject: [MSEC] Re: Review of draft-ietf-msec-mikey-applicability-00

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 14 Jun 2006 01:58:19 -0700

******Reviewing as a contributor and NOT as one of the MSEC co-chairs**

At 06:44 PM 6/13/2006, you wrote:

>MSEC                                                            S. Fries
>Internet-Draft                                                   Siemens
>Expires: November 17, 2006                                   D. Ignjatic
>                                                                  Polycom
>                                                             May 16, 2006
>
>
>        On the applicability of various MIKEY modes and extensions
>                draft-ietf-msec-mikey-applicability-00.txt

><snip>

>Abstract
>
>    Multimedia Internet Keying - MIKEY - is a key management scheme that

s/scheme/protocol/

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

s/schemes/modes/

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

s/schemes/modes

>Fries & Ignjatic        Expires November 17, 2006               [Page 1]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>    but also in terms of payload enhancements.

I am not sure whether payload enhancements is the correct way to say 
this.  Extensions to MIKEY through general extension payloads and 
associated semantics have been introduced.  Please wordsmith that as you like.

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

I would use a different kind of organization: specify the various 
MIKEY modes in one section (so your section 3 and Sections 4.1-4.4 
would go there).  Within each mode (or subsection) you can provide a 
reference to where the mode has been specified.

>      4.5.  New Payload for bootstrapping TESLA  . . . . . . . . . . . 12
>      4.6.  New Key ID information type  . . . . . . . . . . . . . . . 13
>      4.7.  Supporting Integrity Transform carrying the Rollover
>            Counter  . . . . . . . . . . . . . . . . . . . . . . . . . 13

RCC doesn't quite belong in the category that I have in mind and that 
is extensions based on the General Extension payload.  Bootstrapping 
TESLA also does a little bit more than just defining a GenExt 
payload, but would belong in the GenExt category.

My suggestion is to structure the document based on that kind of 
grouping if at all possible.

>      4.8.  OMA BCAST MIKEY General Extension Payload Specification  . 14

>    5.  Selection and interworking of MIKEY modes  . . . . . . . . . . 14
>      5.1.  MIKEY and Early Media  . . . . . . . . . . . . . . . . . . 15
>      5.2.  MIKEY and Forking  . . . . . . . . . . . . . . . . . . . . 16
>      5.3.  MIKEY and Call Transfer  . . . . . . . . . . . . . . . . . 16
>    6.  Transport of MIKEY messages  . . . . . . . . . . . . . . . . . 16
>    7.  Summary of MIKEY related IANA Registrations  . . . . . . . . . 17
>    8.  MIKEY alternatives for SRTP security parameter negotiation . . 17
>    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
>    10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
>    11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
>    12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
>      12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
>      12.2. Informative References . . . . . . . . . . . . . . . . . . 20
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
>    Intellectual Property and Copyright Statements . . . . . . . . . . 23
>
>Fries & Ignjatic        Expires November 17, 2006               [Page 2]
>
>Internet-Draft          MIKEY modes applicability               May 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

Again here, I would talk about various modes of MIKEY and not 
necessarily concentrate on RFC 3830.

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

Please see my comments in the ToC.  I'd group these into the various 
modes of MIKEY.

>    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 [RFC4442]
>    o  The Key ID information type for the general extension payload as
>       defined in [I-D.ietf-msec-newtype-keyid]
>    o  Integrity Transform Carrying Roll-over Counter for SRTP, as
>       defined in [I-D.lehtovirta-srtp-rcc]

Please see my comment on RCC, in the ToC.

>Fries & Ignjatic        Expires November 17, 2006               [Page 3]
>Internet-Draft          MIKEY modes applicability               May 2006
>
>    o  OMA BCAST MIKEY General Extension Payload Specification, as
>       defined in [I-D.dondeti-msec-mikey-genext-oma]
>
>    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
>    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.

This is fine now.  We will delete this paragraph before publication, right?

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

If definitions are taken from 3830, please include them here 
verbatim.  I was going to suggest that they don't need to be 
duplicated, but figured it's ok to include them in this kind of document.

><snip>

>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
>
>
>
>Fries & Ignjatic        Expires November 17, 2006               [Page 5]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>
>    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
>    endpoint clock synchronization by deriving time from a trusted
>    outbound proxy may be appropriate.

The time synchronization aspect probably belongs in a section of its own.

>3.1.  Symmetric key distribution

Why not use the same name as in 3830 for the mode.

><snip>

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

This gives the impression that two keys are being sent.  Please clarify this.

>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 is used to
>    protect the signaling message and 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.
>
>
>
>Fries & Ignjatic        Expires November 17, 2006               [Page 6]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>
>    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 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.

Why is provisioning self-signed certs complex?

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

One issue raised about this is the requirement that the initiator 
know the responder's public key.

Is PFS as desirable as say scalable operation?

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

But, what about

6.5.  Signature payload (SIGN)

RSA/PKCS#1/1.5|     0 | Mandatory, PKCS #1 version 1.5 signature
                                [PSS]

>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

Not sure about the fair, but I guess what you mean is that the two 
parties contribute to the key generation where as in the PSK and RSA 
modes the Initiator provides the key.

>    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
>
>
>
>Fries & Ignjatic        Expires November 17, 2006               [Page 7]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>
>    scalability.  Moreover, it has a limited performance since expensive,
>    non-real time certificate validation has to be done.

What about conferencing support?

>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].  This MIKEY scheme is based on the
>    symmetric key distribution approach described in Section 3.1, but is
>    used with the NULL encryption and the NULL authentication algorithm.
>    It completely relies on the security of the underlying layer, e.g.,
>    provided by TLS This option should be used with caution as it does

Missing a period there.

>    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

Same comment as earlier on the notion of "fair"

>    key agreement, the perfect forward secrecy, and no dependency on a
>
>
>
>Fries & Ignjatic        Expires November 17, 2006               [Page 8]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>
>    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.

Point to point communication and not groups, right?

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

Compare this to the PSK mode.

>4.2.  SAML assisted DH-key agreement

I am not reviewing this part for now.  I would like to see the draft 
before we can include this.  AFAIK, the following is the only 
specification of this mode, other than Bob's presentations.

>    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
>
>
>
>Fries & Ignjatic        Expires November 17, 2006               [Page 9]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>
>    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.
>
>
>    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}, [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.  Thus, the receiver of
>    this message can utilize the received key material to encrypt the
>
>
>
>Fries & Ignjatic        Expires November 17, 2006              [Page 10]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>
>    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
>    and/or required.

I am not sure what low cost means here.

><snip>

>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.
>
>
>
>Fries & Ignjatic        Expires November 17, 2006              [Page 12]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>
>    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
>    described above sent via unicast, multicast or broadcast.

Do you mean MIKEY messages are 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.

I am not sure about the open-ended statement.  What does it mean?

>4.6.  New Key ID information type

I would label it as MBMS extensions to MIKEY or something like that 
(or a functional title).  Let's discuss what's appropriate.  Your 
first paragraph has some ideas for it.

>    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 think the multi-level key management is not new and does not come 
due to the frequent updates to the TEK (or MTK to use the MBMS terminology).

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

That draft also describes Multicast transport of MIKEY messages.

Furthermore, MBMS has different semantics for the T payload.  Do you 
want to capture those here as well?  It would be good to do so.

>4.7.  Supporting Integrity Transform carrying the Rollover Counter
>
>    The document [I-D.lehtovirta-srtp-rcc] 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 will 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
>
>
>
>Fries & Ignjatic        Expires November 17, 2006              [Page 13]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>
>    certain MIKEY payloads need to be made.  These MIKEY new definition
>    comprise the integrity transform s and new integrity transform
>    parameter.  Moreover, the document specifies integrity parameter, to
>    enable the usage of different integrity transforms for SRTP and
>    SRTCP.

Not sure about this description.  I might find time to send you an 
alternative description later.

>4.8.  OMA BCAST MIKEY General Extension Payload Specification
>
>    The document [I-D.dondeti-msec-mikey-genext-oma] 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 the
>    payloads for both, short term and long term key messages as part of
>    the general extension payload.  Note, that only a parameter
>    description is included, but no key information.

Actually the intent is to use to ask for an IANA registration for an 
OMA BCAST payload to be defined in OMA.  We won't be defining any payloads.

>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
>    one of the DH modes exclusively.

Not sure I fully understand the above.  I sort of see what you are 
trying to say, but not sure.  Perhaps you can explain how each mode 
can be used (a list might be better?).  And also define which might 
bootstrap another, etc.

I look at it as follows:

1. If the Initiator has a PSK with the Responder, it uses the PSK mode.  <stop>
1a. 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.
2. If the Initiator has the RSA key of the Responder, it uses the RSA 
mode to establish the PSK or TGK or both (?).  If the PSK is 
established, then Option 1 would be used in the future.  <stop>
3. The Initiator uses RSA-R.

and so on.

>    Forward MIKEY modes like public key or shared key mode when used in

Are there other "forward" modes?  How about a different name or 
definition of the modes where the key is supplied by the Initiator?

>    SIP/SDP may lead to complications in some calls scenarios, for
>    example forking scenarios key derivation material gets distributed to
>    multiple parties.

This may need to analyzed per mode.  Can some modes handle forking 
better than the others?

>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
>
>
>
>Fries & Ignjatic        Expires November 17, 2006              [Page 14]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>
>    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).

This is repetition though!

>   <snip>

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

Even in DH modes, there are issues: the initiator would have to 
process multiple DH responses (which is discussed below).

>    If forking is combined with early media the situation gets
>    aggravated.  If MIKEY modes requiring 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.
>
>5.3.  MIKEY and Call Transfer
>
>    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.

Is this a placeholder?

>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.
>
>Fries & Ignjatic        Expires November 17, 2006              [Page 16]
>
>Internet-Draft          MIKEY modes applicability               May 2006
>
>    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
>    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.

I think there was an allusion to MIKEY transport via 
multicast/broadcast earlier in the document.  3GPP specifies such 
transport; perhaps that can be included here?

>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.  MIKEY alternatives for SRTP security parameter negotiation

Perhaps this is done by other documents and shouldn't be in this document?

Finally, thanks again for your work on this.  I have high hopes for 
this document, and so I am being critical in my review.  Please 
continue your good work and please feel free to ask for help.

regards,
Lakshminath

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec