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.