Protocol Action: 'GDOI GROUPKEY-PUSH Acknowledgement Message' to Proposed Standard (draft-weis-gdoi-rekey-ack-07.txt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The IESG has approved the following document:
- 'GDOI GROUPKEY-PUSH Acknowledgement Message'
  (draft-weis-gdoi-rekey-ack-07.txt) as Proposed Standard

This document has been reviewed in the IETF but is not the product of an IETF
Working Group.

The IESG contact person is Kathleen Moriarty.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-weis-gdoi-rekey-ack/





Technical Summary

The Group Domain of Interpretation (GDOI) defined in RFC 6407 includes the ability for a Group
Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional
security associations (e.g., to rekey expiring security associations).  GDOI meets the requirement
of the Multicast Security (MSEC) Group Key Management Architecture (RFC 4046), and defines both a
Registration Protocol and Rekey Protocol.

Usually the GCKS does not require a notification that the group member actually received the policy.
However, in some cases it is beneficial for a GCKS to be told by each receiving GM that it received
the rekey message and by implication has reacted to the policy contained within.

This memo adds the ability of a GCKS to request the GM devices to return an acknowledgement of receipt
of its rekey message, and specifies the acknowledgement method.


Working Group Summary

   This document is not the product of a WG there being no working group for which this work is
specifically in scope.  The MSEC WG would have been the logical place for the work, but it closed
several years ago.

Attempts to gather interest in the Security Area and specifically the IPSECME WG were not successful.

That said, there were no responses indicating controversy about or objection to the technical work.

Document Quality

  Two vendor implementations are "in the pipe".  Review was light, but
  the document is reasonable for the simplicity of the work with
  implementations, reducing concerns about the review cycles.  Interest in
  the work may be limited to the two vendors.

  Note on references:
  When RFC 2408 was obsoleted it was assumed that the only interesting user of ISAKMP was IKE and since
  IKEv1 was being replaced by IKEv2 it appeared to make sense to obsolete the base RFCs (RFC 2407, 2408,
  2409).

  At the time, GDOI was still using RFC 2408 and RFC 2409, and no attempt was made to update/obsolete
  the GDOI spec. (Hearsay has it that the security ADs at the time said that this was OK.) . RFC2804 is the 
  correct reference.

Personnel

   Adrian Farrel is Document Shepherd for this document
   Kathleen Moriarty is the Responsible Area Director

   The IANA Expert(s) for the registries
   in this document is Brian Weis.

IANA Note
  A new registry defining values for KEK_ACK_REQUESTED 
  is requested with the Specification Required registry procedure.
  A new registry describing ISAKMP Exchange Types for GDOI is added to
  GDOI Payloads [GDOI-REG] with a registry procedure of Specification
  Required.
  Additions are also requested to the GDOI Payloads [GDOI-REG] registry.




[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux