On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions
draft-ietf-msec-mikey-applicability-09

Received changes through RFC Editor sync (changed abstract to '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 (SRTP). MIKEY itself is standardized within RFC 3830 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 arise, 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 an 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 Session Description Protocol (SDP) answer, forking, and shared key conferencing. This memo provides information for the Internet community.')

[Ballot discuss]
I'm concerned about the following Last Call comment from Eric Rescorla:

  The discussion in Section 3 of replay and what happens when clock
  synchronization is not available is inadequate.  The text needs to
  discuss the consequences of replay protection being unavailable.  Does
  it cause you to end up with the same TGK, or is it simply and
  authentication problem?  How does this interact with SRTP?

[Ballot discuss]
Eric Rescorla posted IETF Last Call comments on -07, and he has
  indicated that the changes made to generate -08 do not resolve his
  concerns.  I'm concerned about the following aspects of these Last
  Call comments:

  The discussion in Section 3 of replay and what happens when clock
  synchronization is not available is inadequate.  The text needs to
  discuss the consequences of replay protection being unavailable.  Does
  it cause you to end up with the same TGK, or is it simply and
  authentication problem?  How does this interact with SRTP?

  Eric points out that the discussion of both sides contributing to key
  generation is naive.  The current draft assumes that all schemes in
  which both sides contribute to keying material are roughly the same
  with regard to this aspect of security.  Eric decomposes the space
  into three potentially desirable properties: prevension of replays
  through fresh keys, protection against bad PRNGs, and avoiding weak
  keys.  Please see Eric's Last Call comments, and provide text about
  the security properties the various modes.  I'm not requiring Eric's
  list of properties, but you need state the security analysis that you
  select.

  I agree with Eric that a citation to RFC 3711 is not adequate discussion
  of the two-time pad issue.  The text sounds like reusing SSRCs will have
  dire consequences, creating a two-time pad.  At a minimul there needs to
  be an provide the conditions to avoid the two-time pad.

  In Section 3, describe the manner that the Diffie-Hellman group that
  gets used by all parties in the protocol.

[Ballot comment]
Support Sam and Russ' discuss. I believe the covered all the topics I care about expect on that I have moved from a discuss to a comment after talking to people about the impact of it.

The description of "envelope key" caching in Section 5 could use some elaboration on how the mechanism works. I realize his isn't a complete spec, but it would be nice to describe which MIKEY modes it works in. From reading 3830, I'm not clear on whether it works with DH or just RSA.

[Ballot discuss]
Eric Rescorla posted IETF Last Call comments on -07, and he has
  indicated that the changes made to generate -08 do not resolve his
  concerns.  I am especially concerned that implementors need to know
  the dire consequences of key and counter reuse, as well as the tools
  available to avoid them.

[Ballot discuss]
There has been a lot of discussion about keying modes for
SRTP, so I'm glad to see a document that covers this topic
for MIKEY. For that reason, I think it's really important
to get this right. It looks to me like some of the issues
EKR raises need to be fixed in order to achieve that.

[Ballot discuss]
Based on a secdir review by Eric Rescorla:

Section 3's discussion of replay and what happens when clock
synchronization is not available is inadequate.  The text needs to
discuss the consequences of replay protection being unavailable.  Does
it cause you to end up with the same TGK, or is it simply and
authentication problem?  How does this interact with SRTP?

Eric points out that the discussion of both sides contributing to key
generation is naive.  The current draft assumes that all schemes in
which both sides contribute to keying material are roughly the same
with regard to this aspect of security.  Eric decomposes the space
into three potentially desirable properties: prevension of replays
through fresh keys, protection against bad PRNGs, and avoiding weak
keys.  Please read Eric's actualy write up.  Also, please be clear
about what security properties the various modes actually have.  You
need not use all of Eric's properties, but you should clearly state your security analysis.
The change between 07 and 08 does not seem to actually improve this.

I agree with Eric that a citation to RFC 3711 is not adequate to
discuss the two-time pad issue.  The text sounds like if SSRCs are
reused then MIKEY generates a two-time pad.  That seems really
serious; if it is that bad then the applicability statement needs to state conditions that will avoid SSRC reuse or otherwise address the problem.
Section 3.3 does not discuss how both parties interoperably find out about other DH groups.

[Ballot comment]
> 6.  Support of limited parties involved

I cannot parse this.

> Negatively to remark is that this proposal does have one significant
> security risk.

This too.

> It has to obeyed, that this enables intermediate nodes
> like proxies to actually get the exchanged master key in plain.

Or this.

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

I'm not particularly fond of documenting this idea here. Is this detailed enough for someone to implement it? I hope no one wants to do that...

[Ballot comment]
> 6.  Support of limited parties involved

I cannot parse this.

> Negatively to remark is that this proposal does have one significant
> security risk.

This too.

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

I'm not particularly fond of documenting this idea here. Is this detailed enough for someone to implement it? I hope no one wants to do that...

[Ballot comment]
> 6.  Support of limited parties involved

I cannot parse this.

> Negatively to remark is that this proposal does have one significant
> security risk.

This too.

[Ballot comment]
Section 6.

I think it should be mentioned that RFC 4567 also defines how to transport MIKEY in RTSP which doesn't use SDP for the full exchange, only on the initial leg.