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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
