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