Subject: Document Action: 'On the applicability of various MIKEY modes and extensions' to Informational RFC

From: The IESG <[email-masked]>
Date: Thu, 15 May 2008 10:53:32 -0700 (PDT)

The IESG has approved the following document:

- 'On the applicability of various MIKEY modes and extensions '
   <draft-ietf-msec-mikey-applicability-09.txt> as an Informational RFC

This document is the product of the Multicast Security Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-applicability-09.txt

Technical Summary
 
   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
   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 SDP answer, forking,
   and shared key conferencing.
 
Working Group Summary
 
This document was produced by the Multicast Security working group.  The
document achieved consensus within the working group.
 
Protocol Quality
 
Tim Polk reviewed this specification for the IESG.

Note to RFC Editor
 
Please replace the fourth paragraph in Section 3 as follows:

OLD

   The focus of the following subsections lies on the key distribution
   methods as well as the discussion about advantages and disadvantages
   of the different schemes.  Note that the MIKEY key distribution
   schemes rely on loosely synchronized clocks.  If clock
   synchronization is not available, the replay handling of MIKEY
   (cf.[RFC3830]) may not work.  This is due to the fact that MIKEY does
   not use a challenge-response mechanism for replay handling; instead,
   timestamps are used together with message caching.  Thus the required
   synchronization depends on the number of messages that can be cached
   on either side.  Therefore, MIKEY recommendeds to adjust the cache
   size depending on the clock skew in the deployment environment.
   Moreover, RFC3830 recommends the ISO time synchronization protocol
   [ISO_sec_time].  The format applied to the timestamps submitted in
   the MIKEY have to match the NTP format described in [RFC1305].  In
   other cases, such as of a SIP endpoint, clock synchronization by
   deriving time from a trusted outbound proxy may be appropriate.

NEW

   The focus of the following subsections lies on the key distribution
   methods as well as the discussion about advantages and disadvantages
   of the different schemes.  Note that the MIKEY key distribution
   schemes rely on loosely synchronized clocks.  If clock
   synchronization is not available, the replay handling of MIKEY
   (cf.[RFC3830]) may not work.  This is due to the fact that MIKEY does
   not use a challenge-response mechanism for replay handling; instead,
   timestamps are used together with message caching.  Thus the required
   synchronization depends on the number of messages that can be cached
   on either side.  Therefore, MIKEY recommends to adjust the cache
   size depending on the clock skew in the deployment environment.
   Moreover, RFC3830 recommends the ISO time synchronization protocol
   [ISO_sec_time].  If replay handling is not available, an attacker may 
   be able to replay an older message that he eavesdropped earlier,
   leading to different TGKs on both sides. As these are fed to the
   application utilizing MIKEY (e.g., SRTP or TESLA) both sides may rely 
   on different keys and thus may be unable to communicate with each
   other.   The format applied to the timestamps submitted in
   the MIKEY have to match the NTP format described in [RFC1305].  In
   other cases, such as of a SIP endpoint, clock synchronization by
   deriving time from a trusted outbound proxy may be appropriate.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce