Skip to main content

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



(Tim Polk)

No Objection

(Lisa Dusseault)
(Ross Callon)
(Russ Housley)

No Record

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

Sam Hartman Former IESG member
Discuss [Treat as non-blocking comment] (2008-03-05) Unknown
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.
Jari Arkko Former IESG member
Yes (2008-03-05) Unknown
> 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 Former IESG member
Yes () Unknown

Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

Magnus Westerlund Former IESG member
No Objection
No Objection (2008-03-03) Unknown
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.
Ross Callon Former IESG member
No Objection
No Objection () Unknown

Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

Cullen Jennings Former IESG member
(was Discuss) No Record
No Record (2008-03-06) Unknown
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.