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.
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.
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.
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
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
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.
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.
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.
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.
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.