doc: Add RFC documents

1 files changed, 2243 insertions, 0 deletions

diff --git a/doc/rfc/rfc4430.txt b/doc/rfc/rfc4430.txt
new file mode 100644
index 0000000..e9da256
--- /dev/null
+++ b/doc/rfc/rfc4430.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Network Working Group                                          S. Sakane
+Request for Comments: 4430                                     K. Kamada
+Category: Standards Track                        Yokogawa Electric Corp.
+                                                               M. Thomas
+                                                             J. Vilhuber
+                                                           Cisco Systems
+                                                              March 2006
+
+
+             Kerberized Internet Negotiation of Keys (KINK)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the Kerberized Internet Negotiation of Keys
+   (KINK) protocol.  KINK defines a low-latency, computationally
+   inexpensive, easily managed, and cryptographically sound protocol to
+   establish and maintain security associations using the Kerberos
+   authentication system.  KINK reuses the Quick Mode payloads of the
+   Internet Key Exchange (IKE), which should lead to substantial reuse
+   of existing IKE implementations.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................3
+   2. Protocol Overview ...............................................4
+   3. Message Flows ...................................................4
+      3.1. GETTGT Message Flow ........................................5
+      3.2. CREATE Message Flow ........................................6
+           3.2.1. CREATE Key Derivation Considerations ................7
+      3.3. DELETE Message Flow ........................................8
+      3.4. STATUS Message Flow ........................................9
+      3.5. Reporting Errors ...........................................9
+      3.6. Rekeying Security Associations ............................10
+      3.7. Dead Peer Detection .......................................10
+           3.7.1. Coping with Dead User-to-User Peers ................12
+
+
+
+Sakane, et al.              Standards Track                     [Page 1]
+
+RFC 4430                          KINK                        March 2006
+
+
+   4. KINK Message Format ............................................13
+      4.1. KINK Alignment Rules ......................................15
+      4.2. KINK Payloads .............................................16
+           4.2.1. KINK_AP_REQ Payload ................................17
+           4.2.2. KINK_AP_REP Payload ................................18
+           4.2.3. KINK_KRB_ERROR Payload .............................19
+           4.2.4. KINK_TGT_REQ Payload ...............................20
+           4.2.5. KINK_TGT_REP Payload ...............................21
+           4.2.6. KINK_ISAKMP Payload ................................21
+           4.2.7. KINK_ENCRYPT Payload ...............................22
+           4.2.8. KINK_ERROR Payload .................................23
+   5. Differences from IKE Quick Mode ................................25
+      5.1. Security Association Payloads .............................26
+      5.2. Proposal and Transform Payloads ...........................26
+      5.3. Identification Payloads ...................................26
+      5.4. Nonce Payloads ............................................26
+      5.5. Notify Payloads ...........................................27
+      5.6. Delete Payloads ...........................................28
+      5.7. KE Payloads ...............................................28
+   6. Message Construction and Constraints for IPsec DOI .............28
+      6.1. REPLY Message .............................................28
+      6.2. ACK Message ...............................................28
+      6.3. CREATE Message ............................................29
+      6.4. DELETE Message ............................................30
+      6.5. STATUS Message ............................................31
+      6.6. GETTGT Message ............................................32
+   7. ISAKMP Key Derivation ..........................................32
+   8. Key Usage Numbers for Kerberos Key Derivation ..................33
+   9. Transport Considerations .......................................33
+   10. Security Considerations .......................................34
+   11. IANA Considerations ...........................................35
+   12. Forward Compatibility Considerations ..........................35
+      12.1. New Versions of Quick Mode ...............................36
+      12.2. New DOI ..................................................36
+   13. Related Work ..................................................36
+   14. Acknowledgements ..............................................37
+   15. References ....................................................37
+      15.1. Normative References .....................................37
+      15.2. Informative References ...................................38
+
+
+
+
+
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                     [Page 2]
+
+RFC 4430                          KINK                        March 2006
+
+
+1.  Introduction
+
+   KINK is designed to provide a secure, scalable mechanism for
+   establishing keys between communicating entities within a centrally
+   managed environment in which it is important to maintain consistent
+   security policy.  The security goals of KINK are to provide privacy,
+   authentication, and replay protection of key management messages and
+   to avoid denial of service vulnerabilities whenever possible.  The
+   performance goals of the protocol are to have a low computational
+   cost, low latency, and a small footprint.  It is also to avoid or
+   minimize the use of public key operations.  In particular, the
+   protocol provides the capability to establish IPsec security
+   associations (SAs) in two messages with minimal computational effort.
+   These requirements are described in RFC 3129 [REQ4KINK].
+
+   Kerberos [KERBEROS] provides an efficient authentication mechanism
+   for clients and servers using a trusted third-party model.  Kerberos
+   also provides a mechanism for cross-realm authentication natively.  A
+   client obtains a ticket from an online authentication server, the Key
+   Distribution Center (KDC).  The ticket is then used to construct a
+   credential for authenticating the client to the server.  As a result
+   of this authentication operation, the server will also share a secret
+   key with the client.  KINK uses this property as the basis of
+   distributing keys for IPsec.
+
+   The central key management provided by Kerberos is efficient because
+   it limits computational cost and limits complexity versus IKE's
+   necessity of using public key cryptography [IKE].  Initial
+   authentication to the KDC may be performed using either symmetric
+   keys, or asymmetric keys using the Public Key Cryptography for
+   Initial Authentication in Kerberos [PKINIT]; however, subsequent
+   requests for tickets as well as authenticated exchanges between the
+   client and servers always utilize symmetric cryptography.  Therefore,
+   public key operations (if any) are limited and are amortized over the
+   lifetime of the credentials acquired in the initial authentication
+   operation to the KDC.  For example, a client may use a single public
+   key exchange with the KDC to efficiently establish multiple SAs with
+   many other servers in the realm of the KDC.  Kerberos also scales
+   better than direct peer-to-peer keying when symmetric keys are used.
+   The reason is that since the keys are stored in the KDC, the number
+   of principal keys is O(n+m) rather than O(n*m), where "n" is the
+   number of clients and "m" is the number of servers.
+
+1.1.  Conventions Used in This Document
+
+   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].
+
+
+
+Sakane, et al.              Standards Track                     [Page 3]
+
+RFC 4430                          KINK                        March 2006
+
+
+   It is assumed that the readers are familiar with the terms and
+   concepts described in Kerberos Version 5 [KERBEROS], IPsec [IPSEC],
+   and IKE [IKE].
+
+2.  Protocol Overview
+
+   KINK is a command/response protocol that can create, delete, and
+   maintain IPsec SAs.  Each command or response contains a common
+   header along with a set of type-length-value payloads.  The type of a
+   command or a response constrains the payloads sent in the messages of
+   the exchange.  KINK itself is a stateless protocol in that each
+   command or response does not require storage of hard state for KINK.
+   This is in contrast to IKE, which uses Main Mode to first establish
+   an Internet Security Association and Key Management Protocol (ISAKMP)
+   SA followed by subsequent Quick Mode exchanges.
+
+   KINK uses Kerberos mechanisms to provide mutual authentication and
+   replay protection.  For establishing SAs, KINK provides
+   confidentiality for the payloads that follow the Kerberos AP-REQ
+   payload.  The design of KINK mitigates denial of service attacks by
+   requiring authenticated exchanges before the use of any public key
+   operations and the installation of any state.  KINK also provides a
+   means of using Kerberos User-to-User mechanisms when there is not a
+   key shared between the server and the KDC.  This is typically, but
+   not limited to, the case with IPsec peers using PKINIT for initial
+   authentication.
+
+   KINK directly reuses Quick Mode payloads defined in section 5.5 of
+   [IKE], with some minor changes and omissions.  In most cases, KINK
+   exchanges are a single command and its response.  An optional third
+   message is required when creating SAs, only if the responder rejects
+   the first proposal from the initiator or wants to contribute the
+   keying materials.  KINK also provides rekeying and dead peer
+   detection.
+
+3.  Message Flows
+
+   All KINK message flows follow the same pattern between the two peers:
+   a command, a response, and an optional acknowledgement in a CREATE
+   flow.  A command is a GETTGT, CREATE, DELETE, or STATUS message; a
+   response is a REPLY message; and an acknowledgement is an ACK
+   message.
+
+   KINK uses Kerberos as the authentication mechanism; therefore, a KINK
+   host needs to get a service ticket for each peer before actual key
+   negotiations.  This is basically a pure Kerberos exchange and the
+   actual KDC traffic here is for illustrative purposes only.  In
+   practice, when a principal obtains various tickets is a subject of
+
+
+
+Sakane, et al.              Standards Track                     [Page 4]
+
+RFC 4430                          KINK                        March 2006
+
+
+   Kerberos and local policy consideration.  As an exception, the GETTGT
+   message flow of KINK (described in section 3.1) is used when a User-
+   to-User authentication is required.  In this flow, we assume that
+   both A and B have ticket-granting tickets (TGTs) from their KDCs.
+
+   After a service ticket is obtained, KINK uses the CREATE message flow
+   (section 3.2), DELETE message flow (section 3.3), and STATUS message
+   flow (section 3.4) to manage SAs.  In these flows, we assume that A
+   has a service ticket for B.
+
+3.1.  GETTGT Message Flow
+
+   This flow is used to retrieve a TGT from the remote peer in User-to-
+   User authentication mode.
+
+   If the initiator determines that it will not be able to get a normal
+   (non-User-to-User) service ticket for the responder, it can try a
+   User-to-User authentication.  In this case, it first fetches a TGT
+   from the responder in order to get a User-to-User service ticket:
+
+       A                        B                       KDC
+     ------                  ------                     ---
+    1  GETTGT+KINK_TGT_REQ------>
+
+    2  <-------REPLY+KINK_TGT_REP
+
+    3  TGS-REQ+TGT(B)------------------------------------>
+
+    4  <-------------------------------------------TGS-REP
+
+                       Figure 1: GETTGT Message Flow
+
+   The initiator MAY support the following events as triggers to go to
+   the User-to-User path.  Note that the two errors described below will
+   not be authenticated, and how to act on them depends on the policy.
+
+        o    The local policy says that the responder requires a User-
+             to-User authentication.
+
+        o    A KRB_AP_ERR_USER_TO_USER_REQUIRED error is returned from
+             the responder.
+
+        o    A KDC_ERR_MUST_USE_USER2USER error is returned from the
+             KDC.
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                     [Page 5]
+
+RFC 4430                          KINK                        March 2006
+
+
+3.2.  CREATE Message Flow
+
+   This flow creates SAs.  The CREATE command takes an "optimistic"
+   approach, where SAs are initially created on the expectation that the
+   responder will choose the initial proposed payload.  The optimistic
+   proposal is placed in the first transform payload(s) of the first
+   proposal.  The initiator MUST check to see if the optimistic proposal
+   was selected by comparing all transforms and attributes, which MUST
+   be identical to those in the initiator's optimistic proposal with the
+   exceptions of LIFE_KILOBYTES and LIFE_SECONDS.  Each of these
+   attributes MAY be set to a lower value by the responder and still
+   expect optimistic keying, but MUST NOT be set to a higher value that
+   MUST generate a NO-PROPOSAL-CHOSEN error.  The initiator MUST use the
+   shorter lifetime.
+
+   When a CREATE command contains an existing Security Parameter Index
+   (SPI), the responder MUST reject it and SHOULD return an ISAKMP
+   notification with INVALID-SPI.
+
+   When a key exchange (KE) payload is sent from the initiator but the
+   responder does not support it, the responder MUST reject it with an
+   ISAKMP notification of INVALID-PAYLOAD-TYPE containing a KE payload
+   type as its notification data.  When the initiator receives this
+   error, it MAY retry without a KE payload (as another transaction) if
+   its policy allows that.
+
+       A                        B                       KDC
+     ------                  ------                     ---
+
+       A creates an optimistic inbound SA (B->A) unless using a KE.
+
+    1  CREATE+ISAKMP------------>
+
+       B creates an inbound SA (A->B).
+       B creates an outbound SA (B->A) if optimistic and not using a KE.
+
+    2  <-------------REPLY+ISAKMP
+
+       A creates an outbound SA (A->B).
+       A replaces an inbound SA (B->A) if non-optimistic.
+       A creates an inbound SA (B->A) if using a KE.
+
+    3 [ ACK--------------------->                            ]
+
+      [ B creates an outbound SA (B->A).                     ]
+
+                       Figure 2: CREATE Message Flow
+
+
+
+
+Sakane, et al.              Standards Track                     [Page 6]
+
+RFC 4430                          KINK                        March 2006
+
+
+   Creating SAs has two modes:  2-way handshake and 3-way handshake.
+   The initiator usually begins a negotiation expecting a 2-way
+   handshake.  When the optimistic proposal is not chosen by the
+   responder, the negotiation is switched to a 3-way handshake.  When
+   and only when the initiator uses a KE payload, 3-way handshake is
+   expected from the beginning.
+
+   A 2-way handshake is performed in the following steps:
+
+      1) The host A creates an inbound SA (B->A) in its SA database
+         using the optimistic proposal in the ISAKMP SA proposal.  It is
+         then ready to receive any messages from B.
+      2) A then sends the CREATE message to B.
+      3) If B agrees to A's optimistic proposal, B creates an inbound SA
+         (A->B) and an outbound SA (B->A) in its database.  If B does
+         not choose the first proposal or wants to add a Nonce payload,
+         switch to step 3 of the 3-way handshake described below.
+      4) B then sends a REPLY to A without a Nonce payload and without
+         requesting an ACK.
+      5) Upon receipt of the REPLY, A creates an outbound SA (A->B).
+
+   A 3-way handshake is performed in the following steps:
+
+      1) The host A sends the CREATE message to B without creating any
+         SA.
+      2) B chooses one proposal according to its policy.
+      3) B creates an inbound SA (A->B) and sends the actual choice in
+         the REPLY.  It SHOULD send the optional Nonce payload (as it
+         does not increase message count and generally increases entropy
+         sources) and MUST request that the REPLY be acknowledged.
+      4) Upon receipt of the REPLY, A creates the inbound SA (B->A) (or
+         modifies it as necessary, if switched from 2-way), and the
+         outbound SA (A->B).
+      5) A now sends the ACK message.
+      6) Upon receipt of the ACK, B installs the final outbound SA
+         (B->A).
+
+   If B does not choose the first proposal, adds a nonce, or accepts the
+   KE exchange, then it MUST request an ACK (i.e., set the ACKREQ bit)
+   so that it can install the final outbound SA.  The initiator MUST
+   always generate an ACK if the ACKREQ bit is set in the KINK header,
+   even if it believes that the responder was in error.
+
+3.2.1.  CREATE Key Derivation Considerations
+
+   The CREATE command's optimistic approach allows an SA to be created
+   in two messages rather than three.  The implication of a two-message
+   exchange is that B will not contribute to the key since A must set up
+
+
+
+Sakane, et al.              Standards Track                     [Page 7]
+
+RFC 4430                          KINK                        March 2006
+
+
+   the inbound SA before it receives any additional keying material from
+   B.  This may be suspect under normal circumstances; however, KINK
+   takes advantage of the fact that the KDC provides a reliable source
+   of randomness which is used in key derivation.  In many cases, this
+   will provide an adequate session key so that B will not require an
+   acknowledgement.  Since B is always at liberty to contribute to the
+   keying material, this is strictly a trade-off between the key
+   strength versus the number of messages, which KINK implementations
+   may decide as a matter of policy.
+
+3.3.  DELETE Message Flow
+
+   The DELETE command deletes existing SAs.  The domain of
+   interpretation (DOI)-specific payloads describe the actual SA to be
+   deleted.  For the IPsec DOI, those payloads will include an ISAKMP
+   payload containing the list of the SPIs to be deleted.
+
+       A                        B                       KDC
+     ------                  ------                     ---
+
+       A deletes outbound SA to B.
+
+    1  DELETE+ISAKMP------------>
+
+       B deletes inbound and outbound SA to A.
+
+    2  <-------------REPLY+ISAKMP
+
+       A deletes inbound SA to B.
+
+                       Figure 3: DELETE Message Flow
+
+   The DELETE command takes a "pessimistic" approach, which does not
+   delete inbound SAs until it receives acknowledgement that the other
+   host has received the DELETE.  The exception to the pessimistic
+   approach is if the initiator wants to immediately cease all activity
+   on an inbound SA.  In this case, it MAY delete the inbound SA as well
+   in step 1, above.
+
+   The ISAKMP payload contains ISAKMP Delete payload(s) that indicate
+   the inbound SA(s) for the initiator of this flow.  KINK does not
+   allow half-open SAs; thus, when the responder receives a DELETE
+   command, it MUST delete SAs of both directions, and MUST reply with
+   ISAKMP Delete payload(s) that indicate the inbound SA(s) for the
+   responder of this flow.  If the responder cannot find an appropriate
+   SPI to be deleted, it MUST return an ISAKMP notification with
+   INVALID_SPI, which also serves to inform the initiator that it can
+   delete the inbound SA.
+
+
+
+Sakane, et al.              Standards Track                     [Page 8]
+
+RFC 4430                          KINK                        March 2006
+
+
+   A race condition with the DELETE flow exists.  Due to network
+   reordering, etc., packets in flight while the DELETE operation is
+   taking place may arrive after the diagrams above, which recommend
+   deleting the inbound SA.  A KINK implementation SHOULD implement a
+   grace timer that SHOULD be set to a period of at least two times the
+   average round-trip time, or to a configurable value.  A KINK
+   implementation MAY choose to set the grace period to zero at
+   appropriate times to delete an SA ungracefully.  The behavior
+   described here is referred from the behavior of the TCP [RFC793]
+   flags FIN and RST.
+
+3.4.  STATUS Message Flow
+
+   This flow is used to send any information to a peer or to elicit any
+   information from a peer.  An initiator may send a STATUS command to
+   the responder at any time, optionally with DOI-specific ISAKMP
+   payloads.  In the case of the IPsec DOI, these are generally in the
+   form of ISAKMP Notification payloads.  A STATUS command is also used
+   as a means of dead peer detection described in section 3.7.
+
+       A                        B                       KDC
+     ------                  ------                     ---
+
+    1  STATUS[+ISAKMP]---------->
+
+    2  <-----------REPLY[+ISAKMP]
+
+                       Figure 4: STATUS Message Flow
+
+3.5.  Reporting Errors
+
+   When the responder detects an error in a received command, it can
+   send a DOI-specific payload to indicate the error in a REPLY message.
+   There are three types of payloads that can indicate errors:
+   KINK_KRB_ERROR payloads for Kerberos errors, KINK_ERROR payloads for
+   KINK errors, and KINK_ISAKMP payloads for ISAKMP errors.  Details are
+   described in sections 4.2.3, 4.2.8, and 4.2.6, respectively.
+
+   If the initiator detects an error in a received reply, there is no
+   means to report it back to the responder.  The initiator SHOULD log
+   the event and MAY take a remedial action by reinitiating the initial
+   command.
+
+   If the server clock and the client clock are off by more than the
+   policy-determined clock skew limit (usually 5 minutes), the server
+   MUST return a KRB_AP_ERR_SKEW.  The optional client's time in the
+   KRB-ERROR SHOULD be filled out.  If the server protects the error by
+   adding the Cksum field and returning the correct client's time, the
+
+
+
+Sakane, et al.              Standards Track                     [Page 9]
+
+RFC 4430                          KINK                        March 2006
+
+
+   client SHOULD compute the difference (in seconds) between the two
+   clocks based upon the client and server time contained in the
+   KRB-ERROR message.  The client SHOULD store this clock difference and
+   use it to adjust its clock in subsequent messages.  If the error is
+   not protected, the client MUST NOT use the difference to adjust
+   subsequent messages, because doing so would allow an attacker to
+   construct authenticators that can be used to mount replay attacks.
+
+3.6.  Rekeying Security Associations
+
+   KINK expects the initiator of an SA to be responsible for rekeying
+   the SA for two reasons.  The first reason is to prevent needless
+   duplication of SAs as the result of collisions due to an initiator
+   and responder both trying to renew an existing SA.  The second reason
+   is due to the client/server nature of Kerberos exchanges, which
+   expects the client to get and maintain tickets.  While KINK expects
+   that a KINK host is able to get and maintain tickets, in practice it
+   is often advantageous for servers to wait for clients to initiate
+   sessions so that they do not need to maintain a large ticket cache.
+
+   There are no special semantics for rekeying SAs in KINK.  That is, in
+   order to rekey an existing SA, the initiator must CREATE a new SA
+   followed by either deleting the old SA with the DELETE flow or
+   letting it time out.  When identical flow selectors are available on
+   different SAs, KINK implementations SHOULD choose the SA most
+   recently created.  It should be noted that KINK avoids most of the
+   problems of [IKE] rekeying by having a reliable delete mechanism.
+
+   Normally, a KINK implementation that rekeys existing SAs will try to
+   rekey the SA ahead of an SA termination, which may include the hard
+   lifetime in time/bytecount or the overflow of the sequence number
+   counter.  We call this time "soft lifetime".  The soft lifetime MUST
+   be randomized to avoid synchronization with similar implementations.
+   In the case of the lifetime in time, one reasonable approach to
+   determine the soft lifetime is picking a random time between T-rekey
+   and T-retrans and subtracting it from the hard lifetime.  Here,
+   T-rekey is the reasonable maximum rekeying margin, and T-retrans is
+   the amount of time it would take to go through a full retransmission
+   cycle.  T-rekey SHOULD be at least twice as high as T-retrans.
+
+3.7.  Dead Peer Detection
+
+   In order to determine that a KINK peer has lost its security database
+   information, KINK peers MUST record the current epoch for which they
+   have valid SA information for a peer and reflect that epoch in each
+   AP-REQ and AP-REP message.  When a KINK peer creates state for a
+   given SA, it MUST also record the principal's epoch.  If it discovers
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 10]
+
+RFC 4430                          KINK                        March 2006
+
+
+   on a subsequent message that the principal's epoch has changed, it
+   MUST consider all SAs created by that principal as invalid, and take
+   some action such as tearing those SAs down.
+
+   While a KINK peer SHOULD use feedback from routing (in the form of
+   ICMP messages) as a trigger to check whether or not the peer is still
+   alive, a KINK peer MUST NOT conclude the peer is dead simply based on
+   unprotected routing information (said ICMP messages).
+
+   If there is suspicion that a peer may be dead (based on any
+   information available to the KINK peer, including lack of IPsec
+   traffic, etc.), the KINK STATUS message SHOULD be used to coerce an
+   acknowledgement out of the peer.  Since nothing is negotiated about
+   dead peer detection in KINK, each peer can decide its own metric for
+   "suspicion" and also what timeouts to use before declaring a peer
+   dead due to lack of response to the STATUS message.  This is
+   desirable, and does not break interoperability.
+
+   The STATUS message has a twofold effect.  First, it elicits a
+   cryptographically secured (and replay-protected) response from the
+   peer, which tells us whether or not the peer is reachable/alive.
+   Second, it carries the epoch number of the peer, so we know whether
+   or not the peer has rebooted and lost all state.  This is crucial to
+   the KINK protocol: In IKE, if a peer reboots, we lose all
+   cryptographic context, and no cryptographically secure communication
+   is possible without renegotiating keys.  In KINK, due to Kerberos
+   tickets, we can communicate securely with a peer, even if the peer
+   rebooted, as the shared cryptographic key used is carried in the
+   Kerberos ticket.  Thus, active cryptographic communication is not an
+   indication that the peer has not rebooted and lost all state, and the
+   epoch is needed.
+
+   Assume a Peer A sending a STATUS and a peer B sending the REPLY (see
+   section 3.4).  Peer B MAY assume that the sender is alive, and the
+   epoch in the STATUS message will indicate whether or not the peer A
+   has lost state.  Peer B MUST acknowledge the STATUS message with a
+   REPLY message, as described in section 3.4.
+
+   The REPLY message will indicate to peer A that the peer is alive, and
+   the epoch in the REPLY will indicate whether peer B has lost its
+   state or not.  If peer A does not receive a REPLY message from peer B
+   in a suitable timeout, peer A MAY send another STATUS message.  It is
+   up to peer A to decide how aggressively to declare peer B dead.  The
+   level of aggressiveness may depend on many factors such as rapid fail
+   over versus number of messages sent by nodes with large numbers of
+   SAs.
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 11]
+
+RFC 4430                          KINK                        March 2006
+
+
+   Note that peer B MUST NOT make any inferences about a lack of STATUS
+   message from peer A.  Peer B MAY use a STATUS message from peer A as
+   an indication of A's aliveness, but peer B MUST NOT expect another
+   STATUS message at any time (i.e., dead peer detection is not periodic
+   keepalives).
+
+   Strategies for sending STATUS messages are the following: Peer A may
+   decide to send a STATUS message only after a prolonged period where
+   no traffic was sent in either direction over the IPsec SAs with the
+   peer.  Once there is traffic, peer A may want to know if the traffic
+   is going into a black hole, and send a STATUS message.
+   Alternatively, peer A may use an idle timer to detect lack of traffic
+   with the peer, and send STATUS messages in the quiet phase to make
+   sure the peer is still alive for when traffic needs to finally be
+   sent.
+
+3.7.1.  Coping with Dead User-to-User Peers
+
+   When an initiator uses a User-to-User ticket and a responder has lost
+   its previous TGT, the usual dead peer detection (DPD) mechanism does
+   not work, because the responder cannot decrypt the ticket with its
+   new TGT.  In this case, the following actions are taken.
+
+     o    When the responder receives a KINK command with a User-to-User
+          ticket that cannot be decrypted with its TGT, it returns a
+          REPLY with a KINK_TGT_REP payload containing the TGT.
+
+     o    When the initiator receives a KINK_TGT_REP, it retrieves a new
+          service ticket with the TGT and retries the command.
+
+   This does not directly define a method to detect a dead User-to-User
+   peer, but to recover from the situation that the responder does not
+   have an appropriate TGT to decrypt a service ticket sent from the
+   initiator.  After recovery, they can exchange their epochs, and usual
+   DPD mechanism will detect a dead peer if it really has been dead.
+
+   The initiator MUST NOT think the peer has been dead on the receipt of
+   a KINK_TGT_REP because of two reasons.  One is that the message is
+   not authenticated, and the other is that losing a TGT does not
+   necessarily mean losing the SA database information.  The initiator
+   SHOULD NOT forget the previous service ticket until the new one is
+   successfully obtained in order to reduce the cost when a forged
+   KINK_TGT_REP is received.
+
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 12]
+
+RFC 4430                          KINK                        March 2006
+
+
+4.  KINK Message Format
+
+   All values in KINK are formatted in network byte order (most
+   significant byte first).  The RESERVED fields MUST be set to zero (0)
+   when a packet is sent.  The receiver MUST ignore these fields.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Type        | MjVer |RESRVED|            Length             |
+    +---------------+---------------+---------------+---------------+
+    |                 Domain of Interpretation (DOI)                |
+    +-------------------------------+-------------------------------+
+    |                      Transaction ID (XID)                     |
+    +---------------+-+-------------+-------------------------------+
+    |  NextPayload  |A|  RESERVED2  |           CksumLen            |
+    +---------------+-+-------------+-------------------------------+
+    |                                                               |
+    ~                      A series of payloads                     ~
+    |                                                               |
+    +-------------------------------+-------------------------------+
+    |                                                               |
+    ~                       Cksum (variable)                        ~
+    |                                                               |
+    +-------------------------------+-------------------------------+
+
+                    Figure 5:  Format of a KINK Message
+
+   Fields:
+
+     o    Type (1 octet) -- The type of this message.
+
+              Type              Value
+              -----             -----
+              RESERVED            0
+              CREATE              1
+              DELETE              2
+              REPLY               3
+              GETTGT              4
+              ACK                 5
+              STATUS              6
+              RESERVED TO IANA    7 - 127
+              Private Use       128 - 255
+
+     o    MjVer (4 bits) -- Major protocol version number.  This MUST be
+          set to 1.
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 13]
+
+RFC 4430                          KINK                        March 2006
+
+
+     o    RESRVED (4 bits) -- Reserved and MUST be zero when sent, MUST
+          be ignored when received.
+
+     o    Length (2 octets) -- Length of the message in octets.  It is
+          not forbidden in KINK that there are unnecessary data after
+          the message, but the Length field MUST represent the actual
+          length of the message.
+
+     o    DOI (4 octets) -- The domain of interpretation.  All DOIs must
+          be registered with the IANA in the ISAKMP Domain of
+          Interpretation section of the isakmp-registry [ISAKMP-REG].
+          The IANA Assigned Number for the Internet IP Security DOI
+          [IPDOI] is one (1).  This field defines the context of all
+          sub-payloads in this message.  If sub-payloads have a DOI
+          field (e.g., Security Association Payload), then the DOI in
+          that sub-payload MUST be checked against the DOI in this
+          header, and the values MUST be the same.
+
+     o    XID (4 octets) -- The transaction ID.  A KINK transaction is
+          bound together by a transaction ID, which is created by the
+          command initiator and replicated in subsequent messages in the
+          transaction.  A transaction is defined as a command, a reply,
+          and an optional acknowledgement.  Transaction IDs are used by
+          the initiator to discriminate between multiple outstanding
+          requests to a responder.  It is not used for replay protection
+          because that functionality is provided by Kerberos.  The value
+          of XID is chosen by the initiator and MUST be unique with all
+          outstanding transactions.  XIDs MAY be constructed by using a
+          monotonic counter or random number generator.
+
+     o    NextPayload (1 octet) -- Indicates the type of the first
+          payload after the message header.
+
+     o    A, or ACKREQ (1 bit) -- ACK Request.  Set to one if the
+          responder requires an explicit acknowledgement that a REPLY
+          was received.  An initiator MUST NOT set this flag, nor should
+          a responder except for a REPLY to a CREATE when the optimistic
+          proposal is chosen.
+
+     o    RESERVED2 (7 bits) -- Reserved and MUST be zero on send, MUST
+          be ignored by a receiver.
+
+     o    CksumLen (2 octets) -- CksumLen is the length in octets of the
+          cryptographic checksum of the message.  A CksumLen of zero
+          implies that the message is unauthenticated.
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 14]
+
+RFC 4430                          KINK                        March 2006
+
+
+     o    Cksum (variable) -- Kerberos keyed checksum over the entire
+          message excluding the Cksum field itself.  When any padding
+          bytes are required between the last payload and the Cksum
+          field, they MUST be included in the calculation.  This field
+          MUST always be present whenever a key is available via an
+          AP-REQ or AP-REP payload.  The key used MUST be the session
+          key in the ticket.  When a key is not available, this field is
+          not present, and the CksumLen field is set to zero.  The
+          content of this field is the output of the Kerberos 5 get_mic
+          function [KCRYPTO].  The get_mic function used is specified by
+          a checksum type, which is a "required checksum mechanism" of
+          the etype for the Kerberos session key in the Kerberos ticket.
+          If the checksum type is not a keyed algorithm, the message
+          MUST be rejected.
+
+          To compute the checksum, the CksumLen field is zeroed out and
+          the Length field is filled with the total packet length
+          without the checksum.  Then, the packet is passed to the
+          get_mic function and its output is appended to the packet.
+          Any KINK padding after the Cksum field is not allowed, except
+          the Kerberos internal one, which may be included in the output
+          of the get_mic function.  Finally, the CksumLen field is
+          filled with the checksum length and the Length field is filled
+          with the total packet length including the checksum.
+
+          To verify the checksum, a length-without-checksum is
+          calculated from the value of Length field, subtracting the
+          CksumLen.  The Length field is filled with the length-
+          without-checksum value and the CksumLen field is zeroed out.
+          Then, the packet without checksum (offset from 0 to length-
+          without-checksum minus 1 of the received packet) and the
+          checksum (offset from length-without-checksum to the last) are
+          passed to the verify_mic function.  If verification fails, the
+          message MUST be dropped.
+
+   The KINK header is followed immediately by a series of
+   Type/Length/Value fields, defined in section 4.2.
+
+4.1.  KINK Alignment Rules
+
+   KINK has the following rules regarding alignment and padding:
+
+     o    All length fields MUST reflect the actual number of octets in
+          the structure; i.e., they do not account for padding bytes
+          required by KINK alignments.
+
+     o    KINK headers, payloads, and the Cksum field MUST be aligned on
+          4-octet boundaries.
+
+
+
+Sakane, et al.              Standards Track                    [Page 15]
+
+RFC 4430                          KINK                        March 2006
+
+
+     o    Variable length fields (except the Cksum field) MUST always
+          start immediately after the last octet of the previous field.
+          That is, they are not aligned to 4-octet boundaries.
+
+4.2.  KINK Payloads
+
+   Immediately following the header, there is a list of
+   Type/Length/Value (TLV) payloads.  There can be any number of
+   payloads following the header.  Each payload MUST begin with a
+   payload header.  Each payload header is built on the generic payload
+   header.  Any data immediately follows the generic header.  Payloads
+   are all implicitly aligned to 4-octet boundaries, though the payload
+   length field MUST accurately reflect the actual number of octets in
+   the payload.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +---------------+---------------+---------------+---------------+
+    | Next Payload  |   RESERVED    |         Payload Length        |
+    +---------------+---------------+---------------+---------------+
+    |                      value (variable)                         |
+    +---------------+---------------+---------------+---------------+
+
+                    Figure 6:  Format of a KINK Payload
+
+   Fields:
+
+     o    Next Payload (1 octet) -- The type of the next payload.
+
+              NextPayload       Value
+              ----              -----
+              KINK_DONE           0
+              KINK_AP_REQ         1
+              KINK_AP_REP         2
+              KINK_KRB_ERROR      3
+              KINK_TGT_REQ        4
+              KINK_TGT_REP        5
+              KINK_ISAKMP         6
+              KINK_ENCRYPT        7
+              KINK_ERROR          8
+              RESERVED TO IANA    9 - 127
+              Private Use       128 - 255
+
+          Next Payload type KINK_DONE denotes that the current payload
+          is the final payload in the message.
+
+     o    RESERVED (1 octet) -- Reserved and MUST be set to zero by a
+          sender, MUST be ignored by a receiver.
+
+
+
+Sakane, et al.              Standards Track                    [Page 16]
+
+RFC 4430                          KINK                        March 2006
+
+
+     o    Payload Length (2 octets) -- The length of this payload,
+          including the type and length fields.
+
+     o    Value (variable) -- This value of this field depends on the
+          type.
+
+4.2.1.  KINK_AP_REQ Payload
+
+   The KINK_AP_REQ payload relays a Kerberos AP-REQ to the responder.
+   The AP-REQ MUST request mutual authentication.
+
+   This document does not specify how to generate the principal name.
+   That is, complete principal names may be stored in local policy,
+   Fully Qualified Domain Names (FQDNs) may be converted to principal
+   names, IP addresses may be converted to principal names by secure
+   name services, etc., but see the first paragraph of the Security
+   Considerations section.
+
+   If the peer's principal name for the KINK service is generated from
+   an FQDN, the principal name, which the initiator starts from, will be
+   "kink/fqdn@REALM"; where "kink" is a literal string for the KINK
+   IPsec service, "fqdn" is the fully qualified domain name of the
+   service host, and "REALM" is the Kerberos realm of the service.  A
+   principal name is case sensitive, and "fqdn" part MUST be lowercase
+   as described in [KERBEROS].
+
+   The value field of this payload has the following format:
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +---------------+---------------+---------------+---------------+
+    | Next Payload  |   RESERVED    |         Payload Length        |
+    +---------------+---------------+---------------+---------------+
+    |                         EPOCH                                 |
+    +---------------------------------------------------------------+
+    |                                                               |
+    ~                        AP-REQ                                 ~
+    |                                                               |
+    +---------------------------------------------------------------+
+
+                      Figure 7:  KINK_AP_REQ Payload
+
+   Fields:
+
+     o    Next Payload, RESERVED, Payload Length -- Defined in the
+          beginning of this section.
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 17]
+
+RFC 4430                          KINK                        March 2006
+
+
+     o    EPOCH -- The absolute time at which the creator of the AP-REQ
+          has valid SA information.  Typically, this is when the KINK
+          keying daemon started if it does not retain SA information
+          across restarts.  The value in this field is the least
+          significant 4 octets of so-called POSIX time, which is the
+          elapsed seconds (but without counting leap seconds) from
+          1970-01-01T00:00:00 UTC.  For example, 2038-01-19T03:14:07 UTC
+          is represented as 0x7fffffff.
+
+     o    AP-REQ -- The value field of this payload contains a raw
+          Kerberos AP-REQ.
+
+4.2.2.  KINK_AP_REP Payload
+
+   The KINK_AP_REP payload relays a Kerberos AP-REP to the initiator.
+   The AP-REP MUST be checked for freshness as described in [KERBEROS].
+
+   The value field of this payload has the following format:
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +---------------+---------------+---------------+---------------+
+    | Next Payload  |   RESERVED    |         Payload Length        |
+    +---------------+---------------+---------------+---------------+
+    |                         EPOCH                                 |
+    +---------------------------------------------------------------+
+    |                                                               |
+    ~                        AP-REP                                 ~
+    |                                                               |
+    +---------------------------------------------------------------+
+
+                      Figure 8:  KINK_AP_REP Payload
+
+   Fields:
+
+     o    Next Payload, RESERVED, Payload Length -- Defined in the
+          beginning of this section.
+
+     o    EPOCH -- The absolute time at which the creator of the AP-REP
+          has valid SA information.  Typically, this is when the KINK
+          keying daemon started if it does not retain SA information
+          across restarts.  The value in this field is the least
+          significant 4 octets of so-called POSIX time, which is the
+          elapsed seconds (but without counting leap seconds) from
+          1970-01-01T00:00:00 UTC.  For example, 2038-01-19T03:14:07 UTC
+          is represented as 0x7fffffff.
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 18]
+
+RFC 4430                          KINK                        March 2006
+
+
+     o    AP-REP -- The value field of this payload contains a raw
+          Kerberos AP-REP.
+
+4.2.3.  KINK_KRB_ERROR Payload
+
+   The KINK_KRB_ERROR payload relays Kerberos type errors back to the
+   initiator.  The initiator MUST be prepared to receive any valid
+   Kerberos error type [KERBEROS].
+
+   KINK implementations SHOULD make use of a KINK Cksum field when
+   returning KINK_KRB_ERROR and the appropriate service key is
+   available.  Especially in the case of clock skew errors, protecting
+   the error at the server creates a better user experience because it
+   does not require clocks to be synchronized.  However, many Kerberos
+   implementations do not make it easy to obtain the session key in
+   order to protect error packets.  For unauthenticated Kerberos errors,
+   the initiator MAY choose to act on them, but SHOULD take precautions
+   against make-work kinds of attacks.
+
+   Note that KINK does not make use of the text or e_data field of the
+   Kerberos error message, though a compliant KINK implementation MUST
+   be prepared to receive them and MAY log them.
+
+   The value field of this payload has the following format:
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +---------------+---------------+---------------+---------------+
+    | Next Payload  |   RESERVED    |         Payload Length        |
+    +---------------+---------------+---------------+---------------+
+    |                                                               |
+    ~                      KRB-ERROR                                ~
+    |                                                               |
+    +---------------------------------------------------------------+
+
+                     Figure 9:  KINK_KRB_ERROR Payload
+
+   Fields:
+
+     o    Next Payload, RESERVED, Payload Length -- Defined in the
+          beginning of this section.
+
+     o    KRB-ERROR -- The value field of this payload contains a raw
+          Kerberos KRB-ERROR.
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 19]
+
+RFC 4430                          KINK                        March 2006
+
+
+4.2.4.  KINK_TGT_REQ Payload
+
+   The KINK_TGT_REQ payload provides a means to get a TGT from the peer
+   in order to obtain a User-to-User service ticket from the KDC.
+
+   The value field of this payload has the following format:
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +---------------+---------------+---------------+---------------+
+    | Next Payload  |   RESERVED    |         Payload Length        |
+    +---------------+---------------+---------------+---------------+
+    |                                                               |
+    ~                     PrincName (variable)                      ~
+    |                                                               |
+    +---------------------------------------------------------------+
+
+                     Figure 10:  KINK_TGT_REQ Payload
+
+   Fields:
+
+     o    Next Payload, RESERVED, Payload Length -- Defined in the
+          beginning of this section.
+
+     o    PrincName -- The name of the principal that the initiator
+          wants to communicate with.  It is assumed that the initiator
+          knows the responder's principal name (including the realm
+          name) in the same way as the non-User-to-User case.  The TGT
+          returned MUST NOT be an inter-realm TGT and its cname and
+          crealm MUST match the requested principal name, so that the
+          initiator can rendezvous with the responder at the responder's
+          realm.
+
+          PrincName values are octet string representations of a
+          principal and realm name formatted just like the octet string
+          used in the "NAME" component of Generic Security Service
+          Application Program Interface (GSS-API) [RFC2743] exported
+          name token for the Kerberos V5 GSS-API mechanism [RFC1964].
+          See RFC 1964, section 2.1.3.
+
+   If the responder is not the requested principal and is unable to get
+   a TGT for the name, it MAY return a KRB_AP_ERR_NOT_US.  If the
+   administrative policy prohibits returning a TGT, it MAY return a
+   KINK_U2UDENIED.
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 20]
+
+RFC 4430                          KINK                        March 2006
+
+
+4.2.5.  KINK_TGT_REP Payload
+
+   The value field of this payload contains the TGT requested in a
+   previous KINK_TGT_REQ payload of a GETTGT command.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +---------------+---------------+---------------+---------------+
+    | Next Payload  |   RESERVED    |         Payload Length        |
+    +---------------+---------------+---------------+---------------+
+    |                                                               |
+    ~                        TGT (variable)                         ~
+    |                                                               |
+    +---------------------------------------------------------------+
+
+                     Figure 11:  KINK_TGT_REP Payload
+
+   Fields:
+
+     o    Next Payload, RESERVED, Payload Length -- Defined in the
+          beginning of this section.
+
+     o    TGT -- The Distinguished Encoding Rules (DER)-encoded TGT of
+          the responder.
+
+4.2.6.  KINK_ISAKMP Payload
+
+   The value field of this payload has the following format:
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +---------------+---------------+---------------+---------------+
+    | Next Payload  |   RESERVED    |         Payload Length        |
+    +---------------+-------+-------+---------------+---------------+
+    | InnerNextPload| QMMaj | QMMin |            RESERVED           |
+    +---------------+-------+-------+---------------+---------------+
+    |                Quick Mode Payloads (variable)                 |
+    +---------------+---------------+---------------+---------------+
+
+                      Figure 12:  KINK_ISAKMP Payload
+
+   Fields:
+
+     o    Next Payload, RESERVED, Payload Length -- Defined in the
+          beginning of this section.
+
+     o    InnerNextPload -- First payload type of the inner series of
+          ISAKMP payloads.
+
+
+
+Sakane, et al.              Standards Track                    [Page 21]
+
+RFC 4430                          KINK                        March 2006
+
+
+     o    QMMaj -- The major version of the inner payloads.  MUST be set
+          to 1.
+
+     o    QMMin -- The minor version of the inner payloads.  MUST be set
+          to 0.
+
+   The KINK_ISAKMP payload encapsulates the IKE Quick Mode (phase 2)
+   payloads to take the appropriate action dependent on the KINK
+   command.  There may be any number of KINK_ISAKMP payloads within a
+   single KINK message.  While [IKE] is somewhat fuzzy about whether
+   multiple different SAs may be created within a single IKE message,
+   KINK explicitly requires that a new ISAKMP header be used for each
+   discrete SA operation.  In other words, a KINK implementation MUST
+   NOT send multiple Quick Mode transactions within a single KINK_ISAKMP
+   payload.
+
+   The purpose of the Quick Mode version is to allow backward
+   compatibility with IKE and ISAKMP if there are subsequent revisions.
+   At the present time, the Quick Mode major and minor versions are set
+   to one and zero (1.0), respectively.  These versions do not
+   correspond to the ISAKMP version in the ISAKMP header.  A compliant
+   KINK implementation MUST support receipt of 1.0 payloads.  It MAY
+   support subsequent versions (both sending and receiving), and SHOULD
+   provide a means to resort back to Quick Mode version 1.0 if the KINK
+   peer is unable to process future versions.  A compliant KINK
+   implementation MUST NOT mix Quick Mode versions in any given
+   transaction.
+
+4.2.7.  KINK_ENCRYPT Payload
+
+   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.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +---------------+---------------+---------------+---------------+
+    | Next Payload  |   RESERVED    |         Payload Length        |
+    +---------------+---------------+---------------+---------------+
+    | InnerNextPload|                   RESERVED2                   |
+    +---------------+---------------+---------------+---------------+
+    |                         Payload (variable)                    |
+    +---------------+---------------+---------------+---------------+
+
+                     Figure 13:  KINK_ENCRYPT Payload
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 22]
+
+RFC 4430                          KINK                        March 2006
+
+
+   Fields:
+
+     o    Next Payload, RESERVED, Payload Length -- Defined in the
+          beginning of this section.  This payload is the last one in a
+          message, and accordingly, the Next Payload field must be
+          KINK_DONE (0).
+
+     o    InnerNextPload -- First payload type of the inner series of
+          encrypted KINK payloads.
+
+     o    RESERVED2 -- Reserved and MUST be zero when sent, MUST be
+          ignored when received.
+
+   The coverage of the encrypted data begins at InnerNextPload so that
+   the first payload's type is kept confidential.  Thus, the number of
+   encrypted octets is PayloadLength - 4.
+
+   The format of the encryption payload follows the normal Kerberos
+   semantics.  Its content is the output of an encrypt function defined
+   in the Encryption Algorithm Profile section of [KCRYPTO].  Parameters
+   such as encrypt function itself, specific-key, and initial state are
+   defined with the etype.  The encrypt function may have padding in
+   itself and there may be some garbage data at the end of the decrypted
+   plaintext.  A KINK implementation MUST be prepared to ignore such
+   padding after the last sub-payload inside the KINK_ENCRYPT payload.
+   Note that each encrypt function has its own integrity protection
+   mechanism.  It is redundant with the checksum in the KINK header, but
+   this is unavoidable because it is not always possible to remove the
+   integrity protection part from the encrypt function.
+
+4.2.8.  KINK_ERROR Payload
+
+   The KINK_ERROR payload type provides a protocol-level mechanism of
+   returning an error condition.  This payload should not be used for
+   either Kerberos-generated errors or DOI-specific errors that have
+   their own payloads defined.  The error code is in network order.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +---------------+---------------+---------------+---------------+
+    | Next Payload  |   RESERVED    |         Payload Length        |
+    +---------------+---------------+---------------+---------------+
+    |                           ErrorCode                           |
+    +---------------+---------------+---------------+---------------+
+
+                      Figure 14:  KINK_ERROR Payload
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 23]
+
+RFC 4430                          KINK                        March 2006
+
+
+   Fields:
+
+     o    Next Payload, RESERVED, Payload Length -- Defined in the
+          beginning of this section.
+
+     o    ErrorCode -- One of the following values in the network byte
+          order:
+
+          ErrorCode          Value             Purpose
+          ---------          -----       -------------------
+          KINK_OK              0         No error detected
+          KINK_PROTOERR        1         The message was malformed
+          KINK_INVDOI          2         Invalid DOI
+          KINK_INVMAJ          3         Invalid Major Version
+          RESERVED             4
+          KINK_INTERR          5         An unrecoverable internal error
+          KINK_BADQMVERS       6         Unsupported Quick Mode Version
+          KINK_U2UDENIED       7         Returning a TGT is prohibited
+          RESERVED TO IANA     8 - 8191
+          Private Use       8192 - 16383
+          RESERVED         16384 -
+
+   The responder MUST NOT return KINK_OK.  When received, the initiator
+   MAY act as if the specific KINK_ERROR payload were not present.  If
+   the initiator supports multiple Quick Mode versions or DOIs,
+   KINK_BADQMVERS or KINK_INVDOI is received, and the Cksum is verified,
+   then it MAY retry with another version or DOI.  A responder SHOULD
+   return a KINK error with KINK_INVMAJ, when it receives an unsupported
+   KINK version number in the header.  When KINK_U2UDENIED is received,
+   the initiator MAY retry with the non-User-to-User mode (if it has not
+   yet been tried).
+
+   In general, the responder MAY choose to return these errors in reply
+   to unauthenticated commands, but SHOULD take care to avoid being
+   involved in denial of service attacks.  Similarly, the initiator MAY
+   choose to act on unauthenticated errors, but SHOULD take care to
+   avoid denial of service attacks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 24]
+
+RFC 4430                          KINK                        March 2006
+
+
+5.  Differences from IKE Quick Mode
+
+   KINK directly uses ISAKMP payloads to negotiate SAs.  In particular,
+   KINK uses IKE phase 2 payload types (aka Quick Mode).  In general,
+   there should be very few changes necessary to an IKE implementation
+   to establish the SAs, and unless there is a note to the contrary in
+   the memo, all capabilities and requirements in [IKE] MUST be
+   supported.  IKE phase 1 payloads MUST NOT be sent.
+
+   Unlike IKE, KINK defines specific commands for creation, deletion,
+   and status of SAs, mainly to facilitate predictable SA
+   creation/deletion (see sections 3.2 and 3.3).  As such, KINK places
+   certain restrictions on what payloads may be sent with which
+   commands, and some additional restrictions and semantics of some of
+   the payloads.  Implementors should refer to [IKE] and [ISAKMP] for
+   the actual format and semantics.  If a particular IKE phase 2 payload
+   is not mentioned here, it means that there are no differences in its
+   use.
+
+
+     o   The Security Association Payload header for IP is defined in
+         section 4.6.1 of [IPDOI].  For this memo, the Domain of
+         Interpretation MUST be set to 1 (IPsec) and the Situation
+         bitmap MUST be set to 1 (SIT_IDENTITY_ONLY).  All other fields
+         are omitted (because SIT_IDENTITY_ONLY is set).
+
+     o   KINK also expands the semantics of IKE in that it defines an
+         optimistic proposal for CREATE commands to allow SA creation to
+         complete in two messages.
+
+     o   IKE Quick Mode (phase 2) uses the hash algorithm used in main
+         mode (phase 1) to generate the keying material.  For this
+         purpose, KINK MUST use a pseudo-random function determined by
+         the etype of the session key.
+
+     o   KINK does not use the HASH payload at all.
+
+     o   KINK allows the Nonce payload Nr to be optional to facilitate
+         optimistic keying.
+
+
+
+
+
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 25]
+
+RFC 4430                          KINK                        March 2006
+
+
+5.1.  Security Association Payloads
+
+   KINK supports the following SA attributes from [IPDOI]:
+
+   class                     value           type
+   -------------------------------------------------
+   SA Life Type                1               B
+   SA Life Duration            2               V
+   Encapsulation Mode          4               B
+   Authentication Algorithm    5               B
+   Key Length                  6               B
+   Key Rounds                  7               B
+
+   Refer to [IPDOI] for the actual definitions of these attributes.
+
+5.2.  Proposal and Transform Payloads
+
+   KINK directly uses the Proposal and Transform payloads with no
+   differences.  KINK, however, places additional relevance to the first
+   proposal and first transform of each conjugate for optimistic keying.
+
+5.3.  Identification Payloads
+
+   The Identification payload carries information that is used to
+   identify the traffic that is to be protected by the SA that will be
+   established.  KINK restricts the ID types, which are defined in
+   section 4.6.2.1 of [IPDOI], to the following values:
+
+      ID Type                  Value
+      -------                  -----
+      ID_IPV4_ADDR               1
+      ID_IPV4_ADDR_SUBNET        4
+      ID_IPV6_ADDR               5
+      ID_IPV6_ADDR_SUBNET        6
+      ID_IPV4_ADDR_RANGE         7
+      ID_IPV6_ADDR_RANGE         8
+
+5.4.  Nonce Payloads
+
+   The Nonce payload contains random data that MUST be used in key
+   generation.  It MUST be sent by the initiating KINK peer, and MAY be
+   sent by the responding KINK peer.  See section 7 for the discussion
+   of its use in key generation.
+
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 26]
+
+RFC 4430                          KINK                        March 2006
+
+
+5.5.  Notify Payloads
+
+   Notify payloads are used to transmit several informational data, such
+   as error conditions and state transitions to a peer.  For example,
+   notification information transmit can be error messages specifying
+   why an SA could not be established.  It can also be status data that
+   a process managing an SA database wishes to communicate with a peer
+   process.
+
+   Types in the range 0 - 16383 are intended for reporting errors
+   [ISAKMP].  An implementation receiving a type in this range that it
+   does not recognize in a response MUST assume that the corresponding
+   request has failed entirely.  Unrecognized error types in a request
+   and status types in a request or response MUST be ignored, and they
+   SHOULD be logged.  Notify payloads with status types MAY be added to
+   any message and MUST be ignored if not recognized.  They are intended
+   to indicate capabilities, and as part of SA negotiation are used to
+   negotiate non-cryptographic parameters.
+
+   The table below lists the Notification messages and their
+   corresponding values.  PAYLOAD-MALFORMED denotes some error types
+   defined by [ISAKMP].  Hence INVALID-PROTOCOL-ID, for example, is not
+   used in this document.  INVALID-MAJOR-VERSION and INVALID-MINOR-
+   VERSION are not used because KINK_BADQMVERS is used to tell the
+   initiator that the version of IKE is not supported.
+
+   NOTIFY MESSAGES - ERROR TYPES           Value
+   -----------------------------           -----
+   INVALID-PAYLOAD-TYPE                      1
+
+      Sent if the ISAKMP payload type is not recognized.  It is also
+      sent when the KE payload is not supported by the responder.
+      Notification Data MUST contains the one-octet payload type.
+
+   INVALID-SPI                              11
+
+      Sent if the responder has an SPI indicated by the initiator in
+      case of CREATE flow, or if the responder does not have an SPI
+      indicated by the initiator in case of DELETE flow.
+
+   NO-PROPOSAL-CHOSEN                       14
+
+      Sent if none of the proposals in the SA payload was
+      acceptable.
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 27]
+
+RFC 4430                          KINK                        March 2006
+
+
+   PAYLOAD-MALFORMED                        16
+
+      Sent if the KINK_ISAKMP payload received was invalid because
+      some type, length, or value was out of range.  It is also sent
+      when the request was rejected for reason that was not matched
+      with other error types.
+
+5.6.  Delete Payloads
+
+   KINK directly uses ISAKMP Delete payloads with no changes.
+
+5.7.  KE Payloads
+
+   IKE requires that perfect forward secrecy (PFS) be supported through
+   the use of the KE payload.  KINK retains the ability to use PFS, but
+   relaxes the requirement from must implement to SHOULD implement.  The
+   reasons are described in the Security Considerations section.
+
+6.  Message Construction and Constraints for IPsec DOI
+
+   All commands, responses, and acknowledgements 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.
+
+   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.
+
+6.1.  REPLY Message
+
+   The REPLY message is a generic reply that MUST contain either a
+   KINK_AP_REP, a KINK_KRB_ERROR, or a KINK_ERROR payload.  REPLY
+   messages MAY contain additional DOI-specific payloads such as ISAKMP
+   payloads that are defined in the following sections.
+
+6.2.  ACK Message
+
+   ACKs are sent only when the ACKREQ bit is set in a REPLY message.  An
+   ACK message MUST contain an AP-REQ payload and no other payload.
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 28]
+
+RFC 4430                          KINK                        March 2006
+
+
+6.3.  CREATE Message
+
+   This message initiates an establishment of new security
+   association(s).  The CREATE message must contain an AP-REQ payload
+   and any DOI-specific payloads.
+
+   CREATE KINK Header
+     KINK_AP_REQ
+     [KINK_ENCRYPT]
+        KINK_ISAKMP payloads
+            SA Payload
+                 Proposal Payloads
+                      Transform Payloads
+            Nonce Payload (Ni)
+            [KE]
+            [IDci, IDcr]
+            [Notification Payloads]
+
+   Replies are of the following forms:
+
+   REPLY KINK Header
+     KINK_AP_REP
+     [KINK_ENCRYPT]
+        KINK_ISAKMP payloads
+            SA Payload
+                 Proposal Payloads
+                      Transform Payload
+            [Nonce Payload (Nr)]
+            [KE]
+            [IDci, IDcr]
+            [Notification Payloads]
+
+   Note that there MUST be at least a single proposal payload and a
+   single transform payload in REPLY messages.  There will be multiple
+   proposal payloads only when an SA bundle is negotiated.  Also: unlike
+   IKE, the Nonce payload Nr is not required, and if it exists, an
+   acknowledgement must be requested to indicate that the initiator's
+   outgoing SAs must be modified.  If any of the first proposals are not
+   chosen by the recipient, it SHOULD include the Nonce payload.
+
+   KINK, like IKE, allows the creation of many SAs in one create
+   command.  If any of the optimistic proposals are not chosen by the
+   responder, it MUST request an ACK.
+
+   If an IPsec DOI-specific error is encountered, the responder must
+   reply with a Notify payload describing the error:
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 29]
+
+RFC 4430                          KINK                        March 2006
+
+
+   REPLY KINK Header
+     KINK_AP_REP
+     [KINK_ENCRYPT]
+        [KINK_ERROR]
+        KINK_ISAKMP payloads
+            [Notification Payloads]
+
+   If the responder finds a Kerberos error for which it can produce a
+   valid authenticator, the REPLY takes the following form:
+
+   REPLY KINK Header
+     KINK_AP_REP
+     [KINK_ENCRYPT]
+        KINK_KRB_ERROR
+
+   Finally, if the responder finds a Kerberos or KINK type of error for
+   which it cannot create an AP-REP, it MUST reply with a lone
+   KINK_KRB_ERROR or KINK_ERROR payload:
+
+   REPLY KINK Header
+     [KINK_KRB_ERROR]
+     [KINK_ERROR]
+
+6.4.  DELETE Message
+
+   This message indicates that the sending peer has deleted or will
+   shortly delete Security Association(s) with the other peer.
+
+   DELETE KINK Header
+     KINK_AP_REQ
+     [KINK_ENCRYPT]
+        KINK_ISAKMP payloads
+            Delete Payloads
+            [Notification Payloads]
+
+   There are three forms of replies for a DELETE.  The normal form is:
+
+   REPLY KINK Header
+     KINK_AP_REP
+     [KINK_ENCRYPT]
+        [KINK_ERROR]
+        KINK_ISAKMP payloads
+            Delete Payloads
+            [Notification Payloads]
+
+   If an IPsec DOI-specific error is encountered, the responder must
+   reply with a Notify payload describing the error:
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 30]
+
+RFC 4430                          KINK                        March 2006
+
+
+   REPLY KINK Header
+     KINK_AP_REP
+     [KINK_ENCRYPT]
+        [KINK_ERROR]
+        KINK_ISAKMP payloads
+            [Notification Payloads]
+
+   If the responder finds a Kerberos error for which it can produce a
+   valid authenticator, the REPLY takes the following form:
+
+   REPLY KINK Header
+     KINK_AP_REP
+     [KINK_ENCRYPT]
+        KINK_KRB_ERROR
+
+   If the responder finds a KINK or Kerberos type of error, it MUST
+   reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
+
+   REPLY KINK Header
+     [KINK_KRB_ERROR]
+     [KINK_ERROR]
+
+6.5.  STATUS Message
+
+   The STATUS command is used in two ways:
+
+     1)  As a means to relay an ISAKMP Notification message.
+
+     2)  As a means of probing a peer whether its epoch has changed for
+         dead peer detection.
+
+   STATUS contains the following payloads:
+     KINK Header
+     KINK_AP_REQ
+     [[KINK_ENCRYPT]
+        KINK_ISAKMP payload
+            [Notification Payloads]]
+
+   There are three forms of replies for a STATUS.  The normal form is:
+
+   REPLY KINK Header
+     KINK_AP_REP
+     [[KINK_ENCRYPT]
+        [KINK_ERROR]
+        KINK_ISAKMP payload
+            [Notification Payloads]]
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 31]
+
+RFC 4430                          KINK                        March 2006
+
+
+   If the responder finds a Kerberos error for which it can produce a
+   valid authenticator, the REPLY takes the following form:
+
+   REPLY KINK Header
+     KINK_AP_REP
+     [KINK_ENCRYPT]
+        KINK_KRB_ERROR
+
+   If the responder finds a KINK or Kerberos type of error, it MUST
+   reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
+
+   REPLY KINK Header
+     [KINK_KRB_ERROR]
+     [KINK_ERROR]
+
+6.6.  GETTGT Message
+
+   A GETTGT command is only used to carry a Kerberos TGT and is not
+   related to SA management; therefore, it contains only KINK_TGT_REQ
+   payload and does not contain any DOI-specific payload.
+
+   There are two forms of replies for a GETTGT.  In the normal form,
+   where the responder is allowed to return its TGT, the REPLY contains
+   KINK_TGT_REP payload.  If the responder is not allowed to return its
+   TGT, it MUST reply with a KINK_ERROR payload.
+
+7.  ISAKMP Key Derivation
+
+   KINK uses the same key derivation mechanisms defined in section 5.5
+   of [IKE], which is:
+
+   KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b])
+
+   The following differences apply:
+
+     o    prf is the pseudo-random function corresponding to the session
+          key's etype.  They are defined in [KCRYPTO].
+
+     o    SKEYID_d is the session key in the Kerberos service ticket
+          from the AP-REQ.  Note that subkeys are not used in KINK and
+          MUST be ignored if received.
+
+     o    Both Ni_b and Nr_b are the part of the Nonce payloads (Ni and
+          Nr, respectively) as described in section 3.2 of [IKE].  Nr_b
+          is optional, which means that Nr_b is treated as if a zero
+          length value was supplied when the responder's nonce (Nr) does
+          not exist.  When Nr exists, Nr_b MUST be included in the
+          calculation.
+
+
+
+Sakane, et al.              Standards Track                    [Page 32]
+
+RFC 4430                          KINK                        March 2006
+
+
+   Note that g(qm)^xy refers to the keying material generated when KE
+   payloads are supplied using Diffie-Hellman key agreement.  This is
+   explained in section 5.5 of [IKE].
+
+   The rest of the key derivation (e.g., how to expand KEYMAT) follows
+   IKE.  How to use derived keying materials is up to each service
+   (e.g., section 4.5.2 of [IPSEC]).
+
+8.  Key Usage Numbers for Kerberos Key Derivation
+
+   Kerberos encrypt/decrypt functions and get_mic/verify_mic functions
+   require "key usage numbers".  They are used to generate specific keys
+   for cryptographic operations so that different keys are used for
+   different purposes/objects.  KINK uses two usage numbers, listed
+   below.
+
+      Purpose                                   Usage number
+      -------                                   ------------
+      KINK_ENCRYPT payload (for encryption)      39
+      Cksum field (for checksum)                 40
+
+9.  Transport Considerations
+
+   KINK uses UDP on port 910 to transport its messages.  There is one
+   timer T which SHOULD take into consideration round-trip
+   considerations and MUST implement a truncated exponential back-off
+   mechanism.  The state machine is simple: any message that expects a
+   response MUST retransmit the request using timer T.  Since Kerberos
+   requires that messages be retransmitted with new times for replay
+   protection, the message MUST be re-created each time including the
+   checksum of the message.  Both commands and replies with the ACKREQ
+   bit set are kept on retransmit timers.  When a KINK initiator
+   receives a REPLY with the ACKREQ bit set, it MUST retain the ability
+   to regenerate the ACK message for the transaction for a minimum of
+   its full retransmission timeout cycle or until it notices that
+   packets have arrived on the newly constructed SA, whichever comes
+   first.
+
+   When a KINK peer retransmits a message, it MUST create a new Kerberos
+   authenticator for the AP-REQ so that the peer can differentiate
+   between replays and dropped packets.  This results in a potential
+   race condition when a retransmission occurs before an in-flight reply
+   is received/processed.  To counter this race condition, the
+   retransmitting party SHOULD keep a list of valid authenticators that
+   are outstanding for any particular transaction.
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 33]
+
+RFC 4430                          KINK                        March 2006
+
+
+   When a KINK peer retransmits a command, it MUST use the same ticket
+   within the retransmissions.  This is to avoid race conditions on
+   using different keys, which result in different KEYMATs between an
+   initiator and a responder.  For this reason, (1) an initiator MUST
+   obtain a ticket whose lifetime is greater than the initiator's
+   maximum transaction time including timeouts, or (2) it MUST continue
+   to use the same ticket within a set of retransmissions, and iff it
+   receives an error (most likely KRB_AP_ERR_TKT_EXPIRED) from the
+   responder, it starts a new transaction with a new ticket.
+
+10.  Security Considerations
+
+   The principal names are the identities of the KINK services, but the
+   traffic protected by SAs are identified by DOI-specific selectors (IP
+   addresses, port numbers, etc.).  This may lead to a breakaway of
+   SA-protected data from authentication.  For example, if two different
+   hosts claim that they have the same IP address, it may be impossible
+   to predict which principal's key protects the data.  Thus, an
+   implementation must take care for the binding between principal names
+   and the SA selectors.
+
+   Sending errors without cryptographic protection must be handled very
+   carefully.  There is a trade-off between wanting to be helpful in
+   diagnosing a problem and wanting to avoid being a dupe in a denial of
+   service attack.
+
+   KINK cobbles together and reuses many parts of both Kerberos and IKE,
+   the latter which in turn is cobbled together from many other memos.
+   As such, KINK inherits many of the weaknesses and considerations of
+   each of its components.  However, KINK uses only IKE phase 2 payloads
+   to create and delete SAs; the security considerations which pertain
+   to IKE phase 1 may be safely ignored.  However, being able to ignore
+   IKE's authentication phase necessarily means that KINK inherits all
+   of the security considerations of Kerberos authentication as outlined
+   in [KERBEROS].  For one, a KDC, like an Authentication,
+   Authorization, and Accounting (AAA) server, is a point of attack and
+   all that implies.  Much has been written about various shortcomings
+   and mitigations of Kerberos, and they should be evaluated for any
+   deployment.
+
+   KINK's use of Kerberos presents a couple of considerations.  First,
+   KINK explicitly expects that the KDC will provide adequate entropy
+   when it generates session keys.  Second, Kerberos is used as a user
+   authentication protocol with the possibility of dictionary attacks on
+   user passwords.  This memo does not describe a particular method to
+   avoid these pitfalls, but recommends that suitable randomly generated
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 34]
+
+RFC 4430                          KINK                        March 2006
+
+
+   keys should be used for the service principals such as using the
+   -randomkey option with MIT's "kadmin addprinc" command as well as for
+   clients when that is practical.
+
+   Kerberos does not currently provide perfect forward secrecy in
+   general.  KINK with the KE payload can provide PFS for a service key
+   from a Kerberos key, but the KE is not mandatory because of the
+   computational cost.  This is a trade-off and operators can choose the
+   PFS over the cost, and vice versa.  KINK itself should be secure from
+   offline analysis from compromised principal passphrases if PFS is
+   used, but from an overall system's standpoint, the existence of other
+   Kerberized services that do not provide PFS makes this a less than
+   optimal situation.
+
+11.  IANA Considerations
+
+   The IANA has assigned a well-known port number for KINK.
+
+   The IANA has created a new registry for KINK parameters, and has
+   registered the following identifiers.
+
+      KINK Message Types (section 4)
+      KINK Next Payload Types (section 4.2)
+      KINK Error Codes (section 4.2.8)
+
+   Changes and additions to this registry follow the policies described
+   below.  Their meanings are described in [BCP26].
+
+     o    Using the numbers in the "Private Use" range is Private Use.
+
+     o    Assignment from the "RESERVED TO IANA" range needs Standards
+          Action, or non-standards-track RFCs with Expert Review.
+          (Though the full specification may be a public and permanent
+          document of a standards body other than IETF, an RFC referring
+          it is needed.)
+
+     o    Other change requires Standards Action.
+
+12.  Forward Compatibility Considerations
+
+   KINK can accommodate future versions of Quick Mode through the use of
+   the version field in the ISAKMP payload as well as new domains of
+   interpretation.  In this memo, the only supported Quick Mode version
+   is 1.0, which corresponds to [IKE].  Likewise, the only DOI supported
+   is the IPsec domain of interpretation [IPDOI].  New Quick Mode
+   versions and DOIs MUST be described in subsequent memos.
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 35]
+
+RFC 4430                          KINK                        March 2006
+
+
+   KINK implementations MUST reject ISAKMP versions that are greater
+   than the highest currently supported version with a KINK_BADQMVERS
+   error type.  A KINK implementation that receives a KINK_BADQMVERS
+   message SHOULD be capable of reverting back to version 1.0.
+
+12.1.  New Versions of Quick Mode
+
+   The IPsec working group is defining the next-generation IKE protocol
+   [IKEv2], which does not use Quick Mode, but it is similar to the one
+   in IKEv1.  The difference between the two is summarized in Appendix A
+   of [IKEv2].  Each of them must be considered in order to use IKEv2
+   with KINK.
+
+12.2.  New DOI
+
+   The KINK message header contains a field called "Domain of
+   Interpretation (DOI)" to allow other domains of interpretation to use
+   KINK as a secure transport mechanism for keying.
+
+   As one example of a new DOI, the MSEC working group defined the Group
+   Domain of Interpretation [GDOI], which defines a few new messages,
+   which look like ISAKMP messages, but are not defined in ISAKMP.
+
+   In order to carry GDOI messages in KINK, the DOI field in the KINK
+   header would indicate that GDOI is being used, instead of IPSEC-DOI,
+   and the KINK_ISAKMP payload would contain the payloads defined in the
+   GDOI document rather than the payloads used by [IKE] Quick Mode.  The
+   version number in the KINK_ISAKMP header is related to the DOI in the
+   KINK header, so a maj.min version 1.0 under DOI GDOI is different
+   from a maj.min version 1.0 under DOI IPSEC-DOI.
+
+13.  Related Work
+
+   The IPsec working group has defined a number of protocols that
+   provide the ability to create and maintain cryptographically secure
+   SAs at layer three (i.e., the IP layer).  This effort has produced
+   two distinct protocols:
+
+     o    a mechanism for encrypting and authenticating IP datagram
+          payloads that assumes a shared secret between the sender and
+          receiver
+
+     o    a mechanism for IPsec peers to perform mutual authentication
+          and exchange keying material
+
+   The IPsec working group has defined a peer-to-peer authentication and
+   keying mechanism, IKE (RFC 2409).  One of the drawbacks of a peer-
+   to-peer protocol is that each peer must know and implement a site's
+
+
+
+Sakane, et al.              Standards Track                    [Page 36]
+
+RFC 4430                          KINK                        March 2006
+
+
+   security policy, which in practice can be quite complex.  In
+   addition, the peer-to-peer nature of IKE requires the use of Diffie-
+   Hellman (DH) to establish a shared secret.  DH, unfortunately, is
+   computationally quite expensive and prone to denial of service
+   attacks.  IKE also relies on X.509 certificates to realize scalable
+   authentication of peers.  Digital signatures are also computationally
+   expensive, and certificate-based trust models are difficult to deploy
+   in practice.  While IKE does allow for a pre-shared key, key
+   distribution is required between all peers -- an O(n^2) problem --
+   which is problematic for large deployments.
+
+14.  Acknowledgements
+
+   Many have contributed to the KINK effort, including our working group
+   chairs Derek Atkins and Jonathan Trostle.  The original inspiration
+   came from CableLab's PacketCable effort, which defined a simplified
+   version of Kerberized IPsec, including Sasha Medvinsky, Mike Froh,
+   and Matt Hur and David McGrew.  The inspiration for wholly reusing
+   IKE phase 2 is the result of Tero Kivinen's document suggesting
+   grafting Kerberos authentication onto Quick Mode.
+
+15.  References
+
+15.1.  Normative References
+
+   [BCP26]       Narten, T. and H. Alvestrand, "Guidelines for Writing
+                 an IANA Considerations Section in RFCs", BCP 26, RFC
+                 2434, October 1998.
+
+   [IKE]         Harkins, D. and D. Carrel, "The Internet Key Exchange
+                 (IKE)", RFC 2409, November 1998.
+
+   [IPDOI]       Piper, D., "The Internet IP Security Domain of
+                 Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [IPSEC]       Kent, S. and K. Seo, "Security Architecture for the
+                 Internet Protocol", RFC 4301, December 2005.
+
+   [ISAKMP]      Maughan,  D., Schertler, M., Schneider, M., and J.
+                 Turner, "Internet Security Association and Key
+                 Management Protocol (ISAKMP)", RFC 2408, November 1998.
+
+   [ISAKMP-REG]  IANA, "Internet Security Association and Key Management
+                 Protocol (ISAKMP) Identifiers",
+                 <http://www.iana.org/assignments/isakmp-registry>.
+
+   [KCRYPTO]     Raeburn, K., "Encryption and Checksum Specifications
+                 for Kerberos 5", RFC 3961, February 2005.
+
+
+
+Sakane, et al.              Standards Track                    [Page 37]
+
+RFC 4430                          KINK                        March 2006
+
+
+   [KERBEROS]    Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                 Kerberos Network Authentication Service (V5)", RFC
+                 4120, July 2005.
+
+   [RFC1964]     Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+                 RFC 1964, June 1996.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+15.2.  Informative References
+
+   [GDOI]        Baugher, M., Weis, B., Hardjono, T., and H. Harney,
+                 "The Group Domain of Interpretation", RFC 3547, July
+                 2003.
+
+   [IKEv2]       Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+                 RFC 4306, December 2005.
+
+   [PKINIT]      Zhu, L. and B. Tung, "Public Key Cryptography for
+                 Initial Authentication in Kerberos", Work in Progress,
+                 February 2006.
+
+   [REQ4KINK]    Thomas, M., "Requirements for Kerberized Internet
+                 Negotiation of Keys", RFC 3129, June 2001.
+
+   [RFC793]      Postel, J., "Transmission Control Protocol", STD 7, RFC
+                 793, September 1981.
+
+   [RFC2743]     Linn, J., "Generic Security Service Application Program
+                 Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 38]
+
+RFC 4430                          KINK                        March 2006
+
+
+Authors' Addresses
+
+   Shoichi Sakane
+   Yokogawa Electric Corporation
+   2-9-32 Nakacho, Musashino-shi,
+   Tokyo 180-8750 Japan
+
+   EMail: Shouichi.Sakane@jp.yokogawa.com
+
+
+   Ken'ichi Kamada
+   Yokogawa Electric Corporation
+   2-9-32 Nakacho, Musashino-shi,
+   Tokyo 180-8750 Japan
+
+   EMail: Ken-ichi.Kamada@jp.yokogawa.com
+
+
+   Michael Thomas
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: mat@cisco.com
+
+
+   Jan Vilhuber
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: vilhuber@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 39]
+
+RFC 4430                          KINK                        March 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sakane, et al.              Standards Track                    [Page 40]
+