MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com> Subject: Document Action: 'MIKEY-TICKET: Ticket Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)' to Informational RFC The IESG has approved the following document: - 'MIKEY-TICKET: Ticket Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)' <draft-mattsson-mikey-ticket-05.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-mattsson-mikey-ticket/
Technical Summary This specification describes a MIKEY modes that relies on a centralized key management service. The mode uses a trusted key management service and a ticket concept, similar to that in Kerberos. The new mode also supports features called forking where the exact identity of the other endpoint may not be known at the start of the communication session, which is required by some applications, Working Group Summary This is not the product of an IETF wg, but was presented to the msec wg and reviewed by the chairs. Document Quality There are no existing implementations of the protocol, but the protocol is one option under consideration by 3GPP. Personnel Vincent Roca is the Document Shepherd for this document. Tim Polk is the Responsible Area Director.' RFC Editor Note Please insert the following paragraph at the beginning of Section 12: This specification includes a large number of optional features, which adds complexity to the general case. Protocol designers are strongly encouraged to establish strict profiles defining MIKEY-TICKET options (e.g., exchanges or message fields) that SHOULD or MUST be supported. Such profiles should preclude unexpected consequences from compliant implementations with wildly differing option sets.