Protocol Action: 'Kerberized Internet Negotiation of Keys (KINK)' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Kerberized Internet Negotiation of Keys (KINK) '
   <draft-ietf-kink-kink-11.txt> as a Proposed Standard

This document is the product of the Kerberized Internet Negotiation of Keys 
Working Group. 

The IESG contact persons are Sam Hartman and Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-11.txt

Technical Summary

This document provides for a Kerberos-based IPsec keying mechanism,
as opposed to IKE. It's of most use to places that already have
a Kerberos infrastructure, and do not want to use IKE for some reason.
The most common reason expressed is the load on a large gateway from
many public-key operations simultaneously, i.e., after a power failure.

Working Group Summary

The major issue is whether or not this protocol is too closely tied
to IKE. The coupling appears to be clean, and there should not be
any major problem using it with IKEv2.  This version is back to the IESG after
alignment with RFC 4301  and RFC 4120.

Protocol Quality

This specification was reviewed for the IESG by Steve Bellovin and Sam
Hartman.  Ken Raeburn provided alignment with RFC 3961 and RFC 4120.  There is
an implementation of an earlier version of this spec and work underway for an
implementation of this version.


Note to RFc Editor:

  In section one replace peer to peer with peer-to-peer, creating a
 hyphenated phrase.

  Add a section 1.1 titled "Conventions used in This Document," with the
  following contents:

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].

  Add a normative reference to RFC 2119 .

Section 4.2.7., para. 1:
OLD:

    The KINK_ENCRYPT payload encapsulates other payloads and is encrypted
    using the encryption algorithm specified by the etype of the session
    key.  This payload MUST be the final payload in the message.  KINK
    encrypt payloads MUST be encrypted before the final KINK checksum is
    applied.

NEW:

    The KINK_ENCRYPT payload encapsulates other KINK payloads and is
    encrypted using the session key and the algorithm specified by its
    etype.  This payload MUST be the final one in the outer payload chain
    of the message.  The KINK_ENCRYPT payload MUST be encrypted before
    the final KINK checksum is applied.


Section 6., para. 1:
OLD:

    All commands, responses, and acknowledgments are bound together by
    the XID field of the message header.  The XID is normally a
    monotonically incrementing field, and is used by the initiator to
    differentiate between outstanding requests to a responder.  The XID
    field does not provide replay protection as that functionality is
    provided by the Kerberos mechanisms.  In addition, commands and
    responses MUST use a cryptographic checksum over the entire message
    if the two peers share a key via a ticket exchange.

NEW:

    All commands, responses, and acknowledgments are bound together by
    the XID field of the message header.  The XID is normally a
    monotonically incrementing field, and is used by the initiator to
    differentiate between outstanding requests to a responder.  The XID
    field does not provide replay protection as that functionality is
    provided by the Kerberos mechanisms.  In addition, commands and
    responses MUST use a cryptographic checksum over the entire message

    In all cases in this section, if a message contains a KINK_AP_REQ or
    KINK_AP_REP payload, other KINK payloads MAY be encapsulated in a
    KINK_ENCRYPT payload.


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce