On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions
RFC 5197

Note: This ballot was opened for revision 09 and is now closed.

(Sam Hartman) Discuss

Discuss (2008-03-05 for -** No value found for 'p.get_dochistory.rev' **)
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.
Comment (2008-03-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think that since there is no protocol draft the discussion of the DH SAML mode should be removed.

(Jari Arkko) Yes

Comment (2008-03-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
> 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...

(Tim Polk) Yes

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Russ Housley) (was Discuss) No Objection

Magnus Westerlund No Objection

Comment (2008-03-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Cullen Jennings) (was Discuss) No Record

Comment (2008-03-06)
No email
send info
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.