Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
09 (System) post-migration administrative database adjustment to the No Record position for Cullen Jennings
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2008-05-15
09 (System) IANA Action state changed to No IC from In Progress
2008-05-15
09 (System) IANA Action state changed to In Progress
2008-05-15
09 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-05-15
09 Cindy Morgan IESG state changed to Approved-announcement sent
2008-05-15
09 Cindy Morgan IESG has approved the document
2008-05-15
09 Cindy Morgan Closed "Approve" ballot
2008-05-15
09 Cindy Morgan State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Cindy Morgan
2008-05-15
09 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-05-12
09 Russ Housley
[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 …
[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?
2008-03-31
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-03-31
09 (System) New version available: draft-ietf-msec-mikey-applicability-09.txt
2008-03-11
09 Russ Housley
[Ballot discuss]
Eric Rescorla posted IETF Last Call comments on -07, and he has
  indicated that the changes made to generate -08 do not …
[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.
2008-03-07
09 (System) Removed from agenda for telechat - 2008-03-06
2008-03-06
09 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from Discuss by Cullen Jennings
2008-03-06
09 Cullen Jennings
[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 …
[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.
2008-03-06
09 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2008-03-06
09 Russ Housley
[Ballot discuss]
Eric Rescorla posted IETF Last Call comments on -07, and he has
  indicated that the changes made to generate -08 do not …
[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.
2008-03-06
09 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-03-06
09 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-03-05
09 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-03-05
09 Cullen Jennings
[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 …
[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.
2008-03-05
09 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2008-03-05
09 Sam Hartman
[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 …
[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.
2008-03-05
09 Sam Hartman [Ballot comment]
I think that since there is no protocol draft the discussion of the DH SAML mode should be removed.
2008-03-05
09 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2008-03-05
09 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2008-03-05
09 Jari Arkko
[Ballot comment]
> 6.  Support of limited parties involved

I cannot parse this.

> Negatively to remark is that this proposal does have one significant …
[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...
2008-03-05
09 Jari Arkko
[Ballot comment]
> 6.  Support of limited parties involved

I cannot parse this.

> Negatively to remark is that this proposal does have one significant …
[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...
2008-03-05
09 Jari Arkko
[Ballot comment]
> 6.  Support of limited parties involved

I cannot parse this.

> Negatively to remark is that this proposal does have one significant …
[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.
2008-03-05
09 Jari Arkko [Ballot comment]
> 6.  Support of limited parties involved

I cannot parse this.
2008-03-03
09 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-03-03
09 Magnus Westerlund
[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 …
[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.
2008-02-29
09 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2008-02-29
09 Tim Polk Ballot has been issued by Tim Polk
2008-02-29
09 Tim Polk Created "Approve" ballot
2008-02-27
09 Tim Polk State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk
2008-02-27
09 Tim Polk Placed on agenda for telechat - 2008-03-06 by Tim Polk
2008-02-25
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Kurt Zeilenga.
2008-02-21
08 (System) New version available: draft-ietf-msec-mikey-applicability-08.txt
2008-02-12
09 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2008-02-12
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-01-30
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2008-01-30
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2008-01-29
09 Amy Vezza Last call sent
2008-01-29
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-01-29
09 Tim Polk Last Call was requested by Tim Polk
2008-01-29
09 Tim Polk State Changes to Last Call Requested from AD Evaluation::AD Followup by Tim Polk
2008-01-29
09 (System) Ballot writeup text was added
2008-01-29
09 (System) Last call text was added
2008-01-29
09 (System) Ballot approval text was added
2008-01-29
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-01-29
07 (System) New version available: draft-ietf-msec-mikey-applicability-07.txt
2007-12-03
09 Tim Polk State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Tim Polk
2007-07-23
09 Tim Polk State Changes to AD Evaluation from Publication Requested by Tim Polk
2007-07-23
09 Tim Polk Status date has been changed to 2007-08-01 from
2007-07-22
09 Tim Polk [Note]: 'Document Shepherd is Lakshminath Dondeti, ldondeti@qualcomm.com' added by Tim Polk
2007-07-16
09 Tim Polk proto rec'd July 6 from Lakshminath
2007-07-16
09 Tim Polk Draft Added by Tim Polk in state Publication Requested
2007-07-05
06 (System) New version available: draft-ietf-msec-mikey-applicability-06.txt
2007-06-26
05 (System) New version available: draft-ietf-msec-mikey-applicability-05.txt
2007-05-11
04 (System) New version available: draft-ietf-msec-mikey-applicability-04.txt
2006-12-04
03 (System) New version available: draft-ietf-msec-mikey-applicability-03.txt
2006-08-18
02 (System) New version available: draft-ietf-msec-mikey-applicability-02.txt
2006-06-09
01 (System) New version available: draft-ietf-msec-mikey-applicability-01.txt
2006-05-17
00 (System) New version available: draft-ietf-msec-mikey-applicability-00.txt