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.