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

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.