MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
RFC 6043

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
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.