| KINK, Kerberized Internet Negotiation of Keys |
|
|
Description | Glossary | RFCs | Publications | Obsolete RFCs |
| Protocol suite: | TCP/IP. |
| Protocol type: | Application layer protocol. |
| Multicast addresses: | |
| Ports: | 910 (UDP). |
| URI: | |
| MIME subtype: | |
| SNMP MIBs: | |
| Working groups: | kink, Kerberized Internet Negotiation of Keys. |
| Links: | IANA: KINK parameters. |
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.
| MAC header | IP header | UDP header | KINK header | Data ::: |
KINK header:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type | Version | 0 | Length | ||||||||||||||||||||||||||||
| DOI | |||||||||||||||||||||||||||||||
| Transaction ID | |||||||||||||||||||||||||||||||
| Next payload | A | 0 | Checksum length | ||||||||||||||||||||||||||||
| Payloads ::: | |||||||||||||||||||||||||||||||
| Checksum ::: | |||||||||||||||||||||||||||||||
Type.
8 bits.
Message type.
| Type | Description |
|---|---|
| 0 | reserved. |
| 1 | Create. |
| 2 | Delete. |
| 3 | Reply. |
| 4 | Gettgt. |
| 5 | Ack. |
| 6 | Status. |
| 7 - 127 | reserved. |
| 128 - 255 | private use. |
Version.
4 bits.
KINK protocol version.
Length.
16 bits.
Size of the message in bytes.
DOI, Domain of Interpretation.
32 bits.
All DOIs must be registered with the IANA in the ISAKMP Domain of Interpretation section of the isakmp registry.
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.
Transaction ID.
32 bits.
Also known as an XID.
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 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.
Next payload.
8 bits.
Indicates the type of the first payload after the message header.
| Next payload | Description |
|---|---|
| 0 | KINK_DONE. Final payload in the message. |
| 1 | KINK_AP_REQ. |
| 2 | KINK_AP_REP. |
| 3 | KINK_KRB_ERROR. |
| 4 | KINK_TGT_REQ. |
| 5 | KINK_TGT_REP. |
| 6 | KINK_ISAKMP. |
| 7 | KINK_ENCRYPT. |
| 8 | KINK_ERROR. |
| 9 - 127 | reserved. |
| 128 - 255 | private use. |
A, ACK request.
1 bit.
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.
Checksum length.
16 bits.
Size in bytess of the cryptographic checksum of the message.
If cleared to zero, the message is unauthenticated.
Payloads. Variable length.
Checksum.
Variable length.
Kerberos keyed checksum over the entire message excluding the Cksum field itself.
When any padding bytes are required between the last payload and this 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 Checksum length field is cleared to zero.
The content of this field is the output of the Kerberos 5 get_mic function.
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 field is zeroed out and the Checksum
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 this field is not allowed, except the Kerberos
internal one, which may be included in the output of the get_mic function.
Finally, the field is filled with the checksum length and the Checksum 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 the
Checksum length field, subtracting the Checksum length. The Checksum length
field is filled with the length- without-checksum value and the Checksum length 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.
RFCs:
[RFC 3129] Requirements for Kerberized Internet Negotiation of Keys.
[RFC 4430] Kerberized Internet Negotiation of Keys (KINK).
|
|
Description | Glossary | RFCs | Publications | Obsolete RFCs |