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@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
