Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)
draft-ietf-mmusic-kmgmt-ext-15

[Ballot discuss]
Section 3 says that key management algorithms must be able to set up
security parameters in at most one request-response message.  I'm
concerned about this requirement because a lot of the general purpose
authentication/key agreement frameworks we've come up with support
arbitrary numbers of round trips.  (examples include EAP/GSSAPI/SASL).
I realize that EAP is not appropriate for this application; I include
it only as an example that even outside the applications space people
find the ability to do multiple round trips in authentication
frameworks desirable.

I accept that generalizing this work to multi-round-trip mechanisms is
going to be somewhat ugly and involved.  I don't think it would be
reasonable to request the WG to undertake that work at this time, but
I'd like to leave the door open for the future.  Looking both at RTSP,
SIP and the OAM, it seems that it would be possible to support
multi-round-trip mechanisms at least for SIP and RTSP, although it
would be complicated.

I propose that the requirement in section 3 be rephrased as:

  * At the current time,  MUST be possible to execute the key management protocol in at
      most one request-response message exchange.  Future relaxation of this requirement is possible but would introduce significant complexity for implementations supporting multi-round-trip mechanisms.


Section 7 provides inconsistent advice on which protocols to offer.

    The use of multiple key management protocols in the same offer may
    open up the possibility of a bidding-down attack, as specified in
    Section 3.1.4. To exclude such possibility, the authentication of the
    protocol identifier list is used. Note though, that the security
    level of the authenticated protocol identifier will be as high (or
    low), as the "weakest" protocol. Therefore, it is discouraged to
    offer protocols with too different security levels.

    Note that it is impossible to assure the authenticity of a declined
    offer, since even if it comes from the true respondent, the fact that
    the answerer declines the offer usually means that he does not
    support the protocol(s) offered, and consequently cannot be expected
    to authenticate the response either. This means that if the Initiator
    is unsure of which protocol(s) the Responder supports, we RECOMMEND
    that the Initiator offers all acceptable protocols in a single offer.

I propose fixing as follows: replace the sentece starting "Therefore,
it is discouraged," with "Therefore, the offer MUST NOT contain
security protocols weaker than permitted by local security policy."


On my first reading, Section 6 seemed incomplete.  As I can best tell,
section 6 of this draft needs to specify all the same sorts of
information as is included in section 5 of the SDP security
descriptions draft.  That's true in the general case, although MIKEY
apparently includes descriptions of the SRTP glue directly; it would
be useful if section 6 made this more clear.

The only integrity protected attribute of the media stream is the set
of key management protocols.  What sort of security considerations are
there associated with other sorts of modifications?  For example, can
I get anything by inserting the key management line from one stream
into another?  Does this depend on any anti-replay properties of the
key management protocol?


There are potentially three authenticated identities involved in a SIP
session using this protocol: the SIP authenticated identity, the
S/MIME authenticated idenity for protecting SIP bodies and the
authenticated identity used by the key management protocol.  This
specification does not really give any advice on how (if at all) these
identities should be related or what identities should be authorized.
I'm happy to discuss this concern and try to figure out if any text is
needed, but I don't understand typical interactions of these
identities well enough to do so.

Review by Lucy Lynch, Gen-ART

This draft is on the right track but has open issues.

The basic mechanics of key based session security seem to be in place here, but the document could really use another pass by a native english speaker - some of the constructions used are either very formal or very convoluted.

(example: "The framework defined in this memo is useful when the session setup is not protected in an end-to- end fashion, but the media streams needs to be end-to-end protected, hence the security parameters (such as keys) are not wanted revealed to nor manipulated by intermediaries.")
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think I understand how this is supposed to work, but I'm not convinced that this process represents a secure exchange.

Along those lines... I think I understand the "at most one request" requirement (see below) but it takes some digging to get at what a "less than one" offer would look like.

3. Usage with SDP, SIP, RTSP, and SAP

    * It MUST be possible to execute the key management protocol in at
      most one request-response message exchange.
    * It MUST be possible from the SIP/SDP and RTSP application, using
      the key management API, to receive key management data, and
      information of whether a message is accepted or not.

I had similar issues with text about re-keying on initial offer.
(Re-keying MUST be handled as a new offer)

In general - the offering of multiple keys seems to introduce a lot of
complexity and some security concerns -

  "Note that the placement of multiple key management offers in a single
    message has the disadvantage that the message expands and the
    computational workload for the offerer will increase drastically.
    Unless the guidelines of Section 3.1.4 are followed, multiple lines
    may open up bidding-down attacks. Note also that the multiple offer
    option has been added to optimize signaling overhead in case the
    Initiator knows some key (e.g. a public key) that the Responder has,
    but is unsure of what protocol the Responder supports. The mechanism
    is not intended to negotiate options within one and the same
    protocol."

but the security section of the document recommends a single multiple key
offer rather than serial attempts to find the best fit key protocol -

    "The use of multiple key management protocols in the same offer may
    open up the possibility of a bidding-down attack, as specified in
    Section 3.1.4. To exclude such possibility, the authentication of the
    protocol identifier list is used. Note though, that the security
    level of the authenticated protocol identifier will be as high (or
    low), as the "weakest" protocol. Therefore, it is discouraged to
    offer protocols with too different security levels.

    Note that it is impossible to assure the authenticity of a declined
    offer, since even if it comes from the true respondent, the fact that
    the answerer declines the offer usually means that he does not
    support the protocol(s) offered, and consequently cannot be expected
    to authenticate the response either. This means that if the Initiator
    is unsure of which protocol(s) the Responder supports, we RECOMMEND
    that the Initiator offers all acceptable protocols in a single offer.
    If not, this opens up the possibility for a "man-in-the-middle"
    (MITM) to affect the outcome of the eventually agreed upon protocol,
    by faking unauthenticated error messages until the Initiator
    eventually offers a protocol "to the liking" of the MITM. This is not
    really a security problem, but rather a mild form of denial of
    service that can be avoided by following the above recommendation.
    Note also that the declined offer could be result of an attacker who
    sits on the path and removes all the key management offers. The
    bidding-down attack prevention, as described above, would not work in
    this case (as the answerer receives no key management attribute)."

This seems like a catch 22 and I'm not sure how to resolve the circular
nature of the problem...

idnits 1.58

tmp/draft-ietf-mmusic-kmgmt-ext-12.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3667/3668 boilerplate...
  * The document seems to lack an RFC 3667 Section 5.1 IPR Disclosure
    Acknowledgement  -- however, there's a paragraph with a matching beginning.
    Boilerplate error?
  * The document seems to lack an RFC 3668 Section 5, para 1 IPR Disclosure
    Acknowledgement.
  * The document seems to lack an RFC 3668 Section 5, para 2 IPR Disclosure
    Acknowledgement.
  * The document seems to lack an RFC 3668 Section 5, para 3 IPR Disclosure
    Invitation.
  * There is 1 instance of lines with non-ascii characters in the document.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

  * The document seems to lack a 1id_guidelines paragraph about 6 months
    document validity -- however, there's a paragraph with a matching beginning.
    Boilerplate error?
  * The document seems to lack a 1id_guidelines paragraph about the list of
    current Internet-Drafts -- however, there's a paragraph with a matching
    beginning. Boilerplate error?

  Miscellaneous warnings:

  - There are 9 instances of lines with hyphenated line breaks in the
    document.
  - Line 836 has weird spacing: '... client  then ...'

    Run idnits with the --verbose option for more detailed information.

[Ballot discuss]
draft-ietf-mmusic-kmgmt-ext-13.txt and draft-ietf-mmusic-sdescriptions-09.txt
  are both approaches to establishing keys with SDP.  However, neither
  document includes an applicability statement.  When it it appropriate
  to use this technique, and when should the other one be used?

  Since this document uses MIKEY, I have asked the chairs of the MSEC WG
  to take a look at it.

[Ballot comment]
I would like to see "KMID" changed to something else, like "KMPID."
  KMID means Keying Material IDentifier to some people, and we are
  naming a key management protocol with this value.