| blob | 33d3bce1ffd409e0b694ace0727b9f0630c91d12 |
8 INTERNET-DRAFT Shoichi Sakane
9 KINK Working Group Ken'ichi Kamada
10 Yokogawa Electric Corp.
11 M. Thomas
12 J. Vilhuber
13 Cisco Systems
14 Expires: November 28, 2005 May 27, 2005
17 Kerberized Internet Negotiation of Keys (KINK)
18 draft-ietf-kink-kink-07.txt
23 Status of this Memo
25 By submitting this Internet-Draft, each author represents that any
26 applicable patent or other IPR claims of which he or she is aware
27 have been or will be disclosed, and any of which he or she becomes
28 aware will be disclosed, in accordance with Section 6 of BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF), its areas, and its working groups. Note that other
32 groups may also distribute working documents as Internet-Drafts.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress".
39 The list of current Internet-Drafts can be accessed at
40 http://www.ietf.org/ietf/1id-abstracts.txt
42 The list of Internet-Draft Shadow Directories can be accessed at
43 http://www.ietf.org/shadow.html
45 This document is a submission by the KINK Working Group of the
46 Internet Engineering Task Force (IETF). Comments should be submitted
47 to the KINK mailing list (ietf-kink@vpnc.org). You can subscribe by
48 sending mail to ietf-kink-request@vpnc.org with a line in the body of
49 the mail with the word SUBSCRIBE in it.
51 Distribution of this memo is unlimited.
53 This Internet-Draft expires in November 28, 2005.
58 Thomas, Vilhuber [Page 1]
59 ^L
60 Internet-Draft KINK May 2005
63 Copyright Notice
65 Copyright (C) The Internet Society (2005). All Rights Reserved.
68 Abstract
70 This document describes the Kerberized Internet Negotiation of Keys
71 protocol (KINK) and the domain of interpretation (DOI). KINK defines
72 a low-latency, computationally inexpensive, easily managed, and
73 cryptographically protocol to establish and maintain IPsec security
74 associations (SAs) using the Kerberos authentication system. KINK
75 reuses the payloads of Quick Mode of the Internet Key Exchange (IKE),
76 which should lead to substantial reuse of existing IKE
77 implementations.
80 Conventions used in this document
82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
84 document are to be interpreted as described in RFC-2119.
86 It is assumed that the reader is familiar with the terms and concepts
87 described in the Kerberos version 5 [KERBEROS], IPsec [IPSEC] and IKE
88 [IKE].
114 Thomas, Vilhuber [Page 2]
115 ^L
116 Internet-Draft KINK May 2005
119 Table of Contents
121 1. Introduction ................................................. 5
122 2. Terminology .................................................. 5
123 3. Protocol Overview ............................................ 6
124 4. Message Flows ................................................ 6
125 4.1. Standard KINK Message Flow .............................. 6
126 4.2. GETTGT Message Flow ..................................... 7
127 4.3. CREATE Security Association ............................. 7
128 4.3.1. CREATE Key Derivation Considerations ............. 8
129 4.4. DELETE Security Association ............................. 9
130 4.4.1. Rekeying Security Associations ................... 10
131 4.4.2. Dead Peer Detection .............................. 11
132 4.5. STATUS Message Flow ..................................... 12
133 5. KINK Message Format .......................................... 12
134 5.1. KINK Payloads ........................................... 15
135 5.1.1. KINK Padding Rules ............................... 16
136 5.1.2. KINK_AP_REQ Payload .............................. 16
137 5.1.3. KINK_AP_REP Payload .............................. 17
138 5.1.4. KINK_KRB_ERROR Payload ........................... 18
139 5.1.5. KINK_TGT_REQ Payload ............................. 19
140 5.1.6. KINK_TGT_REP Payload ............................. 20
141 5.1.7. KINK_ISAKMP Payload .............................. 21
142 5.1.8. KINK_ENCRYPT Payload ............................. 22
143 5.1.9. KINK_ERROR Payload ............................... 23
144 6. KINK Quick Mode Payload Profile .............................. 23
145 6.1. General Quick Mode Differences .......................... 24
146 6.2. Security Association Payloads ........................... 24
147 6.3. Proposal and Transform Payloads ......................... 25
148 6.4. Identification Payloads ................................. 25
149 6.5. Nonce Payloads .......................................... 25
150 6.6. Notify Payloads ......................................... 25
151 6.7. Delete Payloads ......................................... 26
152 6.8. KE Payloads ............................................. 26
153 7. IPsec DOI Message Formats .................................... 27
154 7.1. REPLY Message Considerations ............................ 27
155 7.2. ACK Message Considerations .............................. 27
156 7.3. CREATE Message .......................................... 28
157 7.4. DELETE Message .......................................... 29
158 7.5. STATUS Message .......................................... 30
159 8. Key Derivation ............................................... 31
160 9. Transport Considerations ..................................... 32
161 10. Security Considerations ...................................... 32
162 10.1. Security Policy Database Considerations ................ 33
163 11. IANA Considerations .......................................... 34
164 12. Forward Compatibility Considerations ......................... 34
165 12.1. New Versions of Quick Mode ............................. 34
166 12.2. New DOI ................................................ 35
170 Thomas, Vilhuber [Page 3]
171 ^L
172 Internet-Draft KINK May 2005
175 13. Related Work ................................................. 35
176 14. Acknowledgments .............................................. 36
177 15. References ................................................... 36
178 15.1. Normative References ................................... 36
179 15.2. Informative References ................................. 37
180 Authors' Addresses ............................................... 37
181 Change History (To be removed from RFC) .......................... 38
182 Full Copyright Statement ......................................... 38
183 Intellectual Property Statement .................................. 38
226 Thomas, Vilhuber [Page 4]
227 ^L
228 Internet-Draft KINK May 2005
231 1. Introduction
233 KINK is designed to provide a secure, scalable mechanism for
234 establishing keys between communicating entities within a centrally
235 managed environment in which it is important to maintain consistent
236 security policy. The security goals of KINK are to provide privacy,
237 authentication, and replay protection of key management messages, and
238 to avoid denial of service vulnerabilities whenever possible. The
239 performance goals of the protocol are to incur a low computational
240 cost, to have low latency, to have a small footprint, and to avoid or
241 minimize the use of public key operations. In particular, the
242 protocol provides the capability to establish IPsec security
243 associations in two messages with minimal computational effort.
245 Kerberos [KERB] and [KERBEROS] provides an efficient authentication
246 mechanism for clients and servers using trusted third-party model.
247 (Kerberos also provides an mechanisms for inter-realm authentication
248 natively.) A client obtains a ticket from an online authentication
249 server (the Key Distribution Center or KDC). The ticket is then used
250 to construct a credential for authenticating the client to the
251 server. As a result of this authentication operation, the client and
252 the server will also share a secret key. KINK uses this property as
253 the basis of distributing keys for IPsec.
255 The central key management provided by Kerberos is efficient because
256 it limits computational cost and limits complexity versus IKE's [IKE]
257 necessity of using public key cryptography. Initial authentication
258 to the KDC may be performed using either symmetric keys or asymmetric
259 keys using [PKINIT]; however, subsequent requests for tickets, as
260 well as authenticated exchanges between client and server always
261 utilize symmetric cryptography. Therefore, public key operations (if
262 any) are limited and are amortized over the lifetime of the initial
263 authentication operation to the Kerberos KDC. For example, a client
264 may use a single public key exchange with the KDC to efficiently
265 establish multiple security associations with many other servers in
266 the extended realm of the KDC. Kerberos also scales better than
267 direct peer to peer keying when symmetric keys are used. The reason
268 is that since the keys are stored in the KDC, the number of principal
269 keys is O(n) rather than O(n*m), where "n" is the number of clients
270 and "m" is the number of servers. Kerberos, like any internet
271 protocol, does have its own security considerations. You can find
272 them discussed in [KERBEROS] and [KERB].
275 2. Terminology
277 Editor's comment: remain it for the order of sections referred from
282 Thomas, Vilhuber [Page 5]
283 ^L
284 Internet-Draft KINK May 2005
287 the issue list.
290 3. Protocol Overview
292 KINK is a command/response protocol which can create, delete, and
293 maintain IPsec security associations. Each command or response
294 contains a common header along with a set of type-length-value
295 payloads which are constrained according to the type of command or
296 response. KINK itself is a stateless protocol in that each command
297 or response does not require storage of hard state for KINK. This is
298 in contrast to IKE's use of Main Mode to first establish an ISAKMP
299 security association followed by subsequent Quick Mode exchanges.
301 KINK uses Kerberos mechanisms to provide mutual authentication and
302 replay protection. For security association establishment, KINK
303 provides privacy of the payloads which follow the Kerberos
304 authenticator. KINK's design mitigates denial of service attacks by
305 requiring authenticated exchanges before the use of any public key
306 operations and the installation of any state. KINK also provides the
307 means of using Kerberos User-to-User mechanisms when there isn't a
308 key shared between the server and the KDC. This is typically, but
309 not limited to, the case with IPsec peers using [PKINIT] for initial
310 authentication.
312 KINK directly reuses Quick Mode payloads defined in section 5.5 of
313 [IKE], with some minor changes and omissions. In most cases, KINK
314 exchanges are a single command and its response. The exception is
315 that the CREATE command may have a third message. When the responder
316 disagrees with the optimistic proposal, it requests the third
317 message, an acknowledgement, to the initiator in order to complete a
318 non-optimistic keying. KINK also provides rekeying and dead peer
319 detection.
322 4. Message Flows
324 KINK message flows all follow the same pattern between the two peers:
325 a command, a response, and a possible acknowledgment with CREATE's.
326 The actual Kerberos KDC traffic here is for illustrative purposes
327 only. In practice, when a principal obtains various tickets is a
328 subject of Kerberos and local policy consideration. In these flows,
329 we assume that A and B both have TGT's from their KDC.
332 4.1. Standard KINK Message Flow
338 Thomas, Vilhuber [Page 6]
339 ^L
340 Internet-Draft KINK May 2005
343 A B KDC
344 ------ ------ ---
345 1 COMMAND------------------->
347 2 <------------------REPLY
349 3 [ ACK---------------------> ]
351 Figure 1: KINK Message Flow
354 4.2. GETTGT Message Flow
356 If the initiator determines that it will not be able to get a normal
357 service ticket for the responder (e.g., B is a client principal), it
358 MUST first fetch the TGT from the responder in order to get a User-
359 to-User service ticket:
361 A B KDC
362 ------ ------ ---
363 1 GETTGT+KRB_TGT_REQ------->
365 2 <-------REPLY+KRB_TGT_REP
367 3 TGS-REQ+TGT(B)------------------------------------->
369 4 <--------------------------------------------TGS-REP
371 Figure 2: GETTGT Message Flow
374 4.3. CREATE Security Association
376 This flow instantiates a security association. The CREATE command
377 takes an "optimistic" approach where security associations are
378 initially created on the expectation that the responder will choose
379 the initial proposed payload. The optimistic proposal is defined as
380 the first transform of the first proposal of the first conjugate.
381 The initiator MUST check to see if the optimistic proposal was
382 selected by comparing all transforms and attributes which MUST be
383 identical from those in the initiator's optimistic proposal with the
384 exceptions of LIFE_KILOBYTES and LIFE_SECONDS. Each of these
385 attributes MAY be set to a lower value by the responder and still
386 expect optimistic keying, but MUST NOT be set to a higher value which
387 MUST generate an error.
389 CREATE'ing a security association on an existing SPI is an error in
390 KINK and MUST be rejected with an ISAKMP notification of INVALID-SPI.
394 Thomas, Vilhuber [Page 7]
395 ^L
396 Internet-Draft KINK May 2005
399 A B KDC
400 ------ ------ ---
402 A creates initial inbound SA (B->A)
404 1 CREATE+ISAKMP------------>
406 B creates inbound SA to A (A->B). If B chooses A's optimistic
407 proposal, it creates the outbound SA as well (B->A).
409 2 <------------REPLY+ISAKMP
411 A creates outbound SA and modifies inbound SA if it first
412 proposal wasn't acceptable.
414 3 [ ACK--------------------> ]
416 [ B creates the outbound SA to A (B-A). ]
418 Figure 3: CREATE Message Flow
420 The security associations are instantiated as follows: In step one
421 host A creates an inbound security association in its security
422 association database from B->A using the optimistic proposal in the
423 ISAKMP SA proposal. It is then ready to receive any messages from B.
424 A then sends the CREATE message to B. If B agrees to A's optimistic
425 proposal, B instantiates a security association in its database from
426 A->B. B then instantiates the security association from B->A. It
427 then sends a REPLY to A without a NONCE payload and without
428 requesting an ACK. If B does not choose the first proposal, it sends
429 the actual choice in the REPLY. It SHOULD send the optional NONCE
430 payload (as it does not increase message count and generally
431 increases entropy sources) and MUST request that the REPLY be
432 acknowledged. Upon receipt of the REPLY, A modifies the inbound
433 security association as necessary, instantiates the security
434 association from A->B, If B requested an ACK, A now sends the ACK
435 message. Upon receipt of the ACK, B installs the final security
436 association from B->A.
438 Note: if B adds a nonce, or does not choose the first proposal, it
439 MUST request an ACK so that it can install the final outbound
440 security association. The initiator MUST always generate an ACK if
441 the ACKREQ bit is set in the KINK header, even if it believes that
442 the responder was in error.
445 4.3.1. CREATE Key Derivation Considerations
450 Thomas, Vilhuber [Page 8]
451 ^L
452 Internet-Draft KINK May 2005
455 The CREATE command's optimistic approach allows a security
456 association to be created in two messages rather than three. The
457 implication of a two-message exchange is that B will not contribute
458 to the key since A must set up the inbound security association
459 before it receives any additional keying material from B. Under
460 normal circumstances this may be suspect, however KINK takes
461 advantage of the fact that the KDC provides a reliable source of
462 randomness which is used in key derivation. In many cases, this will
463 provide an adequate session key so that B will not require an
464 acknowledgment. Since B is always at liberty to contribute to the
465 keying material, this is strictly a tradeoff between the key strength
466 versus the number of messages, which KINK implementations may decide
467 as a matter of policy.
470 4.4. DELETE Security Association
472 The DELETE command deletes an existing security association. The DOI
473 specific payloads describe the actual security association to be
474 deleted. For the IPSEC DOI, those payloads will include an ISAKMP
475 payload containing the SPI to be deleted in each direction.
477 A B KDC
478 ------ ------ ---
480 A deletes outbound SA to B
482 1 DELETE+ISAKMP------------>
484 B deletes inbound and outbound SA to A
486 2 <-------------REPLY+ISAKMP
488 A deletes inbound SA to B
490 Figure 4: DELETE Message Flow
492 The DELETE command takes a "pessimistic" approach which does not
493 delete incoming security associations until it receives
494 acknowledgment that the other host has received the DELETE. The
495 exception to the pessimistic approach is if the initiator wants to
496 immediately cease all activity on an incoming SA. In this case, it
497 MAY delete the incoming SA as well in step one. If the receiver
498 cannot find an appropriate SPI to delete, it MUST return an ISAKMP
499 INVALID_SPI notification which also serves to inform the initiator
500 that it can delete the incoming SA. KINK does not allow half open
501 security associations; thus upon receiving a DELETE, the responder
502 MUST delete its security associations, and MUST reply with ISAKMP
506 Thomas, Vilhuber [Page 9]
507 ^L
508 Internet-Draft KINK May 2005
511 delete notification messages if the SPI is found, or ISAKMP
512 INVALID_SPI if it is not.
514 A race condition with DELETE exists. Packets in flight while the
515 DELETE operation is taking place may, due to network reordering, etc,
516 arrive after the diagrams above recommend deleting the incoming
517 security association. A KINK implementation SHOULD implement a grace
518 timer which SHOULD be set to a period of at least two times the
519 average round trip time, or to a configurable value. A KINK
520 implementation MAY choose to set the grace period to zero at
521 appropriate times to delete a security association ungracefully. The
522 behavior described here loosely mimics the behavior of the TCP
523 [RFC793] flags FIN and RST.
526 4.4.1. Rekeying Security Associations
528 KINK requires the initiator of a security association to be
529 responsible for rekeying a security association. The reason is
530 twofold: the first is to prevent needless duplication of security
531 associations as the result of collisions due to an initiator and
532 responder both trying to renew an existing security association. The
533 second reason is due to the client/server nature of Kerberos
534 exchanges which expects the client to get and maintain tickets.
535 While KINK requires that a KINK host is able to get and maintain
536 tickets, in practice it is often advantageous for servers to wait for
537 clients to initiate sessions so that they do not need to maintain a
538 large ticket cache.
540 There are no special semantics for rekeying security associations in
541 KINK. That is, in order to rekey an existing security association,
542 the initiator must CREATE a new security association followed by
543 either DELETE'ing the old security association or letting it time
544 out. When identical flow selectors are available on different
545 security associations, KINK implementations SHOULD choose the
546 security association most recently created. It should be noted that
547 KINK avoids most of the problems of [IKE] rekeying by having a
548 reliable delete mechanism.
550 Normally a KINK implementation which rekeys existing security
551 associations will try to rekey the security association ahead of a
552 hard SA expiration. We call this time the rekey time Trekey. In
553 order to avoid synchronization with similar implementations, KINK
554 initiators MUST randomly pick a rekeying time between Trekey and the
555 SA expiration time minus the amount of time it would take to go
556 through a full retransmission time cycle, Tretrans. Trekey SHOULD be
562 Thomas, Vilhuber [Page 10]
563 ^L
564 Internet-Draft KINK May 2005
567 set at least twice as high as Tretrans.
570 4.4.2. Dead Peer Detection
572 In order to determine that a KINK peer has lost its security database
573 information, KINK peers MUST record the current epoch for which they
574 have valid security association information for a peer and reflect
575 that epoch in each AP-REQ and AP-REP message. When a KINK peer
576 creates state for a given security association, it MUST also record
577 the principal's epoch as well. If it discovers on a subsequent
578 message that the principal's epoch has changed, it MUST consider all
579 security associations created by that principal as invalid, and take
580 some action such as tearing those SA's down.
582 While a KINK peer SHOULD use feedback from routing (in the form of
583 ICMP messages) as a trigger to check whether the peer is still alive
584 or not, a KINK peer MUST NOT conclude the peers is dead simply based
585 on unprotected routing information (said ICMP messages).
587 If there is suspicion that a peer may be dead (based on any
588 information available to the KINK peer, including lack of IPsec
589 traffic, etc), the KINK STATUS message SHOULD be used to coerce an
590 acknowledgment out of the peer. Since nothing is negotiated about
591 dead peer detection in KINK, each peer can decide its own metric for
592 'suspicion' and also what time-outs to use before declaring a peer
593 dead due to lack of response to the STATUS message. This is
594 desirable, and does not break interoperability.
596 The STATUS message has a two-fold effect: First, it elicits a
597 cryptographically secured (and replay-protected) response from the
598 peer, which tells us whether the peer is reachable/alive or not.
599 Further, it carries the epoch number of the peer, so we know whether
600 the peer has rebooted and lost all state or not. This is crucial to
601 the KINK protocol: In IKE, if a peer reboots, we lose all
602 cryptographic context, and no cryptographically secure communication
603 is possible without renegotiating keys. In KINK, due to Kerberos
604 tickets, we can communicate securely with a peer, even if the peer
605 rebooted, as the shared cryptographic key used is carried in the
606 Kerberos ticket. Thus, active cryptographic communication is not an
607 indication that the peer has not rebooted and lost all state, and the
608 epoch is needed.
610 Assume a Peer A sending a STATUS and a peer B sending the REPLY (see
611 section 4.5). Peer B MAY assume that the sender is alive, and the
612 epoch in the STATUS message will indicate whether the peer A has lost
613 state or not. Peer B MUST acknowledge the STATUS message with a
614 REPLY message, as described in section 4.5.
618 Thomas, Vilhuber [Page 11]
619 ^L
620 Internet-Draft KINK May 2005
623 The REPLY message will indicate to peer A that the peer is alive, and
624 the epoch in the REPLY will indicate whether peer B has lost its
625 state or not. If peer A does not receive a REPLY message from peer B
626 in a suitable timeout, peer A MAY send another STATUS message. It is
627 up to peer A to decide how aggressively to declare peer B dead. The
628 level of aggressiveness may depend on many factors such as rapid fail
629 over versus number of messages sent by nodes with large numbers of
630 security associations.
632 Note that peer B MUST NOT make any inferences about a lack of STATUS
633 message from peer A. Peer B MAY use a STATUS message from peer A as
634 indication of A's aliveness, but peer B MUST NOT expect another
635 STATUS message at any time (i.e. Dead Peer detection is not periodic
636 keepalives).
638 Strategies for sending STATUS messages: Peer A may decide to send a
639 STATUS message only after a prolonged period where no traffic was
640 sent in either direction over the IPsec SA's with the peer. Once
641 there is traffic, peer A may want to know if the traffic going into a
642 black hole, and send a STATUS message. Alternatively, peer A may use
643 an idle timer to detect lack of traffic with the peer, and send
644 STATUS messages in the quiet phase to make sure the peer is still
645 alive for when traffic needs to finally be sent.
648 4.5. STATUS Message Flow
650 At any point, a sender may send status, normally in the form of DOI
651 specific payloads to its peer. In the case of the IPsec DOI, these
652 are generally in the form of ISAKMP Notification Payloads.
654 A B KDC
655 ------ ------ ---
657 1 STATUS+ISAKMP------------>
659 2 <-------------REPLY+ISAKMP
661 Figure 5: STATUS Message Flow
664 5. KINK Message Format
666 All values in KINK are formatted in network byte order (Most
667 Significant Byte first). The RESERVED fields MUST be set to zero (0)
668 when a packet is sent. The receiver MUST ignore these fields.
674 Thomas, Vilhuber [Page 12]
675 ^L
676 Internet-Draft KINK May 2005
679 0 1 2 3
680 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
681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
682 | Type | MjVer | MnVer | Length |
683 +---------------+---------------+---------------+---------------+
684 | Domain of Interpretation (DOI) |
685 +-------------------------------+-------------------------------+
686 | Transaction ID (XID) |
687 +---------------+---------------+-+-----------------------------+
688 | CksumLen | NextPayload |A| RESERVED |
689 +---------------+---------------+-+-----------------------------+
690 | |
691 ~ Cksum ~
692 | |
693 +-------------------------------+-------------------------------+
694 | |
695 ~ A series of payloads ~
696 | |
697 +-------------------------------+-------------------------------+
699 Figure 6: Format of a KINK message
701 Fields:
703 o Type (1 octet) - The type of message of this packet
705 Type Value
706 ----- -----
707 RESERVED 0
708 CREATE 1
709 DELETE 2
710 REPLY 3
711 GETTGT 4
712 ACK 5
713 STATUS 6
715 o MjVer (4 bits) - Major protocol version number. This MUST be set
716 to 1.
718 o MnVer (4 bits) - Minor protocol version number. This MUST be set
719 to 0.
721 o Length (2 octets) - Length of the message in octets. Note that it
722 is legal within KINK to omit the last bytes of padding in the last
723 payload in the overall length.
725 o DOI (4 octets) - The domain of interpretation. All DOI's must be
726 registered with the IANA in the "Assigned Numbers" RFC [STD-2].
730 Thomas, Vilhuber [Page 13]
731 ^L
732 Internet-Draft KINK May 2005
735 Defined values are specified by the ISAKMP Domain of
736 Interpretation section in the IANA isakmp-registry [ISAKMP-REG].
737 The IANA Assigned Number for the Internet IP Security DOI [IPDOI]
738 is one (1). This field defines the context of all sub-payloads in
739 this message. If sub-payloads have a DOI field (example: Security
740 Association Payload), then the DOI in that sub-payload MUST be
741 checked against the DOI in this header, and the values MUST be the
742 same.
744 o XID (4 octets) - The transaction ID. A KINK transaction is bound
745 together by a transaction ID which is created by the command
746 initiator and replicated in subsequent messages in the
747 transaction. A transaction is defined as a command, a reply, and
748 an optional acknowledgment. Transaction ID's are used by the
749 initiator to discriminate between multiple outstanding requests to
750 a responder. It is not used for replay protection because that
751 functionality is provided by Kerberos. The value of XID is chosen
752 by the initiator and MUST be unique with all outstanding
753 transactions. XID's MAY be constructed by using a monotonic
754 counter, or random number generator.
756 o CksumLen (2 octets) -- CksumLen is the length in octets of the
757 keyed hash of the message. A CksumLen of zero implies that the
758 message is unauthenticated. Note that as with payload padding,
759 the length here denotes the actual number of octets of the
760 checksum structure not including any padding required.
762 o NextPayload (1 octet) -- Indicates the type of the first payload
763 after the message header.
765 o A (1 bit) -- ACK Request. Set to one if the responder requires an
766 explicit acknowledgment that a REPLY was received. An initiator
767 MUST NOT set this flag, nor should any other command other than
768 CREATE request an ACK and then only when the optimistic proposal
769 is not chosen.
771 o RESERVED (15 bits) -- Reserved and MUST be zero on send, MUST be
772 ignored by a receiver.
774 o Cksum (variable) - Keyed checksum over the entire message. This
775 field MUST always be present whenever a key is available via an
776 AP-REQ or AP-REP payload. The key used MUST be the session key in
777 the ticket. When a key is not available, this field is not
778 present, and the CksumLen field is set to zero. The hash
779 algorithm used is the same as specified in the etype for the
780 Kerberos session key in the Kerberos ticket. If the etype does
781 not specify a hash algorithm, the message MUST be rejected.
786 Thomas, Vilhuber [Page 14]
787 ^L
788 Internet-Draft KINK May 2005
791 The format of the Cksum field is as follows:
793 0 1 2 3
794 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
795 +---------------+---------------+---------------+---------------+
796 | checksum (variable) ~ padding (variable) |
797 +---------------+---------------+---------------+---------------+
799 Figure 7: KINK Checksum
801 To compute the checksum, the checksum field is zeroed out and the
802 appropriate algorithm is run over the entire message (as given by the
803 Length field in the KINK header), and placed in the Checksum field.
804 To verify the checksum, the checksum is saved, and the checksum field
805 is zeroed out. The checksum algorithm is run over the message, and
806 the result is compared with the saved version. If they do not match,
807 the message MUST be dropped.
809 The KINK header is followed immediately by a series of
810 Type/Length/Value fields, defined in the next section.
813 5.1. KINK Payloads
815 Immediately following the header, there is a list of
816 Type/Length/Value (TLV) payloads. There can be any number of
817 payloads following the header. Each payload MUST begin with a
818 payload header. Each payload header is built on the generic payload
819 header. Any data immediately follows the generic header. Payloads
820 are all implicitly padded to 4-octet boundaries, though the payload
821 length field MUST accurately reflect the actual number of octets in
822 the payload.
824 0 1 2 3
825 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
826 +---------------+---------------+---------------+---------------+
827 | Next Payload | RESERVED | Payload Length |
828 +---------------+---------------+---------------+---------------+
829 | value (variable) |
830 +---------------+---------------+---------------+---------------+
832 Figure 8: Format of a KINK payload
834 Fields:
836 o NextPayload (1 octets) - The type of the next payload
838 NextPayload Number
842 Thomas, Vilhuber [Page 15]
843 ^L
844 Internet-Draft KINK May 2005
847 ---- ------
848 KINK_DONE 0 (same as ISAKMP_NEXT_NONE)
849 KINK_AP_REQ KINK_ISAKMP_PAYLOAD_BASE+0
850 KINK_AP_REP KINK_ISAKMP_PAYLOAD_BASE+1
851 KINK_KRB_ERROR KINK_ISAKMP_PAYLOAD_BASE+2
852 KINK_TGT_REQ KINK_ISAKMP_PAYLOAD_BASE+3
853 KINK_TGT_REP KINK_ISAKMP_PAYLOAD_BASE+4
854 KINK_ISAKMP KINK_ISAKMP_PAYLOAD_BASE+5
855 KINK_ENCRYPT KINK_ISAKMP_PAYLOAD_BASE+6
856 KINK_ERROR KINK_ISAKMP_PAYLOAD_BASE+7
858 NextPayload type KINK_DONE denotes that the current payload is the
859 final payload in the message.
861 Note: the payload types are taken from the ISAKMP registry for
862 payload types. See the IANA consideration section for the value
863 of KINK_ISAKMP_PAYLOAD_BASE.
866 o RESERVED (1 octet) - Reserved and MUST be zero on send, MUST be
867 ignored by a receiver.
869 o Length (2 octets) - The length of this payload, including the Type
870 and Length fields.
872 o Value (variable) - This value of this field depends on the Type.
875 5.1.1. KINK Padding Rules
877 KINK has the following rules regarding alignment and padding:
879 o All length fields MUST reflect the actual number of octets in the
880 structure; i.e., they do not account for padding bytes.
882 o Between KINK payloads, checksums, headers, or any other variable
883 length data, the adjacent fields MUST be aligned on 4-octet
884 boundaries.
886 o Variable length fields MUST always start immediately after the
887 last octet of the previous field. I.e., they are not padded to a
888 4-octet boundary.
891 5.1.2. KINK_AP_REQ Payload
893 The KINK_AP_REQ payload relays a Kerberos AP-REQ to the responder.
894 The AP-REQ MUST request mutual authentication. The service that the
898 Thomas, Vilhuber [Page 16]
899 ^L
900 Internet-Draft KINK May 2005
903 KINK peer SHOULD request is "kink/fqdn@REALM" where "kink" is the
904 KINK IPsec service, "fqdn" is the fully qualified domain name of the
905 service host, and REALM is the Kerberos realm of the service. The
906 exception to this rule is when User-to-User service is requested in
907 which case the service name MUST be the service returned in the
908 GETTGT response payload.
910 The value field of this payload has the following format:
912 0 1 2 3
913 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
914 +---------------+---------------+---------------+---------------+
915 | Next Payload | RESERVED | Payload Length |
916 +---------------+---------------+---------------+---------------+
917 | EPOCH |
918 +---------------------------------------------------------------+
919 | |
920 ~ KRB_AP_REQ ~
921 | |
922 +---------------------------------------------------------------+
924 Figure 9: KINK_AP_REQ Payload
926 Fields:
928 o Next Payload, RESERVED, Payload Length - defined in the beginning
929 of this section
931 o EPOCH - the absolute time at which the creator of the AP-REQ has
932 valid security association information. Typically, this is when
933 the KINK keying daemon started if it does not retain security
934 association information across different restarts. The format of
935 this field is network order encoding of the standard POSIX four-
936 octet time stamp.
938 o KRB_AP_REQ - The value field of this payload contains a raw
939 Kerberos KRB_AP_REQ.
942 5.1.3. KINK_AP_REP Payload
944 The KINK_AP_REP payload relays a Kerberos AP-REP to the initiator.
945 The AP-REP MUST be checked for freshness as described in [KERBEROS].
947 The value field of this payload has the following format:
954 Thomas, Vilhuber [Page 17]
955 ^L
956 Internet-Draft KINK May 2005
959 0 1 2 3
960 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
961 +---------------+---------------+---------------+---------------+
962 | Next Payload | RESERVED | Payload Length |
963 +---------------+---------------+---------------+---------------+
964 | EPOCH |
965 +---------------------------------------------------------------+
966 | |
967 ~ KRB_AP_REP ~
968 | |
969 +---------------------------------------------------------------+
971 Figure 10: KINK_AP_REP Payload
973 Fields:
975 o Next Payload, RESERVED, Payload Length - defined in the beginning
976 of this section
978 o EPOCH - the absolute time at which the creator of the AP-REP has
979 valid security association information. Typically, this is when
980 the KINK keying daemon started if it does not retain security
981 association information across different restarts. The format of
982 this field is network order encoding of the standard POSIX four-
983 octet time stamp.
985 o KRB_AP_REP - The value field of this payload contains a raw
986 Kerberos KRB_AP_REP.
989 5.1.4. KINK_KRB_ERROR Payload
991 The KINK_KRB_ERROR payload relays Kerberos type errors back to the
992 initiator. The receiver MUST be prepared to receive any valid
993 [KERBEROS] error type, but the sender SHOULD send only the following
994 errors:
996 KRB_AP_ERR_BAD_INTEGRITY
997 KRB_AP_ERR_TKT_EXPIRED
998 KRB_AP_ERR_SKEW
999 KRB_AP_ERR_NOKEY
1000 KRB_AP_ERR_BADKEYVER
1003 KINK implementations MUST make use of a KINK Cksum field when
1004 returning KINK_KRB_ERROR and the appropriate service key is
1005 available.
1010 Thomas, Vilhuber [Page 18]
1011 ^L
1012 Internet-Draft KINK May 2005
1015 Note that KINK does not make use of the text or e_data field of the
1016 Kerberos error message, though a compliant KINK implementation MUST
1017 be prepared to receive them and MAY log them.
1019 The value field of this payload has the following format:
1021 0 1 2 3
1022 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
1023 +---------------+---------------+---------------+---------------+
1024 | Next Payload | RESERVED | Payload Length |
1025 +---------------+---------------+---------------+---------------+
1026 | |
1027 ~ KRB-ERROR ~
1028 | |
1029 +---------------------------------------------------------------+
1031 Figure 11: KINK_KRB_ERROR Payload
1033 Fields:
1035 o Next Payload, RESERVED, Payload Length - defined in the beginning
1036 of this section
1038 o KRB-ERROR - The value field of this payload contains a raw
1039 Kerberos KRB-ERROR.
1042 5.1.5. KINK_TGT_REQ Payload
1044 The KINK_TGT_REQ payload provides a means to get a TGT from the peer
1045 in order to obtain a User-to-User service ticket from the KDC
1047 The value field of this payload has the following format:
1049 0 1 2 3
1050 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
1051 +---------------+---------------+---------------+---------------+
1052 | Next Payload | RESERVED | Payload Length |
1053 +---------------+---------------+---------------+---------------+
1054 | RealmNameLen | RealmName (variable) ~
1055 +---------------+---------------+---------------+---------------+
1056 | |
1057 ~ RealmName(variable) ~
1058 | |
1059 +---------------------------------------------------------------+
1061 Figure 12: KINK_TGT_REQ Payload
1066 Thomas, Vilhuber [Page 19]
1067 ^L
1068 Internet-Draft KINK May 2005
1071 Fields:
1073 o Next Payload, RESERVED, Payload Length - defined in the beginning
1074 of this section
1076 o RealmNameLen - The length of the realm name that follows
1078 o RealmName - The realm name that the responder should return a TGT
1079 for. The responder MUST return a ticket for the principal
1080 krbtgt/REALM@REALM to the initiator so that a User-to-User service
1081 ticket can be obtained by the initiator.
1083 If the responder is unable to get a TGT for the domain, it must reply
1084 with a KINK_KRB_ERROR payload type.
1087 5.1.6. KINK_TGT_REP Payload
1089 The value field of this payload contains the TGT requested in a
1090 previous KINK_TGT_REP command.
1092 0 1 2 3
1093 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
1094 +---------------+---------------+---------------+---------------+
1095 | Next Payload | RESERVED | Payload Length |
1096 +---------------+---------------+---------------+---------------+
1097 | PrincNameLen | PrincName (variable) ~
1098 +---------------+---------------+---------------+---------------+
1099 | |
1100 ~ PrincName(variable) +---------------+
1101 | ~ padding |
1102 +---------------------------------------------------------------+
1103 | TGTlength | TGT (variable) |
1104 +-------------------------------+---------------+---------------+
1105 | ~
1106 ~ TGT (variable) +---------------+
1107 | ~ padding |
1108 +---------------------------------------------------------------+
1110 Figure 13: KINK_TGT_REP Payload
1112 Fields:
1114 o Next Payload, RESERVED, Payload Length - defined in the beginning
1115 of this section
1117 o PrincNameLen - The length of the principal name that immediately
1118 follows
1122 Thomas, Vilhuber [Page 20]
1123 ^L
1124 Internet-Draft KINK May 2005
1127 o PrincName - The client principal that the initiator should request
1128 a User-to-User service ticket for.
1130 o TGTlength - The length of TGT that immediately follows
1132 o TGT - the DER encoded TGT of the responder
1135 5.1.7. KINK_ISAKMP Payload
1137 The value field of this payload has the following format:
1139 0 1 2 3
1140 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
1141 +---------------+---------------+---------------+---------------+
1142 | Next Payload | RESERVED | Payload Length |
1143 +---------------+-------+-------+---------------+---------------+
1144 | InnerNextPload| QMMaj | QMMin | RESERVED |
1145 +---------------+-------+-------+---------------+---------------+
1146 | Quick Mode Payloads (variable) |
1147 +---------------+---------------+---------------+---------------+
1149 Figure 14: KINK_ISAKMP Payload
1151 Fields:
1153 o Next Payload, RESERVED, Payload Length - defined in the beginning
1154 of this section
1156 o InnerNextPload - First payload type of the inner series of ISAKMP
1157 payloads.
1159 o QMMaj - The major version of the inner payloads. MUST be set to
1160 1.
1162 o QMMin - The minor version of the inner payloads. MUST be set to
1163 0.
1165 The KINK_ISAKMP payload encapsulates the IKE Quick Mode (phase two)
1166 payloads to take the appropriate action dependent on the KINK
1167 command. There may be any number of KINK_ISAKMP payloads within a
1168 single KINK message. While IKE is somewhat fuzzy about whether
1169 multiple different SA's may be created within a single IKE message,
1170 KINK explicitly requires that a new ISAKMP header be used for each
1171 discrete SA operation. In other words, a KINK sender MUST NOT send
1172 multiple quick mode transactions within a single KINK_ISAKMP payload.
1174 The purpose of the Quick Mode version is to allow backward
1178 Thomas, Vilhuber [Page 21]
1179 ^L
1180 Internet-Draft KINK May 2005
1183 compatibility with IKE and ISAKMP if there are subsequent revisions.
1184 At the present time, the Quick Mode major and minor versions are set
1185 to one and zero (1.0) respectively. These versions do not correspond
1186 to the ISAKMP version in the ISAKMP header. A compliant KINK
1187 implementation MUST support receipt of 1.0 payloads. It MAY support
1188 subsequent versions (both sending and receiving), and SHOULD provide
1189 a means to resort back to Quick Mode version 1.0 if the KINK peer is
1190 unable to process future versions. A compliant KINK implementation
1191 MUST NOT mix Quick Mode versions in any given transaction.
1194 5.1.8. KINK_ENCRYPT Payload
1196 The KINK_ENCRYPT payload encapsulates other payloads and is encrypted
1197 using the encryption algorithm specified by the etype of the session
1198 key. This payload MUST be the final payload in the message. KINK
1199 encrypt payloads MUST be encrypted before the final KINK checksum is
1200 applied.
1202 0 1 2 3
1203 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
1204 +---------------+---------------+---------------+---------------+
1205 | Next Payload | RESERVED | Payload Length |
1206 +---------------+---------------+---------------+---------------+
1207 | InnerNextPload| RESERVED2 |
1208 +---------------+---------------+---------------+---------------+
1209 | Payload (variable) |
1210 +---------------+---------------+---------------+---------------+
1212 Figure 15: KINK_ENCRYPT Payload
1214 Fields:
1216 o Next Payload, RESERVED, Payload Length - defined in the beginning
1217 of this section. The Next Payload field must be KINK_DONE (0).
1219 o InnerNextPload (variable) - First payload type of the inner series
1220 of encrypted KINK payloads.
1222 o RESERVED2 - reserved and must be zero
1224 Note: the coverage of the encrypted data begins at InnerNextPload so
1225 that first payload's type is kept confidential. Thus, the number of
1226 encrypted octets is PayloadLength - 4.
1228 The format of the encryption payload uses the normal [KERBEROS]
1229 semantics of prepending a crypto-specific initialization vector and
1230 padding the entire message out to the crypto-specific number of
1234 Thomas, Vilhuber [Page 22]
1235 ^L
1236 Internet-Draft KINK May 2005
1239 bytes. For example, with DES-CBC, the initialization vector will be
1240 8 octets long, and the entire message will be padded to an 8-octet
1241 boundary. Note that KINK Encrypt payload MUST NOT include a checksum
1242 since this is redundant with the message integrity checksum in the
1243 KINK header.
1246 5.1.9. KINK_ERROR Payload
1248 The KINK_ERROR payload type provides a protocol level mechanism of
1249 returning an error condition. This payload should not be used for
1250 either Kerberos generated errors, or DOI specific errors which have
1251 their own payloads defined. The error code is in network order.
1253 0 1 2 3
1254 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
1255 +---------------+---------------+---------------+---------------+
1256 | Next Payload | RESERVED | Payload Length |
1257 +---------------+---------------+---------------+---------------+
1258 | ErrorCode |
1259 +---------------+---------------+---------------+---------------+
1261 Figure 16: KINK_ERROR Payload
1263 Fields:
1265 o Next Payload, RESERVED, Payload Length - defined in the beginning
1266 of this section
1268 o ErrorCode - one of the following error values, network ordered:
1270 ErrorCode Number Purpose
1271 --------- ------ -------------------
1272 KINK_OK 0 No error detected
1273 KINK_PROTOERR 1 The message was malformed
1274 KINK_INVDOI 2 Invalid DOI
1275 KINK_INVMAJ 3 Invalid Major Version
1276 KINK_INVMIN 4 Invalid Minor Version
1277 KINK_INTERR 5 An unrecoverable internal error
1278 KINK_BADQMVERS 6 Unsupported Quick Mode Version
1279 RESERVED 7 - 8191
1280 Private Use 8192 - 16383
1283 6. KINK Quick Mode Payload Profile
1285 KINK directly uses ISAKMP payloads to negotiate security
1286 associations. In particular, KINK uses IKE phase II payload types
1290 Thomas, Vilhuber [Page 23]
1291 ^L
1292 Internet-Draft KINK May 2005
1295 (aka Quick Mode). In general, there should be very few changes
1296 necessary to an IKE implementation to establish the security
1297 associations, and unless there is a note to the contrary in the memo,
1298 all capabilities and requirements in [IKE] MUST be supported. IKE
1299 Phase I payloads MUST NOT be sent.
1301 Unlike IKE, KINK defines specific commands for creation, deletion,
1302 and status of security associations, mainly to facilitate predictable
1303 SA creation/deletion (see section 4.3 and 4.4). As such, KINK places
1304 certain restrictions on what payloads may be sent with which
1305 commands, and some additional restrictions and semantics of some of
1306 the payloads. Implementors should refer to [IKE] and [ISAKMP] for
1307 the actual format and semantics. If a particular IKE phase II
1308 payload is not mentioned here, it means that there are no differences
1309 in its use.
1312 6.1. General Quick Mode Differences
1315 o The Security Association Payload header for IP is defined in
1316 [IPDOI] section 4.6.1. For this memo, the Domain of
1317 Interpretation MUST be set to 1 (IPsec) and the Situation bitmap
1318 MUST be set to 1 (SIT_IDENTITY_ONLY). All other fields are
1319 omitted (because SIT_IDENTITY_ONLY is set).
1321 o KINK also expands the semantics of IKE in it defines an
1322 optimistic proposal for CREATE commands to allow SA creation to
1323 complete in two messages.
1325 o IKE Quick Mode (phase 2) uses the hash algorithm used in main
1326 mode (phase 1) to generate the keying material. KINK MUST use
1327 the hashing algorithm specified in the session ticket's etype.
1329 o KINK does not use the HASH payload at all.
1331 o KINK allows the NONCE payload Nr to be optional to facilitate
1332 optimistic keying.
1335 6.2. Security Association Payloads
1337 KINK supports the following security association attributes from
1338 [IPDOI]:
1340 class value type
1341 -------------------------------------------------
1342 SA Life Type 1 B
1346 Thomas, Vilhuber [Page 24]
1347 ^L
1348 Internet-Draft KINK May 2005
1351 SA Life Duration 2 V
1352 Encapsulation Mode 4 B
1353 Authentication Algorithm 5 B
1354 Key Length 6 B
1355 Key Rounds 7 B
1357 Refer to [IPDOI] for the actual definitions for these attributes.
1360 6.3. Proposal and Transform Payloads
1362 KINK directly uses the Proposal and Transform payloads with no
1363 differences. KINK, however, places additional relevance to the first
1364 proposal and first transform of each conjugate for optimistic keying.
1367 6.4. Identification Payloads
1369 The Identification payload carries information that is used to
1370 identify the traffic that is to be protected using the keys exchanges
1371 in this memo. KINK restricts the ID types to the following values:
1374 ID Type Value
1375 ------- -----
1376 ID_IPV4_ADDR 1
1377 ID_IPV4_ADDR_SUBNET 4
1378 ID_IPV6_ADDR 5
1379 ID_IPV6_ADDR_SUBNET 6
1380 ID_IPV4_ADDR_RANGE 7
1381 ID_IPV6_ADDR_RANGE 8
1385 6.5. Nonce Payloads
1387 The Nonce payload contains random data that MUST be used in key
1388 generation by the initiating KINK peer, and MAY be used by the
1389 responding KINK peer. See section 8 for the discussion of its use in
1390 key generation.
1393 6.6. Notify Payloads
1395 Notification information can be error messages specifying why an SA
1396 could not be established. It can also be status data that a process
1397 managing an SA database wishes to communicate with a peer process.
1398 For example, a secure front end or security gateway may use the
1402 Thomas, Vilhuber [Page 25]
1403 ^L
1404 Internet-Draft KINK May 2005
1407 Notify message to synchronize SA communication. The table below
1408 lists the Notification messages and their corresponding values that
1409 are supported in KINK.
1412 NOTIFY MESSAGES - ERROR TYPES
1414 Errors Value
1415 INVALID-PAYLOAD-TYPE 1
1416 SITUATION-NOT-SUPPORTED 3
1417 INVALID-MAJOR-VERSION 5
1418 INVALID-MINOR-VERSION 6
1419 INVALID-EXCHANGE-TYPE 7
1420 INVALID-FLAGS 8
1421 INVALID-MESSAGE-ID 9
1422 INVALID-PROTOCOL-ID 10
1423 INVALID-SPI 11
1424 INVALID-TRANSFORM-ID 12
1425 ATTRIBUTES-NOT-SUPPORTED 13
1426 NO-PROPOSAL-CHOSEN 14
1427 BAD-PROPOSAL-SYNTAX 15
1428 PAYLOAD-MALFORMED 16
1429 INVALID-KEY-INFORMATION 17
1430 INVALID-ID-INFORMATION 18
1431 ADDRESS-NOTIFICATION 26
1432 NOTIFY-SA-LIFETIME 27
1433 UNEQUAL-PAYLOAD-LENGTHS 30
1434 RESERVED (Future Use) 31 - 8191
1435 Private Use 8192 - 16383
1437 NOTIFY MESSAGES - STATUS TYPES
1439 Status Value
1440 CONNECTED 16384
1441 RESERVED (Future Use) 16385 - 24575
1442 DOI-specific codes 24576 - 32767
1443 Private Use 32768 - 40959
1444 RESERVED (Future Use) 40960 - 65535
1448 6.7. Delete Payloads
1450 KINK directly uses ISAKMP delete payloads with no changes.
1453 6.8. KE Payloads
1458 Thomas, Vilhuber [Page 26]
1459 ^L
1460 Internet-Draft KINK May 2005
1463 IKE requires that perfect forward secrecy be supported through the
1464 use of the KE payload. However, Kerberos in general does not provide
1465 PFS so it is somewhat questionable whether a system which is heavily
1466 relying on Kerberos benefits from PFS. KINK retains the ability to
1467 use PFS, but relaxes the requirement from must implement to SHOULD
1468 implement.
1471 7. IPsec DOI Message Formats
1473 KINK messages are either commands, replies, or acknowledgments. A
1474 command is sent by an initiator to the responder. A reply is sent by
1475 the responder to the initiator. If the responder desires
1476 confirmation of the reply, it sets the ACKREQ bit in the message
1477 header. The ACKREQ bit MUST NOT be set by the responder except in
1478 the lone case of a CREATE message for which one of the security
1479 associations did not use the optimistic proposal. In that case, the
1480 ACKREQ bit MUST be set. All commands, responses, and acknowledgments
1481 are bound together by the XID field of the message header. The XID
1482 is normally a monotonically incrementing field, and is used by the
1483 initiator to differentiate between outstanding requests to a
1484 responder. The XID field does not provide replay protection as that
1485 functionality is provided by Kerberos mechanisms. In addition,
1486 commands and responses MUST use a cryptographic hash over the entire
1487 message if the two peers share a symmetric key via a ticket exchange.
1490 7.1. REPLY Message Considerations
1492 The REPLY message is a generic reply which MUST contain either a
1493 KINK_AP_REP, a KINK_KRB_ERROR, or a KINK_ERROR payload. REPLY's MAY
1494 contain additional DOI specific payloads such as ISAKMP payloads
1495 which are defined in the following sections. The checksum in the
1496 KRB-ERROR message is not used, since the KINK header already contains
1497 a checksum field.
1499 The server MUST return a KRB_AP_ERR_SKEW if the server clock and the
1500 client clock are off by more than the policy-determined clock skew
1501 limit (usually 5 minutes). The optional client's time in the KRB-
1502 ERROR MUST be filled out, and the client SHOULD compute the
1503 difference (in seconds) between the two clocks based upon the client
1504 and server time contained in the KRB-ERROR message. The client
1505 SHOULD store this clock difference and use it to adjust its clock in
1506 subsequent messages.
1509 7.2. ACK Message Considerations
1514 Thomas, Vilhuber [Page 27]
1515 ^L
1516 Internet-Draft KINK May 2005
1519 ACK's are sent only when the ACKREQ bit is set in a REPLY message.
1520 ACK's MUST NOT contain any payloads beside a lone AP-REQ header. If
1521 the initiator detects an error in the AP-REP or any other KINK or
1522 Kerberos error, it SHOULD take remedial action by reinitiating the
1523 initial command with the appropriate error to instruct the KINK
1524 receiver how to correct its original problem.
1527 7.3. CREATE Message
1529 This message initiates an establishment of new Security
1530 Association(s). The CREATE message must contain an AP-REQ payload
1531 and any DOI specific payloads.
1533 CREATE KINK Header
1534 KINK_AP_REQ
1535 [KINK_ENCRYPT]
1536 KINK_ISAKMP payload
1537 SA Payload[s]
1538 Proposal Payloads
1539 Transform Payloads
1540 Nonce Payload (Ni)
1541 [KE]
1542 [IDci, IDcr]
1543 [Notification Payloads]
1545 Replies are of the following forms:
1547 REPLY KINK Header
1548 KINK_AP_REP
1549 [KINK_ENCRYPT]
1550 KINK_ISAKMP
1551 SA Payload[s]
1552 Proposal Payload
1553 Transform Payload
1554 [Nonce Payload (Nr)]
1555 [KE]
1556 [IDci, IDcr]
1557 [Notification Payloads]
1559 Note that there MUST be at least a single proposal payload and a
1560 single transform payload in REPLY messages. Also: unlike IKE, the
1561 Nonce Payload Nr is not required, and its absence means that SAs in
1562 the optimistic proposal installed by the initiator are valid. If any
1563 of the first proposals are not chosen by the recipient, it MUST
1564 include the nonce payload as well to indicate that the initiator's
1565 outgoing SA's must be modified.
1570 Thomas, Vilhuber [Page 28]
1571 ^L
1572 Internet-Draft KINK May 2005
1575 KINK, like IKE allows the creation of many security associations in
1576 one create command. If any of the optimistic proposals is not chosen
1577 by the responder, it MUST request an ACK.
1579 If an IPsec DOI specific error is encountered, the responder must
1580 reply with a Notify payload describing the error:
1582 REPLY KINK Header
1583 KINK_AP_REP
1584 [KINK_ENCRYPT]
1585 [KINK_ERROR]
1586 KINK_ISAKMP
1587 [Notification Payloads]
1589 If the responder finds a Kerberos error for which it can produce a
1590 valid authenticator, the REPLY takes the following form:
1592 REPLY KINK Header
1593 KINK_AP_REP
1594 [KINK_ENCRYPT]
1595 KINK_KRB_ERROR
1597 Finally, if the responder finds a Kerberos or KINK type of error
1598 which it cannot create a AP-REP for, it MUST reply with a lone
1599 KINK_KRB_ERROR or KINK_ERROR payload:
1601 REPLY KINK Header
1602 [KINK_KRB_ERROR]
1603 [KINK_ERROR]
1606 7.4. DELETE Message
1608 This message indicates that the sending peer has deleted or will
1609 shortly delete Security Association(s) with the other peer.
1611 DELETE KINK Header
1612 KINK_AP_REQ
1613 [KINK_ENCRYPT]
1614 [ KINK_ERROR payload ]
1615 KINK_ISAKMP payload
1616 Delete Payload[s]
1617 [Notification Payloads]
1619 There are three forms of replies for a DELETE. The normal form is:
1626 Thomas, Vilhuber [Page 29]
1627 ^L
1628 Internet-Draft KINK May 2005
1631 REPLY KINK Header
1632 KINK_AP_REP
1633 [KINK_ENCRYPT]
1634 [ KINK_ERROR payload ]
1635 KINK_ISAKMP payload
1636 Delete Payload[s]
1637 [Notification Payloads]
1639 If an IPsec DOI specific error is encountered, the responder must
1640 reply with a Notify payload describing the error:
1642 REPLY KINK Header
1643 KINK_AP_REP payload
1644 [ KINK_ENCRYPT payload ]
1645 [ KINK_ERROR payload ]
1646 KINK_ISAKMP payload
1647 [Notification Payloads]
1649 If the responder finds a Kerberos error for which it can produce a
1650 valid authenticator, the REPLY takes the following form:
1652 REPLY KINK Header
1653 KINK_AP_REP
1654 [KINK_ENCRYPT]
1655 KINK_KRB_ERROR
1657 If the responder finds a KINK or Kerberos type of error, it MUST
1658 reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
1660 REPLY KINK Header
1661 [KINK_KRB_ERROR]
1662 [KINK_ERROR]
1665 7.5. STATUS Message
1667 The STATUS command is used in two ways:
1670 1) As a means to relay an ISAKMP Notification message
1672 2) As a means of probing a peer whether its epoch has changed for
1673 dead peer detection.
1682 Thomas, Vilhuber [Page 30]
1683 ^L
1684 Internet-Draft KINK May 2005
1687 STATUS contains the following payloads:
1688 KINK Header
1689 KINK_AP_REQ payload
1690 [ [KINK_ENCRYPT]
1691 [ KINK_ERROR payload ]
1692 KINK_ISAKMP payload
1693 [Notification Payloads] ]
1695 There are two forms of replies for a STATUS. The normal form is:
1697 REPLY KINK Header
1698 KINK_AP_REP
1699 [ [KINK_ENCRYPT]
1700 [KINK_ERROR]
1701 KINK_ISAKMP
1702 [Notification Payloads] ]
1704 If the responder finds a Kerberos error for which it can produce a
1705 valid authenticator, the REPLY takes the following form:
1707 REPLY KINK Header
1708 KINK_AP_REP
1709 [KINK_ENCRYPT]
1710 KINK_KRB_ERROR
1712 If the responder finds a KINK or Kerberos type of error it MUST reply
1713 with a lone KINK_KRB_ERROR or KINK_ERROR payload:
1715 REPLY KINK Header
1716 [KINK_KRB_ERROR]
1717 [KINK_ERROR]
1720 8. Key Derivation
1722 KINK uses the same key derivation mechanisms that [IKE] uses in
1723 section 5.5, which is:
1725 KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b])
1727 The following differences apply:
1729 o prf is the pseudo-random function corresponding to the session
1730 key's etype. They are defined in [KCRYPTO].
1732 o SKEYID_d is the session key in the Kerberos service ticket from
1733 the AP-REQ.
1738 Thomas, Vilhuber [Page 31]
1739 ^L
1740 Internet-Draft KINK May 2005
1743 o Both Ni_b and Nr_b are the part of the nonce payload as described
1744 in section 3.2 of [IKE]. Nr_b is optional. When the responder's
1745 nonce does not exist, Nr_b is treated as if a zero length value
1746 was supplied.
1748 Note that g(qm)^xy refers to the keying material generated when KE
1749 payloads are supplied using Diffie Hellman key agreement. This is
1750 explained in section 5.5 of [IKE].
1752 The rest of the key derivation (e.g., how to expand KEYMAT) follows
1753 IKE. How to use derived keying materials is up to each service
1754 (e.g., section 4.6.2 of [IPSEC]).
1757 9. Transport Considerations
1759 KINK uses UDP on port [XXX -- TBA by IANA] to transport its messages.
1760 There is one timer T which SHOULD take into consideration round trip
1761 considerations and MUST implement a truncated exponential back off
1762 mechanism. The state machine is simple: any message which expects a
1763 response MUST retransmit the request using timer T. Since Kerberos
1764 requires that messages be retransmitted with new times for replay
1765 protection, the message MUST be recreated each time including the
1766 checksum of the message. Both commands and replies with the ACKREQ
1767 bit set are kept on retransmit timers. When a KINK initiator
1768 receives a REPLY with the ACKREQ bit set, it MUST retain the ability
1769 to regenerate the ACK message for the transaction for a minimum of
1770 its a full retransmission timeout cycle or until it notices that
1771 packets have arrived on the newly constructed SA, whichever comes
1772 first.
1774 When a KINK peer retransmits a message, it MUST create a new Kerberos
1775 authenticator for the AP-REQ so that the peer can differentiate
1776 between replays and dropped packets. This results in a potential
1777 race condition when a retransmission occurs before an in-flight reply
1778 is received/processed. To counter this race condition, the
1779 retransmitting party SHOULD keep a list of valid authenticators which
1780 are outstanding for any particular transaction.
1783 10. Security Considerations
1785 KINK cobbles together and reuses many parts of both Kerberos and IKE,
1786 the latter which in turn is cobbled together from many other memos.
1787 As such, KINK inherits many of the weaknesses and considerations of
1788 each of its components. However, KINK uses only IKE Phase II
1789 payloads to create and delete security associations, the security
1790 considerations which pertain to IKE Phase I may be safely ignored.
1794 Thomas, Vilhuber [Page 32]
1795 ^L
1796 Internet-Draft KINK May 2005
1799 However, being able to ignore IKE's authentication phase necessarily
1800 means that KINK inherits all of the security considerations of
1801 Kerberos authentication as outlined in [KERBEROS] and [KERB]. For
1802 one, a KDC, like an AAA server, is a point of attack and all that
1803 implies. Much has been written about various shortcomings and
1804 mitigations of Kerberos and they should be evaluated for any
1805 deployment.
1807 KINK's use of Kerberos presents a couple of considerations. First,
1808 KINK explicitly expects that the KDC will provide adequate entropy
1809 when it generates session keys. Second, Kerberos is used as a user
1810 authentication protocol with the possibility of dictionary attacks on
1811 user passwords. This memo does not describe a particular method to
1812 avoid these pitfalls, but recommends that suitable randomly generated
1813 keys be used for the service principals such as using the -randomkey
1814 option with MIT's "kadmin addprinc" command as well as for clients
1815 when that is practical.
1817 Kerberos itself does not provide for perfect forward secrecy which
1818 makes KINK's reliance on the IKE ability to do PFS somewhat suspect
1819 from an overall system's standpoint. In isolation KINK itself should
1820 be secure from offline analysis from compromised principal
1821 passphrases if PFS is used, but the existence of other Kerberized
1822 service which do not provide PFS makes this a less than optimal
1823 situation on the whole.
1826 10.1. Security Policy Database Considerations
1828 KINK leaves the population of the IPsec security policy database out
1829 of scope. There are, however, considerations which should be pointed
1830 out. First, even though when and when not to initiate a User-to-User
1831 flow is left to the discretion of the KINK implementation, a Kerberos
1832 client which initially authenticated using a symmetric key SHOULD NOT
1833 use a User-to-User flow if the responder is also in the same realm.
1834 Likewise, a KINK initiator which authenticated in a public key realm
1835 SHOULD use a User-to-User flow if the responder is in the same realm.
1837 At a minimum the security policy database for a KINK implementation
1838 SHOULD contain a logical record of the KDC to contact, principal name
1839 for the responder, and whether the KINK implementation should use a
1840 direct AP-REQ/AP-REP flow, or a User-to-User flow to CREATE/DELETE
1841 the security association.
1843 That said, there is considerable room for improvement on how a KINK
1844 initiator could auto-discover how a responder in a different realm
1845 initially authenticated. This is left as an implementation detail as
1846 well as the subject of possible future standardization efforts which
1850 Thomas, Vilhuber [Page 33]
1851 ^L
1852 Internet-Draft KINK May 2005
1855 are outside of the scope of the KINK working group.
1858 11. IANA Considerations
1860 KINK requires that a new well known system port for UDP be created.
1861 Since KINK uses standard message types from [IKE], KINK does not
1862 require any new registries. Any new DOI's, ISAKMP types, etc for
1863 future versions of KINK MUST use the registries defined for [IKE].
1865 In addition, the ISAKMP payload types currently don't have a IANA
1866 registry, but needs one. KINK defines its payload constants as a
1867 sequential set of integers from KINK_ISAKMP_PAYLOAD_BASE to
1868 KINK_ISAKMP_PAYLOAD_BASE+7.
1870 KINK also requires that IANA create a registry for KINK error types.
1873 12. Forward Compatibility Considerations
1875 KINK can accommodate future versions of Quick Mode through the use of
1876 the version field in the ISAKMP payload as well as new domains of
1877 interpretation. In this memo, the only supported Quick Mode version
1878 is 1.0 which corresponds to [IKE]. Likewise, the only DOI supported
1879 is the IPsec domain of interpretation [IPDOI]. New Quick Mode
1880 versions and DOI's MUST be described in subsequent memos.
1882 KINK implementations MUST reject ISAKMP versions which are greater
1883 than the highest currently supported version with a KINK_BADQMVERS
1884 error type. A KINK implementation which receives a KINK_BADQMVERS
1885 message SHOULD be capable of reverting back to version 1.0.
1887 The following sections describe how different quick-modes and
1888 different DOI's can be used within the KINK framework.
1891 12.1. New Versions of Quick Mode
1893 The IPsec working group is defining the next generation IKE protocol
1894 (IKEv2) which uses a slightly different quick mode from the one in
1895 IKE v1. While the format of IKEv2 is not yet finalized, it does
1896 serve as an example.
1898 The only difference between the two is the format of the payloads
1899 that contain the IPsec traffic selectors. Formerly, these were
1900 overloaded into the ID payloads, and now they are carried in slightly
1901 more powerful TS (Traffic Selector) payloads.
1906 Thomas, Vilhuber [Page 34]
1907 ^L
1908 Internet-Draft KINK May 2005
1911 Were KINK to replace the IKEv2 'CREATE_CHILD_SA' for the current
1912 scheme, we would replace the contents of the KINK_ISAKMP payload
1913 (which currently contains a simplified version of the IKEv1 Quick-
1914 mode payloads) with the set of new payloads. Since the IKEv2
1915 CREATE_CHILD_SA exchange is still part of the IPsec DOI (see A.2),
1916 only the QMMaj version number in the KINK_ISAKMP header would be
1917 bumped to a new (higher) version number to indicate the new expected
1918 format of the contents of the KINK_ISAKMP payload. No other changes
1919 would be needed.
1921 KINK, therefore, merely acts as a transport mechanism to a Quick-mode
1922 exchange.
1925 12.2. New DOI
1927 The KINK message header contains a field called "Domain of
1928 Interpretation (DOI)" to allow other domains of interpretation to use
1929 KINK as a secure transport mechanism for keying.
1931 As one example of a new DOI, the MSEC working group is currently
1932 defining the GDOI (Group Domain of Interpretation), which defines a
1933 few new messages, which look like ISAKMP messages, but are not
1934 defined in ISAKMP.
1936 In order to carry GDOI messages in KINK, the DOI field in the KINK
1937 header would indicate that GDOI is being used, instead of IPSEC-DOI,
1938 and the KINK_ISAKMP payload would contain the payloads defined in the
1939 GDOI draft rather than the payloads used by [IKE] Quick Mode. The
1940 version number in the KINK_ISAKMP header is related to the DOI in the
1941 KINK header, so a maj.min version 1.0 under DOI GDOI is different
1942 from a maj.min version 1.0 under DOI IPSEC-DOI.
1945 13. Related Work
1947 The IPsec working group has defined a number of protocols that
1948 provide the ability to create and maintain cryptographically secure
1949 security associations at layer three (ie, the IP layer). This effort
1950 has produced two distinct protocols:
1952 o a mechanism for encrypting and authenticating IP datagram payloads
1953 which assumes a shared secret between the sender and receiver
1955 o a mechanism for IPsec peers to perform mutual authentication and
1956 exchange keying material
1958 The IPsec working group has defined a peer to peer authentication and
1962 Thomas, Vilhuber [Page 35]
1963 ^L
1964 Internet-Draft KINK May 2005
1967 keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer to
1968 peer protocol is that each peer must know and implement a site's
1969 security policy which in practice can be quite complex. In addition,
1970 the peer to peer nature of IKE requires the use of Diffie Hellman
1971 (DH) to establish a shared secret. DH, unfortunately, is
1972 computationally quite expensive and prone to denial of service
1973 attacks. IKE also relies on X.509 certificates to realize scalable
1974 authentication of peers. Digital signatures are also computationally
1975 expensive and certificate based trust models are difficult to deploy
1976 in practice. While IKE does allow for pre-shared symmetric keys, key
1977 distribution is required between all peers -- an O(n2) problem --
1978 which is problematic for large deployments.
1981 14. Acknowledgments
1983 Many have contributed to the KINK effort, including our working group
1984 chairs Derek Atkins and Jonathan Trostle. The original inspiration
1985 came from Cablelab's Packetcable effort which defined a simplified
1986 version of Kerberized IPsec, including Sasha Medvinsky, Mike Froh,
1987 and Matt Hur and David McGrew. The inspiration for wholly reusing
1988 IKE Phase II is the result of the Tero Kivinen's draft suggesting
1989 grafting Kerberos authentication onto quick mode.
1992 15. References
1995 15.1. Normative References
1997 [IKE]
1998 D. Harkins, D. Carrel. The Internet Key Exchange (IKE). Request
1999 for Comments 2409.
2001 [IPDOI]
2002 Piper, D., "The Internet IP Security Domain Of Interpretation for
2003 ISAKMP", RFC 2407, November 1998.
2005 [IPSEC]
2006 S. Kent, R. Atkinson. Security Architecture for the Internet
2007 Protocol. Request for Comments 2401.
2009 [ISAKMP]
2010 Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
2011 "Internet Security Association and Key Management Protocol
2012 (ISAKMP)", RFC 2408, November 1998.
2018 Thomas, Vilhuber [Page 36]
2019 ^L
2020 Internet-Draft KINK May 2005
2023 [ISAKMP-REG]
2024 http://www.iana.org/assignments/isakmp-registry
2026 [KCRYPTO]
2027 K. Raeburn, "Encryption and Checksum Specifications for Kerberos
2028 5", RFC 3961, February 2005.
2030 [KERBEROS] J. Kohl, C. Neuman. The Kerberos Network
2031 Authentication Service (V5). Request for Comments
2032 1510.
2035 15.2. Informative References
2038 [KERB] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication
2039 Service for Computer Networks, IEEE Communications,
2040 32(9):33-38. September 1994.
2042 [PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky,
2043 J. Wray, J. Trostle. Public Key Cryptography for
2044 Initial Authentication in Kerberos. draft-ietf-cat-
2045 kerberos-pk-init-11.txt
2047 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
2048 Sep-01-1981
2050 Authors' Addresses
2052 Shoichi Sakane
2053 Ken'ichi Kamada
2054 Yokogawa Electric Corporation
2055 2-9-32 Nakacho, Musashino-shi,
2056 Tokyo 180-8750 Japan
2057 E-mail: Shouichi.Sakane@jp.yokogawa.com, Ken-ichi.Kamada@jp.yokogawa.com
2060 Michael Thomas
2061 Jan Vilhuber
2062 Cisco Systems
2063 170 West Tasman Drive
2064 San Jose, CA 95134
2065 E-mail: mat@cisco.com, vilhuber@cisco.com
2074 Thomas, Vilhuber [Page 37]
2075 ^L
2076 Internet-Draft KINK May 2005
2079 Change History (To be removed from RFC)
2081 H.07
2082 1) Modified lots of editorial things.
2083 2) Added I-D boilerplate concerning Copyright and IPR claim disclosure.
2086 Full Copyright Statement
2088 Copyright (C) The Internet Society (2005).
2090 This document is subject to the rights, licenses and restrictions
2091 contained in BCP 78, and except as set forth therein, the authors
2092 retain all their rights.
2094 This document and the information contained herein are provided on an
2095 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2096 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2097 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2098 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2099 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2100 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2102 Intellectual Property Statement
2104 The IETF takes no position regarding the validity or scope of any
2105 intellectual property or other rights that might be claimed to
2106 pertain to the implementation or use of the technology described in
2107 this document or the extent to which any license under such rights
2108 might or might not be available; neither does it represent that it
2109 has made any effort to identify any such rights. Information on the
2110 IETF's procedures with respect to rights in standards-track and
2111 standards-related documentation can be found in BCP-11. Copies of
2112 claims of rights made available for publication and any assurances of
2113 licenses to be made available, or the result of an attempt made to
2114 obtain a general license or permission for the use of such
2115 proprietary rights by implementors or users of this specification can
2116 be obtained from the IETF Secretariat.
2118 The IETF invites any interested party to bring to its attention any
2119 copyrights, patents or patent applications, or other proprietary
2120 rights which may cover technology that may be required to practice
2121 this standard. Please address the information to the IETF Executive
2122 Director.
2130 Thomas, Vilhuber [Page 38]
2131 ^L