idnits 2.17.1 draft-ietf-kink-kink-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1816. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 8, 2005) is 6714 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KE' is mentioned on line 1324, but not defined == Missing Reference: 'IDci' is mentioned on line 1325, but not defined == Missing Reference: 'IDcr' is mentioned on line 1325, but not defined ** Obsolete normative reference: RFC 2434 (ref. 'BCP26') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. 'IPDOI') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISAKMP-REG' -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. 'GDOI') (Obsoleted by RFC 6407) == Outdated reference: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-30 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Shoichi Sakane 3 KINK Working Group Ken'ichi Kamada 4 Expires: June 11, 2006 Yokogawa Electric Corp. 5 Michael Thomas 6 Jan Vilhuber 7 Cisco Systems 8 December 8, 2005 10 Kerberized Internet Negotiation of Keys (KINK) 11 draft-ietf-kink-kink-11.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is a submission by the KINK Working Group of the 37 Internet Engineering Task Force (IETF). Comments should be submitted 38 to the KINK mailing list (ietf-kink@vpnc.org). You can subscribe by 39 sending mail to ietf-kink-request@vpnc.org with a line in the body of 40 the mail with the word SUBSCRIBE in it. 42 Distribution of this memo is unlimited. 44 This Internet-Draft expires in June 11, 2006. 46 Copyright Notice 48 Copyright (C) The Internet Society (2005). 50 Abstract 52 This document describes the Kerberized Internet Negotiation of Keys 53 (KINK) protocol. KINK defines a low-latency, computationally 54 inexpensive, easily managed, and cryptographically sound protocol to 55 establish and maintain security associations using the Kerberos 56 authentication system. KINK reuses the Quick Mode payloads of the 57 Internet Key Exchange (IKE), which should lead to substantial reuse 58 of existing IKE implementations. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119. 66 It is assumed that the readers are familiar with the terms and 67 concepts described in Kerberos Version 5 [KERBEROS], IPsec [IPSEC], 68 and IKE [IKE]. 70 Table of Contents 72 1. Introduction ................................................. 5 73 2. Protocol Overview ............................................ 5 74 3. Message Flows ................................................ 6 75 3.1. GETTGT Message Flow ..................................... 7 76 3.2. CREATE Message Flow ..................................... 7 77 3.2.1. CREATE Key Derivation Considerations ............. 9 78 3.3. DELETE Message Flow ..................................... 9 79 3.4. STATUS Message Flow ..................................... 10 80 3.5. Reporting Errors ........................................ 11 81 3.6. Rekeying Security Associations .......................... 11 82 3.7. Dead Peer Detection ..................................... 12 83 3.7.1. Coping with Dead User-to-User Peers .............. 14 84 4. KINK Message Format .......................................... 14 85 4.1. KINK Alignment Rules .................................... 17 86 4.2. KINK Payloads ........................................... 17 87 4.2.1. KINK_AP_REQ Payload .............................. 18 88 4.2.2. KINK_AP_REP Payload .............................. 20 89 4.2.3. KINK_KRB_ERROR Payload ........................... 20 90 4.2.4. KINK_TGT_REQ Payload ............................. 21 91 4.2.5. KINK_TGT_REP Payload ............................. 22 92 4.2.6. KINK_ISAKMP Payload .............................. 23 93 4.2.7. KINK_ENCRYPT Payload ............................. 24 94 4.2.8. KINK_ERROR Payload ............................... 25 95 5. Differences from IKE Quick Mode .............................. 26 96 5.1. Security Association Payloads ........................... 27 97 5.2. Proposal and Transform Payloads ......................... 28 98 5.3. Identification Payloads ................................. 28 99 5.4. Nonce Payloads .......................................... 28 100 5.5. Notify Payloads ......................................... 28 101 5.6. Delete Payloads ......................................... 29 102 5.7. KE Payloads ............................................. 30 103 6. Message Construction and Constraints for IPsec DOI ........... 30 104 6.1. REPLY Message ........................................... 30 105 6.2. ACK Message ............................................. 30 106 6.3. CREATE Message .......................................... 30 107 6.4. DELETE Message .......................................... 32 108 6.5. STATUS Message .......................................... 33 109 6.6. GETTGT Message .......................................... 34 110 7. ISAKMP Key Derivation ........................................ 34 111 8. Key Usage Numbers for Kerberos Key Derivation ................ 35 112 9. Transport Considerations ..................................... 35 113 10. Security Considerations ...................................... 36 114 11. IANA Considerations .......................................... 37 115 12. Forward Compatibility Considerations ......................... 37 116 12.1. New Versions of Quick Mode ............................. 38 117 12.2. New DOI ................................................ 38 119 13. Related Work ................................................. 38 120 14. Acknowledgments .............................................. 39 121 15. References ................................................... 39 122 15.1. Normative References ................................... 39 123 15.2. Informative References ................................. 40 124 Authors' Addresses ............................................... 40 125 Change History (To be removed from RFC) .......................... 41 126 Full Copyright Statement ......................................... 41 127 Intellectual Property Statement .................................. 41 129 1. Introduction 131 KINK is designed to provide a secure, scalable mechanism for 132 establishing keys between communicating entities within a centrally 133 managed environment in which it is important to maintain consistent 134 security policy. The security goals of KINK are to provide privacy, 135 authentication, and replay protection of key management messages, and 136 to avoid denial of service vulnerabilities whenever possible. The 137 performance goals of the protocol are to have a low computational 138 cost, low latency, and a small footprint. It is also to avoid or 139 minimize the use of public key operations. In particular, the 140 protocol provides the capability to establish IPsec security 141 associations (SA) in two messages with minimal computational effort. 142 These requirements are described in RFC 3129 [REQ4KINK]. 144 Kerberos [KERBEROS] provides an efficient authentication mechanism 145 for clients and servers using a trusted third-party model. Kerberos 146 also provides a mechanism for cross-realm authentication natively. A 147 client obtains a ticket from an online authentication server, the Key 148 Distribution Center (KDC). The ticket is then used to construct a 149 credential for authenticating the client to the server. As a result 150 of this authentication operation, the server will also share a secret 151 key with the client. KINK uses this property as the basis of 152 distributing keys for IPsec. 154 The central key management provided by Kerberos is efficient because 155 it limits computational cost and limits complexity versus IKE's [IKE] 156 necessity of using public key cryptography. Initial authentication 157 to the KDC may be performed using either symmetric keys, or 158 asymmetric keys using PKINIT [PKINIT]; however, subsequent requests 159 for tickets as well as authenticated exchanges between the client and 160 servers always utilize symmetric cryptography. Therefore, public key 161 operations (if any) are limited and are amortized over the lifetime 162 of the credentials acquired in the initial authentication operation 163 to the KDC. For example, a client may use a single public key 164 exchange with the KDC to efficiently establish multiple SAs with many 165 other servers in the realm of the KDC. Kerberos also scales better 166 than direct peer to peer keying when symmetric keys are used. The 167 reason is that since the keys are stored in the KDC, the number of 168 principal keys is O(n+m) rather than O(n*m), where "n" is the number 169 of clients and "m" is the number of servers. 171 2. Protocol Overview 173 KINK is a command/response protocol which can create, delete, and 174 maintain IPsec SAs. Each command or response contains a common 175 header along with a set of type-length-value payloads. The type of a 176 command or a response constrains the payloads sent in the messages of 177 the exchange. KINK itself is a stateless protocol in that each 178 command or response does not require storage of hard state for KINK. 179 This is in contrast to IKE, which uses Main Mode to first establish 180 an ISAKMP SA followed by subsequent Quick Mode exchanges. 182 KINK uses Kerberos mechanisms to provide mutual authentication and 183 replay protection. For establishing SAs, KINK provides 184 confidentiality for the payloads which follow the Kerberos AP-REQ 185 payload. The design of KINK mitigates denial of service attacks by 186 requiring authenticated exchanges before the use of any public key 187 operations and the installation of any state. KINK also provides a 188 means of using Kerberos User-to-User mechanisms when there is not a 189 key shared between the server and the KDC. This is typically, but 190 not limited to, the case with IPsec peers using PKINIT for initial 191 authentication. 193 KINK directly reuses Quick Mode payloads defined in section 5.5 of 194 [IKE], with some minor changes and omissions. In most cases, KINK 195 exchanges are a single command and its response. An optional third 196 message is required when creating SAs, only if the responder rejects 197 the first proposal from the initiator or wants to contribute the 198 keying materials. KINK also provides rekeying and dead peer 199 detection. 201 3. Message Flows 203 All KINK message flows follow the same pattern between the two peers: 204 a command, a response, and an optional acknowledgment in a CREATE 205 flow. A command is a GETTGT, CREATE, DELETE, or STATUS message, a 206 response is a REPLY message, and an acknowledgment is an ACK message. 208 KINK uses Kerberos as the authentication mechanism, therefore a KINK 209 host needs to get a service ticket for each peer before actual key 210 negotiations. This is basically a pure Kerberos exchange and the 211 actual KDC traffic here is for illustrative purposes only. In 212 practice, when a principal obtains various tickets is a subject of 213 Kerberos and local policy consideration. As an exception, the GETTGT 214 message flow of KINK (described in section 3.1) is used when a User- 215 to-User authentication is required. In this flow, we assume that 216 both A and B have TGTs from their KDCs. 218 After a service ticket is obtained, KINK uses the CREATE message flow 219 (section 3.2), DELETE message flow (section 3.3), and STATUS message 220 flow (section 3.4) to manage SAs. In these flows, we assume that A 221 has a service ticket for B. 223 3.1. GETTGT Message Flow 225 This flow is used to retrieve a TGT from the remote peer in User-to- 226 User authentication mode. 228 If the initiator determines that it will not be able to get a normal 229 (non-User-to-User) service ticket for the responder, it can try a 230 User-to-User authentication. In this case, it first fetches a TGT 231 from the responder in order to get a User-to-User service ticket: 233 A B KDC 234 ------ ------ --- 235 1 GETTGT+KINK_TGT_REQ------> 237 2 <-------REPLY+KINK_TGT_REP 239 3 TGS-REQ+TGT(B)------------------------------------> 241 4 <-------------------------------------------TGS-REP 243 Figure 1: GETTGT Message Flow 245 The initiator MAY support the following events as triggers to go to 246 the User-to-User path. Note that the two errors described below will 247 not be authenticated, and how to act on them depends on the policy. 249 o The local policy says that the responder requires a User-to-User 250 authentication. 252 o A KRB_AP_ERR_USER_TO_USER_REQUIRED error is returned from the 253 responder. 255 o A KDC_ERR_MUST_USE_USER2USER error is returned from the KDC. 257 3.2. CREATE Message Flow 259 This flow creates SAs. The CREATE command takes an "optimistic" 260 approach, where SAs are initially created on the expectation that the 261 responder will choose the initial proposed payload. The optimistic 262 proposal is placed in the first transform payload(s) of the first 263 proposal. The initiator MUST check to see if the optimistic proposal 264 was selected by comparing all transforms and attributes which MUST be 265 identical from those in the initiator's optimistic proposal with the 266 exceptions of LIFE_KILOBYTES and LIFE_SECONDS. Each of these 267 attributes MAY be set to a lower value by the responder and still 268 expect optimistic keying, but MUST NOT be set to a higher value which 269 MUST generate a NO-PROPOSAL-CHOSEN error. The initiator MUST use the 270 shorter lifetime. 272 When a CREATE command contains an existing SPI, the responder MUST 273 reject it and SHOULD reply an ISAKMP notification with INVALID-SPI. 275 When a KE payload is sent from the initiator but the responder does 276 not support it, the responder MUST reject it with an ISAKMP 277 notification of INVALID-PAYLOAD-TYPE containing a KE payload type as 278 its notification data. When the initiator receives this error, it 279 MAY retry without a KE payload (as another transaction) if its policy 280 allows that. 282 A B KDC 283 ------ ------ --- 285 A creates an optimistic inbound SA (B->A) unless using a KE. 287 1 CREATE+ISAKMP------------> 289 B creates an inbound SA (A->B). 290 B creates an outbound SA (B->A) if optimistic and not using a KE. 292 2 <-------------REPLY+ISAKMP 294 A creates an outbound SA (A->B). 295 A replaces an inbound SA (B->A) if non-optimistic. 296 A creates an inbound SA (B->A) if using a KE. 298 3 [ ACK---------------------> ] 300 [ B creates an outbound SA (B->A). ] 302 Figure 2: CREATE Message Flow 304 Creating SAs has two modes: 2-way handshake and 3-way handshake. The 305 initiator usually begins a negotiation expecting a 2-way handshake. 306 When the optimistic proposal is not chosen by the responder, the 307 negotiation is switched to a 3-way handshake. When and only when the 308 initiator uses a KE payload, 3-way handshake is expected from the 309 beginning. 311 A 2-way handshake is performed in the following steps: 312 1) The host A creates an inbound SA (B->A) in its SA database using 313 the optimistic proposal in the ISAKMP SA proposal. It is then 314 ready to receive any messages from B. 315 2) A then sends the CREATE message to B. 316 3) If B agrees to A's optimistic proposal, B creates an inbound SA 317 (A->B) and an outbound SA (B->A) in its database. If B does not 318 choose the first proposal or wants to add a nonce payload, switch 319 to the step 3) of a 3-way handshake described below. 320 4) B then sends a REPLY to A without a NONCE payload and without 321 requesting an ACK. 322 5) Upon receipt of the REPLY, A creates an outbound SA (A->B). 324 A 3-way handshake is performed in the following steps: 325 1) The host A sends the CREATE message to B without creating any SA. 326 2) B chooses one proposal according to its policy. 327 3) B creates an inbound SA (A->B) and sends the actual choice in the 328 REPLY. It SHOULD send the optional NONCE payload (as it does not 329 increase message count and generally increases entropy sources) 330 and MUST request that the REPLY be acknowledged. 331 4) Upon receipt of the REPLY, A creates the inbound SA (B->A) (or 332 modifies it as necessary, if switched from 2-way), and the 333 outbound SA (A->B). 334 5) A now sends the ACK message. 335 6) Upon receipt of the ACK, B installs the final outbound SA (B->A). 337 If B does not choose the first proposal, adds a nonce, or accepts the 338 KE exchange, then it MUST request an ACK (i.e. set the ACKREQ bit) so 339 that it can install the final outbound SA. The initiator MUST always 340 generate an ACK if the ACKREQ bit is set in the KINK header, even if 341 it believes that the responder was in error. 343 3.2.1. CREATE Key Derivation Considerations 345 The CREATE command's optimistic approach allows an SA to be created 346 in two messages rather than three. The implication of a two-message 347 exchange is that B will not contribute to the key since A must set up 348 the inbound SA before it receives any additional keying material from 349 B. This may be suspect under normal circumstances, however KINK 350 takes advantage of the fact that the KDC provides a reliable source 351 of randomness which is used in key derivation. In many cases, this 352 will provide an adequate session key so that B will not require an 353 acknowledgment. Since B is always at liberty to contribute to the 354 keying material, this is strictly a tradeoff between the key strength 355 versus the number of messages, which KINK implementations may decide 356 as a matter of policy. 358 3.3. DELETE Message Flow 360 The DELETE command deletes existing SAs. The DOI specific payloads 361 describe the actual SA to be deleted. For the IPSEC DOI, those 362 payloads will include an ISAKMP payload containing the list of the 363 SPIs to be deleted. 365 A B KDC 366 ------ ------ --- 368 A deletes outbound SA to B. 370 1 DELETE+ISAKMP------------> 372 B deletes inbound and outbound SA to A. 374 2 <-------------REPLY+ISAKMP 376 A deletes inbound SA to B. 378 Figure 3: DELETE Message Flow 380 The DELETE command takes a "pessimistic" approach, which does not 381 delete inbound SAs until it receives acknowledgment that the other 382 host has received the DELETE. The exception to the pessimistic 383 approach is if the initiator wants to immediately cease all activity 384 on an inbound SA. In this case, it MAY delete the inbound SA as well 385 in step one. 387 The ISAKMP payload contains ISAKMP Delete payload(s) which indicates 388 the inbound SA(s) for the initiator of this flow. KINK does not 389 allow half-open SAs, thus when the responder receives a DELETE 390 command, it MUST delete SAs of both directions, and MUST reply with 391 ISAKMP Delete Payload(s) which indicates the inbound SA(s) for the 392 responder of this flow. If the responder cannot find an appropriate 393 SPI to be deleted, it MUST return an ISAKMP notification with 394 INVALID_SPI, which also serves to inform the initiator that it can 395 delete the inbound SA. 397 A race condition with the DELETE flow exists. Due to network 398 reordering, etc, packets in flight while the DELETE operation is 399 taking place may arrive after the diagrams above, which recommend 400 deleting the inbound SA. A KINK implementation SHOULD implement a 401 grace timer which SHOULD be set to a period of at least two times the 402 average round trip time, or to a configurable value. A KINK 403 implementation MAY choose to set the grace period to zero at 404 appropriate times to delete an SA ungracefully. The behavior 405 described here is referred from the behavior of the TCP [RFC793] 406 flags FIN and RST. 408 3.4. STATUS Message Flow 410 This flow is used to send any information to a peer, or to elicit any 411 information from a peer. An initiator may send a STATUS command to 412 the responder at any time, optionally with DOI specific ISAKMP 413 payloads. In the case of the IPsec DOI, these are generally in the 414 form of ISAKMP Notification Payloads. A STATUS command is also used 415 as a means of Dead Peer Detection described in section 3.7. 417 A B KDC 418 ------ ------ --- 420 1 STATUS[+ISAKMP]----------> 422 2 <-----------REPLY[+ISAKMP] 424 Figure 4: STATUS Message Flow 426 3.5. Reporting Errors 428 When the responder detects an error in a received command, it can 429 send a DOI specific payload to indicate the error in a REPLY message. 430 There are three types of payloads which can indicate errors: 431 KINK_KRB_ERROR payloads for Kerberos errors, KINK_ERROR payloads for 432 KINK errors, and KINK_ISAKMP payloads for ISAKMP errors. Details are 433 described in the each part of this document. 435 If the initiator detects an error in a received reply, there is no 436 means to report it back to the responder. The initiator SHOULD log 437 the event and MAY take a remedial action by reinitiating the initial 438 command. 440 If the server clock and the client clock are off by more than the 441 policy-determined clock skew limit (usually 5 minutes), the server 442 MUST return a KRB_AP_ERR_SKEW. The optional client's time in the 443 KRB-ERROR SHOULD be filled out. If the server protects the error by 444 adding the Cksum field and returning the correct client's time, the 445 client SHOULD compute the difference (in seconds) between the two 446 clocks based upon the client and server time contained in the KRB- 447 ERROR message. The client SHOULD store this clock difference and use 448 it to adjust its clock in subsequent messages. If the error is not 449 protected, the client MUST NOT use the difference to adjust 450 subsequent messages, because doing so would allow an attacker to 451 construct authenticators that can be used to mount replay attacks. 453 3.6. Rekeying Security Associations 455 KINK expects the initiator of an SA to be responsible for rekeying 456 the SA. The reason is twofold: the first is to prevent needless 457 duplication of SAs as the result of collisions due to an initiator 458 and responder both trying to renew an existing SA. The second reason 459 is due to the client/server nature of Kerberos exchanges which 460 expects the client to get and maintain tickets. While KINK expects 461 that a KINK host is able to get and maintain tickets, in practice it 462 is often advantageous for servers to wait for clients to initiate 463 sessions so that they do not need to maintain a large ticket cache. 465 There are no special semantics for rekeying SAs in KINK. That is, in 466 order to rekey an existing SA, the initiator must CREATE a new SA 467 followed by either deleting the old SA with the DELETE flow or 468 letting it timeout. When identical flow selectors are available on 469 different SAs, KINK implementations SHOULD choose the SA most 470 recently created. It should be noted that KINK avoids most of the 471 problems of [IKE] rekeying by having a reliable delete mechanism. 473 Normally a KINK implementation which rekeys existing SAs will try to 474 rekey the SA ahead of an SA termination, which may include the hard 475 lifetime in time/bytecount or the overflow of the sequence number 476 counter. We call this time "soft lifetime". The soft lifetime MUST 477 be randomized to avoid synchronization with similar implementations. 478 In the case of the lifetime in time, one reasonable approach to 479 determine the soft lifetime is that picking a random time between T- 480 rekey and T-retrans and subtracting it from the hard lifetime. Here, 481 T-rekey is the reasonable maximum rekeying margin, and T-retrans is 482 the amount of time it would take to go through a full retransmission 483 cycle. T-rekey SHOULD be at least twice as high as T-retrans. 485 3.7. Dead Peer Detection 487 In order to determine that a KINK peer has lost its security database 488 information, KINK peers MUST record the current epoch for which they 489 have valid SA information for a peer and reflect that epoch in each 490 AP-REQ and AP-REP message. When a KINK peer creates state for a 491 given SA, it MUST also record the principal's epoch as well. If it 492 discovers on a subsequent message that the principal's epoch has 493 changed, it MUST consider all SAs created by that principal as 494 invalid, and take some action such as tearing those SAs down. 496 While a KINK peer SHOULD use feedback from routing (in the form of 497 ICMP messages) as a trigger to check whether the peer is still alive 498 or not, a KINK peer MUST NOT conclude the peers is dead simply based 499 on unprotected routing information (said ICMP messages). 501 If there is suspicion that a peer may be dead (based on any 502 information available to the KINK peer, including lack of IPsec 503 traffic, etc), the KINK STATUS message SHOULD be used to coerce an 504 acknowledgment out of the peer. Since nothing is negotiated about 505 dead peer detection in KINK, each peer can decide its own metric for 506 "suspicion" and also what time-outs to use before declaring a peer 507 dead due to lack of response to the STATUS message. This is 508 desirable, and does not break interoperability. 510 The STATUS message has a twofold effect: First, it elicits a 511 cryptographically secured (and replay-protected) response from the 512 peer, which tells us whether the peer is reachable/alive or not. 513 Second, it carries the epoch number of the peer, so we know whether 514 the peer has rebooted and lost all state or not. This is crucial to 515 the KINK protocol: In IKE, if a peer reboots, we lose all 516 cryptographic context, and no cryptographically secure communication 517 is possible without renegotiating keys. In KINK, due to Kerberos 518 tickets, we can communicate securely with a peer, even if the peer 519 rebooted, as the shared cryptographic key used is carried in the 520 Kerberos ticket. Thus, active cryptographic communication is not an 521 indication that the peer has not rebooted and lost all state, and the 522 epoch is needed. 524 Assume a Peer A sending a STATUS and a peer B sending the REPLY (see 525 section 3.4). Peer B MAY assume that the sender is alive, and the 526 epoch in the STATUS message will indicate whether the peer A has lost 527 state or not. Peer B MUST acknowledge the STATUS message with a 528 REPLY message, as described in section 3.4. 530 The REPLY message will indicate to peer A that the peer is alive, and 531 the epoch in the REPLY will indicate whether peer B has lost its 532 state or not. If peer A does not receive a REPLY message from peer B 533 in a suitable timeout, peer A MAY send another STATUS message. It is 534 up to peer A to decide how aggressively to declare peer B dead. The 535 level of aggressiveness may depend on many factors such as rapid fail 536 over versus number of messages sent by nodes with large numbers of 537 SAs. 539 Note that peer B MUST NOT make any inferences about a lack of STATUS 540 message from peer A. Peer B MAY use a STATUS message from peer A as 541 an indication of A's aliveness, but peer B MUST NOT expect another 542 STATUS message at any time (i.e. Dead Peer detection is not periodic 543 keepalives). 545 Strategies for sending STATUS messages: Peer A may decide to send a 546 STATUS message only after a prolonged period where no traffic was 547 sent in either direction over the IPsec SAs with the peer. Once 548 there is traffic, peer A may want to know if the traffic going into a 549 black hole, and send a STATUS message. Alternatively, peer A may use 550 an idle timer to detect lack of traffic with the peer, and send 551 STATUS messages in the quiet phase to make sure the peer is still 552 alive for when traffic needs to finally be sent. 554 3.7.1. Coping with Dead User-to-User Peers 556 When an initiator uses a User-to-User ticket and a responder has lost 557 its previous TGT, the usual DPD mechanism does not work, because the 558 responder cannot decrypt the ticket with its new TGT. In this case, 559 the following actions are taken. 561 o When the responder receives a KINK command with a User-to-User 562 ticket which cannot be decrypted with its TGT, it returns a REPLY 563 with a KINK_TGT_REP payload containing the TGT. 565 o When the initiator receives a KINK_TGT_REP, it retrieves a new 566 service ticket with the TGT and retries the command. 568 This does not directly define a method to detect a dead User-to-User 569 peer, but to recover from the situation that the responder does not 570 have an appropriate TGT to decrypt a service ticket sent from the 571 initiator. After recovery, they can exchange their epochs, and usual 572 DPD mechanism will detect a dead peer if it really has been dead. 574 The initiator MUST NOT think the peer has been dead on the receipt of 575 a KINK_TGT_REP because of two reasons. One is that the message is 576 not authenticated, and the other is that losing a TGT does not 577 necessarily mean losing the SA database information. The initiator 578 SHOULD NOT forget the previous service ticket until the new one is 579 successfully obtained in order to reduce the cost when a forged 580 KINK_TGT_REP is received. 582 4. KINK Message Format 584 All values in KINK are formatted in network byte order (Most 585 Significant Byte first). The RESERVED fields MUST be set to zero (0) 586 when a packet is sent. The receiver MUST ignore these fields. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type | MjVer |RESRVED| Length | 592 +---------------+---------------+---------------+---------------+ 593 | Domain of Interpretation (DOI) | 594 +-------------------------------+-------------------------------+ 595 | Transaction ID (XID) | 596 +---------------+-+-------------+-------------------------------+ 597 | NextPayload |A| RESERVED2 | CksumLen | 598 +---------------+-+-------------+-------------------------------+ 599 | | 600 ~ A series of payloads ~ 601 | | 602 +-------------------------------+-------------------------------+ 603 | | 604 ~ Cksum (variable) ~ 605 | | 606 +-------------------------------+-------------------------------+ 608 Figure 5: Format of a KINK message 610 Fields: 612 o Type (1 octet) -- The type of this message. 614 Type Value 615 ----- ----- 616 RESERVED 0 617 CREATE 1 618 DELETE 2 619 REPLY 3 620 GETTGT 4 621 ACK 5 622 STATUS 6 623 RESERVED TO IANA 7 - 127 624 Private Use 128 - 255 626 o MjVer (4 bits) -- Major protocol version number. This MUST be set 627 to 1. 629 o RESRVED (4 bits) -- Reserved and MUST be zero when sent, MUST be 630 ignored when received. 632 o Length (2 octets) -- Length of the message in octets. It is not 633 forbidden in KINK that there are unnecessary data after the 634 message, but the Length field MUST represent the actual length of 635 the message. 637 o DOI (4 octets) -- The domain of interpretation. All DOIs must be 638 registered with the IANA in the ISAKMP Domain of Interpretation 639 section of the isakmp-registry [ISAKMP-REG]. The IANA Assigned 640 Number for the Internet IP Security DOI [IPDOI] is one (1). This 641 field defines the context of all sub-payloads in this message. If 642 sub-payloads have a DOI field (e.g. Security Association Payload), 643 then the DOI in that sub-payload MUST be checked against the DOI 644 in this header, and the values MUST be the same. 646 o XID (4 octets) -- The transaction ID. A KINK transaction is bound 647 together by a transaction ID, which is created by the command 648 initiator and replicated in subsequent messages in the 649 transaction. A transaction is defined as a command, a reply, and 650 an optional acknowledgment. Transaction IDs are used by the 651 initiator to discriminate between multiple outstanding requests to 652 a responder. It is not used for replay protection because that 653 functionality is provided by Kerberos. The value of XID is chosen 654 by the initiator and MUST be unique with all outstanding 655 transactions. XIDs MAY be constructed by using a monotonic 656 counter, or random number generator. 658 o NextPayload (1 octet) -- Indicates the type of the first payload 659 after the message header. 661 o A, or ACKREQ (1 bit) -- ACK Request. Set to one if the responder 662 requires an explicit acknowledgment that a REPLY was received. An 663 initiator MUST NOT set this flag, nor should a responder except 664 for a REPLY to a CREATE when the optimistic proposal is chosen. 666 o RESERVED2 (7 bits) -- Reserved and MUST be zero on send, MUST be 667 ignored by a receiver. 669 o CksumLen (2 octets) -- CksumLen is the length in octets of the 670 cryptographic checksum of the message. A CksumLen of zero implies 671 that the message is unauthenticated. 673 o Cksum (variable) -- Kerberos keyed checksum over the entire 674 message excluding the Cksum field itself. When any padding bytes 675 are required between the last payload and the Cksum field, they 676 MUST be included in the calculation. This field MUST always be 677 present whenever a key is available via an AP-REQ or AP-REP 678 payload. The key used MUST be the session key in the ticket. 679 When a key is not available, this field is not present, and the 680 CksumLen field is set to zero. The content of this field is the 681 output of the Kerberos 5 get_mic function [KCRYPTO]. The get_mic 682 function used is specified by a checksum type, which is a 683 "required checksum mechanism" of the etype for the Kerberos 684 session key in the Kerberos ticket. If the checksum type is not a 685 keyed algorithm, the message MUST be rejected. 687 To compute the checksum, the CksumLen field is zeroed out and the 688 Length field is filled with the total packet length without the 689 checksum. Then, the packet is passed to the get_mic function and 690 its output is appended to the packet. Any KINK padding after the 691 Cksum field is not allowed, except the Kerberos internal one which 692 may be included in the output of the get_mic function. Finally, 693 the CksumLen field is filled with the checksum length and the 694 Length field is filled with the total packet length including the 695 checksum. 697 To verify the checksum, a length-without-checksum is calculated 698 from the value of Length field, subtracting the CksumLen. The 699 Length field is filled with the length-without-checksum value and 700 the CksumLen field is zeroed out. Then, the packet without 701 checksum (offset from 0 to length-without-checksum minus 1 of the 702 received packet) and the checksum (offset from length-without- 703 checksum to the last) are passed to the verify_mic function. If 704 verification fails, the message MUST be dropped. 706 The KINK header is followed immediately by a series of 707 Type/Length/Value fields, defined in section 4.2. 709 4.1. KINK Alignment Rules 711 KINK has the following rules regarding alignment and padding: 713 o All length fields MUST reflect the actual number of octets in the 714 structure; i.e., they do not account for padding bytes required by 715 KINK alignments. 717 o KINK headers, payloads, and the Cksum field MUST be aligned on 718 4-octet boundaries. 720 o Variable length fields (except the Cksum field) MUST always start 721 immediately after the last octet of the previous field. I.e., 722 they are not aligned to 4-octet boundaries. 724 4.2. KINK Payloads 726 Immediately following the header, there is a list of 727 Type/Length/Value (TLV) payloads. There can be any number of 728 payloads following the header. Each payload MUST begin with a 729 payload header. Each payload header is built on the generic payload 730 header. Any data immediately follows the generic header. Payloads 731 are all implicitly aligned to 4-octet boundaries, though the payload 732 length field MUST accurately reflect the actual number of octets in 733 the payload. 735 0 1 2 3 736 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 737 +---------------+---------------+---------------+---------------+ 738 | Next Payload | RESERVED | Payload Length | 739 +---------------+---------------+---------------+---------------+ 740 | value (variable) | 741 +---------------+---------------+---------------+---------------+ 743 Figure 6: Format of a KINK payload 745 Fields: 747 o Next Payload (1 octets) -- The type of the next payload. 749 NextPayload Value 750 ---- ----- 751 KINK_DONE 0 752 KINK_AP_REQ 1 753 KINK_AP_REP 2 754 KINK_KRB_ERROR 3 755 KINK_TGT_REQ 4 756 KINK_TGT_REP 5 757 KINK_ISAKMP 6 758 KINK_ENCRYPT 7 759 KINK_ERROR 8 760 RESERVED TO IANA 9 - 127 761 Private Use 128 - 255 763 Next Payload type KINK_DONE denotes that the current payload is 764 the final payload in the message. 766 o RESERVED (1 octet) -- Reserved and MUST be set to zero by a 767 sender, MUST be ignored by a receiver. 769 o Payload Length (2 octets) -- The length of this payload, including 770 the type and length fields. 772 o Value (variable) -- This value of this field depends on the type. 774 4.2.1. KINK_AP_REQ Payload 776 The KINK_AP_REQ payload relays a Kerberos AP-REQ to the responder. 777 The AP-REQ MUST request mutual authentication. 779 This document does not specify how to generate the principal name. 780 That is, complete principal names may be stored in local policy, 781 FQDNs may be converted to principal names, IP addresses may be 782 converted to principal names by secure name services, etc; but see 783 the first paragraph of the Security Considerations section. 785 If the peer's principal name for the KINK service is generated from 786 an FQDN, the principal name, which the initiator starts from, will be 787 "kink/fqdn@REALM"; where "kink" is a literal string for the KINK 788 IPsec service, "fqdn" is the fully qualified domain name of the 789 service host, and "REALM" is the Kerberos realm of the service. A 790 principal name is case sensitive, and "fqdn" part MUST be lower case 791 as described in [KERBEROS]. 793 The value field of this payload has the following format: 795 0 1 2 3 796 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 797 +---------------+---------------+---------------+---------------+ 798 | Next Payload | RESERVED | Payload Length | 799 +---------------+---------------+---------------+---------------+ 800 | EPOCH | 801 +---------------------------------------------------------------+ 802 | | 803 ~ AP-REQ ~ 804 | | 805 +---------------------------------------------------------------+ 807 Figure 7: KINK_AP_REQ Payload 809 Fields: 811 o Next Payload, RESERVED, Payload Length -- Defined in the beginning 812 of this section. 814 o EPOCH -- The absolute time at which the creator of the AP-REQ has 815 valid SA information. Typically, this is when the KINK keying 816 daemon started if it does not retain SA information across 817 restarts. The value in this field is the least significant four 818 octets of so-called POSIX time, which is the elapsed seconds (but 819 without counting leap seconds) from 1970-01-01T00:00:00 UTC. For 820 example, 2038-01-19T03:14:07 UTC is represented as 0x7fffffff. 822 o AP-REQ -- The value field of this payload contains a raw Kerberos 823 AP-REQ. 825 4.2.2. KINK_AP_REP Payload 827 The KINK_AP_REP payload relays a Kerberos AP-REP to the initiator. 828 The AP-REP MUST be checked for freshness as described in [KERBEROS]. 830 The value field of this payload has the following format: 832 0 1 2 3 833 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 834 +---------------+---------------+---------------+---------------+ 835 | Next Payload | RESERVED | Payload Length | 836 +---------------+---------------+---------------+---------------+ 837 | EPOCH | 838 +---------------------------------------------------------------+ 839 | | 840 ~ AP-REP ~ 841 | | 842 +---------------------------------------------------------------+ 844 Figure 8: KINK_AP_REP Payload 846 Fields: 848 o Next Payload, RESERVED, Payload Length -- Defined in the beginning 849 of this section. 851 o EPOCH -- The absolute time at which the creator of the AP-REP has 852 valid SA information. Typically, this is when the KINK keying 853 daemon started if it does not retain SA information across 854 restarts. The value in this field is the least significant four 855 octets of so-called POSIX time, which is the elapsed seconds (but 856 without counting leap seconds) from 1970-01-01T00:00:00 UTC. For 857 example, 2038-01-19T03:14:07 UTC is represented as 0x7fffffff. 859 o AP-REP -- The value field of this payload contains a raw Kerberos 860 AP-REP. 862 4.2.3. KINK_KRB_ERROR Payload 864 The KINK_KRB_ERROR payload relays Kerberos type errors back to the 865 initiator. The initiator MUST be prepared to receive any valid 866 Kerberos error type [KERBEROS]. 868 KINK implementations SHOULD make use of a KINK Cksum field when 869 returning KINK_KRB_ERROR and the appropriate service key is 870 available. Especially in the case of clock skew errors, protecting 871 the error at the server creates a better user experience because it 872 does not require clocks to be synchronized. However many Kerberos 873 implementations do not make it easy to obtain the session key in 874 order to protect error packets. For unauthenticated Kerberos errors, 875 the initiator MAY choose to act on them, but SHOULD take precautions 876 against make-work kinds of attacks. 878 Note that KINK does not make use of the text or e_data field of the 879 Kerberos error message, though a compliant KINK implementation MUST 880 be prepared to receive them and MAY log them. 882 The value field of this payload has the following format: 884 0 1 2 3 885 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 886 +---------------+---------------+---------------+---------------+ 887 | Next Payload | RESERVED | Payload Length | 888 +---------------+---------------+---------------+---------------+ 889 | | 890 ~ KRB-ERROR ~ 891 | | 892 +---------------------------------------------------------------+ 894 Figure 9: KINK_KRB_ERROR Payload 896 Fields: 898 o Next Payload, RESERVED, Payload Length -- Defined in the beginning 899 of this section. 901 o KRB-ERROR -- The value field of this payload contains a raw 902 Kerberos KRB-ERROR. 904 4.2.4. KINK_TGT_REQ Payload 906 The KINK_TGT_REQ payload provides a means to get a TGT from the peer 907 in order to obtain a User-to-User service ticket from the KDC. 909 The value field of this payload has the following format: 911 0 1 2 3 912 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 913 +---------------+---------------+---------------+---------------+ 914 | Next Payload | RESERVED | Payload Length | 915 +---------------+---------------+---------------+---------------+ 916 | | 917 ~ PrincName (variable) ~ 918 | | 919 +---------------------------------------------------------------+ 921 Figure 10: KINK_TGT_REQ Payload 923 Fields: 925 o Next Payload, RESERVED, Payload Length -- Defined in the beginning 926 of this section. 928 o PrincName -- The name of the principal which the initiator want to 929 communicate with. It is assumed that the initiator knows the 930 responder's principal name (including the realm name) in the same 931 way as the non-User-to-User case. The TGT returned MUST NOT be an 932 inter-realm TGT and its cname and crealm MUST match the requested 933 principal name, so that the initiator can rendezvous with the 934 responder at the responder's realm. 936 PrincName values are octet string representations of a principal 937 and realm name formatted just like the octet string used in the 938 "NAME" component of GSS-API [RFC2743] exported name token for the 939 Kerberos V5 GSS-API mechanism [RFC1964]. See RFC 1964, section 940 2.1.3. 942 If the responder is not the requested principal and is unable to get 943 a TGT for the name, it MAY return a KRB_AP_ERR_NOT_US. If the 944 administrative policy prohibits returning a TGT, it MAY return a 945 KINK_U2UDENIED. 947 4.2.5. KINK_TGT_REP Payload 949 The value field of this payload contains the TGT requested in a 950 previous KINK_TGT_REQ payload of a GETTGT command. 952 0 1 2 3 953 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 954 +---------------+---------------+---------------+---------------+ 955 | Next Payload | RESERVED | Payload Length | 956 +---------------+---------------+---------------+---------------+ 957 | | 958 ~ TGT (variable) ~ 959 | | 960 +---------------------------------------------------------------+ 962 Figure 11: KINK_TGT_REP Payload 964 Fields: 966 o Next Payload, RESERVED, Payload Length -- Defined in the beginning 967 of this section. 969 o TGT -- The DER encoded TGT of the responder. 971 4.2.6. KINK_ISAKMP Payload 973 The value field of this payload has the following format: 975 0 1 2 3 976 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 977 +---------------+---------------+---------------+---------------+ 978 | Next Payload | RESERVED | Payload Length | 979 +---------------+-------+-------+---------------+---------------+ 980 | InnerNextPload| QMMaj | QMMin | RESERVED | 981 +---------------+-------+-------+---------------+---------------+ 982 | Quick Mode Payloads (variable) | 983 +---------------+---------------+---------------+---------------+ 985 Figure 12: KINK_ISAKMP Payload 987 Fields: 989 o Next Payload, RESERVED, Payload Length -- Defined in the beginning 990 of this section. 992 o InnerNextPload -- First payload type of the inner series of ISAKMP 993 payloads. 995 o QMMaj -- The major version of the inner payloads. MUST be set to 996 1. 998 o QMMin -- The minor version of the inner payloads. MUST be set to 999 0. 1001 The KINK_ISAKMP payload encapsulates the IKE Quick Mode (phase two) 1002 payloads to take the appropriate action dependent on the KINK 1003 command. There may be any number of KINK_ISAKMP payloads within a 1004 single KINK message. While [IKE] is somewhat fuzzy about whether 1005 multiple different SAs may be created within a single IKE message, 1006 KINK explicitly requires that a new ISAKMP header be used for each 1007 discrete SA operation. In other words, a KINK implementation MUST 1008 NOT send multiple quick mode transactions within a single KINK_ISAKMP 1009 payload. 1011 The purpose of the Quick Mode version is to allow backward 1012 compatibility with IKE and ISAKMP if there are subsequent revisions. 1013 At the present time, the Quick Mode major and minor versions are set 1014 to one and zero (1.0) respectively. These versions do not correspond 1015 to the ISAKMP version in the ISAKMP header. A compliant KINK 1016 implementation MUST support receipt of 1.0 payloads. It MAY support 1017 subsequent versions (both sending and receiving), and SHOULD provide 1018 a means to resort back to Quick Mode version 1.0 if the KINK peer is 1019 unable to process future versions. A compliant KINK implementation 1020 MUST NOT mix Quick Mode versions in any given transaction. 1022 4.2.7. KINK_ENCRYPT Payload 1024 The KINK_ENCRYPT payload encapsulates other payloads and is encrypted 1025 using the encryption algorithm specified by the etype of the session 1026 key. This payload MUST be the final payload in the message. KINK 1027 encrypt payloads MUST be encrypted before the final KINK checksum is 1028 applied. 1030 0 1 2 3 1031 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 1032 +---------------+---------------+---------------+---------------+ 1033 | Next Payload | RESERVED | Payload Length | 1034 +---------------+---------------+---------------+---------------+ 1035 | InnerNextPload| RESERVED2 | 1036 +---------------+---------------+---------------+---------------+ 1037 | Payload (variable) | 1038 +---------------+---------------+---------------+---------------+ 1040 Figure 13: KINK_ENCRYPT Payload 1042 Fields: 1044 o Next Payload, RESERVED, Payload Length -- Defined in the beginning 1045 of this section. This payload is the last one in a message, and 1046 accordingly, the Next Payload field must be KINK_DONE (0). 1048 o InnerNextPload -- First payload type of the inner series of 1049 encrypted KINK payloads. 1051 o RESERVED2 -- Reserved and MUST be zero when sent, MUST be ignored 1052 when received. 1054 The coverage of the encrypted data begins at InnerNextPload so that 1055 the first payload's type is kept confidential. Thus, the number of 1056 encrypted octets is PayloadLength - 4. 1058 The format of the encryption payload follows the normal Kerberos 1059 semantics. Its content is the output of an encrypt function defined 1060 in the Encryption Algorithm Profile section of [KCRYPTO]. Parameters 1061 such as encrypt function itself, specific-key, and initial state are 1062 defined with the etype. The encrypt function may have padding in 1063 itself and there may be some garbage data at the end of the decrypted 1064 plaintext. A KINK implementation MUST be prepared to ignore such 1065 padding after the last sub-payload inside the KINK_ENCRYPT payload. 1066 Note that each encrypt function has its own integrity protection 1067 mechanism. It is redundant with the checksum in the KINK header, but 1068 this is unavoidable because it is not always possible to remove the 1069 integrity protection part from the encrypt function. 1071 4.2.8. KINK_ERROR Payload 1073 The KINK_ERROR payload type provides a protocol level mechanism of 1074 returning an error condition. This payload should not be used for 1075 either Kerberos generated errors, or DOI specific errors which have 1076 their own payloads defined. The error code is in network order. 1078 0 1 2 3 1079 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 1080 +---------------+---------------+---------------+---------------+ 1081 | Next Payload | RESERVED | Payload Length | 1082 +---------------+---------------+---------------+---------------+ 1083 | ErrorCode | 1084 +---------------+---------------+---------------+---------------+ 1086 Figure 14: KINK_ERROR Payload 1088 Fields: 1090 o Next Payload, RESERVED, Payload Length -- Defined in the beginning 1091 of this section. 1093 o ErrorCode -- One of the following values in the network byte 1094 order: 1096 ErrorCode Value Purpose 1097 --------- ----- ------------------- 1098 KINK_OK 0 No error detected 1099 KINK_PROTOERR 1 The message was malformed 1100 KINK_INVDOI 2 Invalid DOI 1101 KINK_INVMAJ 3 Invalid Major Version 1102 RESERVED 4 1103 KINK_INTERR 5 An unrecoverable internal error 1104 KINK_BADQMVERS 6 Unsupported Quick Mode Version 1105 KINK_U2UDENIED 7 Returning a TGT is prohibited 1106 RESERVED TO IANA 8 - 8191 1107 Private Use 8192 - 16383 1108 RESERVED 16384 - 1110 The responder MUST NOT return KINK_OK. When received, the 1111 initiator MAY act as if the specific KINK_ERROR payload were not 1112 present. If the initiator supports multiple Quick Mode versions 1113 or DOIs, KINK_BADQMVERS or KINK_INVDOI is received, and the Cksum 1114 is verified, then it MAY retry with another version or DOI. A 1115 responder SHOULD return a KINK error with KINK_INVMAJ, when it 1116 receives an unsupported KINK version number in the header. When 1117 KINK_U2UDENIED is received, the initiator MAY retry with the non- 1118 User-to-User mode (if not yet been tried). 1120 In general, the responder MAY choose to return these errors in 1121 reply to unauthenticated commands, but SHOULD take care to avoid 1122 being involved in denial of service attacks. Similarly, the 1123 initiator MAY choose to act on unauthenticated errors, but SHOULD 1124 take care to avoid denial of service attacks. 1126 5. Differences from IKE Quick Mode 1128 KINK directly uses ISAKMP payloads to negotiate SAs. In particular, 1129 KINK uses IKE phase II payload types (aka Quick Mode). In general, 1130 there should be very few changes necessary to an IKE implementation 1131 to establish the SAs, and unless there is a note to the contrary in 1132 the memo, all capabilities and requirements in [IKE] MUST be 1133 supported. IKE Phase I payloads MUST NOT be sent. 1135 Unlike IKE, KINK defines specific commands for creation, deletion, 1136 and status of SAs, mainly to facilitate predictable SA 1137 creation/deletion (see section 3.2 and 3.3). As such, KINK places 1138 certain restrictions on what payloads may be sent with which 1139 commands, and some additional restrictions and semantics of some of 1140 the payloads. Implementors should refer to [IKE] and [ISAKMP] for 1141 the actual format and semantics. If a particular IKE phase II 1142 payload is not mentioned here, it means that there are no differences 1143 in its use. 1145 o The Security Association Payload header for IP is defined in 1146 section 4.6.1 of [IPDOI]. For this memo, the Domain of 1147 Interpretation MUST be set to 1 (IPsec) and the Situation bitmap 1148 MUST be set to 1 (SIT_IDENTITY_ONLY). All other fields are 1149 omitted (because SIT_IDENTITY_ONLY is set). 1151 o KINK also expands the semantics of IKE in it defines an 1152 optimistic proposal for CREATE commands to allow SA creation to 1153 complete in two messages. 1155 o IKE Quick Mode (phase 2) uses the hash algorithm used in main 1156 mode (phase 1) to generate the keying material. For this 1157 purpose, KINK MUST use a pseudo-random function determined by the 1158 etype of the session key. 1160 o KINK does not use the HASH payload at all. 1162 o KINK allows the NONCE payload Nr to be optional to facilitate 1163 optimistic keying. 1165 5.1. Security Association Payloads 1167 KINK supports the following SA attributes from [IPDOI]: 1169 class value type 1170 ------------------------------------------------- 1171 SA Life Type 1 B 1172 SA Life Duration 2 V 1173 Encapsulation Mode 4 B 1174 Authentication Algorithm 5 B 1175 Key Length 6 B 1176 Key Rounds 7 B 1178 Refer to [IPDOI] for the actual definitions for these attributes. 1180 5.2. Proposal and Transform Payloads 1182 KINK directly uses the Proposal and Transform payloads with no 1183 differences. KINK, however, places additional relevance to the first 1184 proposal and first transform of each conjugate for optimistic keying. 1186 5.3. Identification Payloads 1188 The Identification payload carries information that is used to 1189 identify the traffic that is to be protected by the SA that will be 1190 established. KINK restricts the ID types, which are defined in 1191 section 4.6.2.1 of [IPDOI], to the following values: 1193 ID Type Value 1194 ------- ----- 1195 ID_IPV4_ADDR 1 1196 ID_IPV4_ADDR_SUBNET 4 1197 ID_IPV6_ADDR 5 1198 ID_IPV6_ADDR_SUBNET 6 1199 ID_IPV4_ADDR_RANGE 7 1200 ID_IPV6_ADDR_RANGE 8 1202 5.4. Nonce Payloads 1204 The Nonce payload contains random data that MUST be used in key 1205 generation. It MUST be sent by the initiating KINK peer, and MAY be 1206 sent by the responding KINK peer. See section 7 for the discussion 1207 of its use in key generation. 1209 5.5. Notify Payloads 1211 Notify payloads are used to transmit several informational data, such 1212 as error conditions and state transitions to a peer. For example, 1213 notification information transmit can be error messages specifying 1214 why an SA could not be established. It can also be status data that 1215 a process managing an SA database wishes to communicate with a peer 1216 process. 1218 Types in the range 0 - 16383 are intended for reporting errors 1219 [ISAKMP]. An implementation receiving a type in this range that it 1220 does not recognize in a response MUST assume that the corresponding 1221 request has failed entirely. Unrecognized error types in a request 1222 and status types in a request or response MUST be ignored, and they 1223 SHOULD be logged. Notify payloads with status types MAY be added to 1224 any message and MUST be ignored if not recognized. They are intended 1225 to indicate capabilities, and as part of SA negotiation are used to 1226 negotiate non-cryptographic parameters. 1228 The table below lists the Notification messages and their 1229 corresponding values. This document draws upon [IKEv2] to explain 1230 the usage of the messages clearly. PAYLOAD-MALFORMED denotes some 1231 error types defined by [ISAKMP]. Hence INVALID-PROTOCOL-ID for 1232 example is not used in this document. INVALID-MAJOR-VERSION and 1233 INVALID-MINOR-VERSION are not used because KINK_BADQMVERS is used to 1234 tell the initiator that the version of IKE is not supported. 1236 NOTIFY MESSAGES - ERROR TYPES Value 1237 ----------------------------- ----- 1238 INVALID-PAYLOAD-TYPE 1 1240 Sent if the ISAKMP payload type is not recognized. It is also 1241 sent when the KE Payload is not supported by the responder. 1242 Notification Data MUST contains the one octet payload type. 1244 INVALID-SPI 11 1246 Sent if the responder has an SPI indicated by the initiator in 1247 case of CREATE flow, or if the responder does not have an SPI 1248 indicated by the initiator in case of DELETE flow. 1250 NO-PROPOSAL-CHOSEN 14 1252 Sent if none of the proposals in the SA payload was 1253 acceptable. 1255 PAYLOAD-MALFORMED 16 1257 Sent if the KINK_ISAKMP message received was invalid because 1258 some type, length, or value was out of range. It is also sent 1259 when the request was rejected for reason that was not matched 1260 with other error types. 1262 5.6. Delete Payloads 1264 KINK directly uses ISAKMP delete payloads with no changes. 1266 5.7. KE Payloads 1268 IKE requires that perfect forward secrecy be supported through the 1269 use of the KE payload. KINK retains the ability to use PFS, but 1270 relaxes the requirement from must implement to SHOULD implement. The 1271 reasons are described in the Security Considerations section. 1273 6. Message Construction and Constraints for IPsec DOI 1275 All commands, responses, and acknowledgments are bound together by 1276 the XID field of the message header. The XID is normally a 1277 monotonically incrementing field, and is used by the initiator to 1278 differentiate between outstanding requests to a responder. The XID 1279 field does not provide replay protection as that functionality is 1280 provided by the Kerberos mechanisms. In addition, commands and 1281 responses MUST use a cryptographic checksum over the entire message 1282 if the two peers share a key via a ticket exchange. 1284 6.1. REPLY Message 1286 The REPLY message is a generic reply which MUST contain either a 1287 KINK_AP_REP, a KINK_KRB_ERROR, or a KINK_ERROR payload. REPLY 1288 messages MAY contain additional DOI specific payloads such as ISAKMP 1289 payloads which are defined in the following sections. 1291 6.2. ACK Message 1293 ACKs are sent only when the ACKREQ bit is set in a REPLY message. An 1294 ACK message MUST contain an AP-REQ payload and no other payload. 1296 6.3. CREATE Message 1298 This message initiates an establishment of new Security 1299 Association(s). The CREATE message must contain an AP-REQ payload 1300 and any DOI specific payloads. 1302 CREATE KINK Header 1303 KINK_AP_REQ 1304 [KINK_ENCRYPT] 1305 KINK_ISAKMP payloads 1306 SA Payload 1307 Proposal Payloads 1308 Transform Payloads 1309 Nonce Payload (Ni) 1310 [KE] 1311 [IDci, IDcr] 1312 [Notification Payloads] 1314 Replies are of the following forms: 1316 REPLY KINK Header 1317 KINK_AP_REP 1318 [KINK_ENCRYPT] 1319 KINK_ISAKMP payloads 1320 SA Payload 1321 Proposal Payloads 1322 Transform Payload 1323 [Nonce Payload (Nr)] 1324 [KE] 1325 [IDci, IDcr] 1326 [Notification Payloads] 1328 Note that there MUST be at least a single proposal payload and a 1329 single transform payload in REPLY messages. There will be multiple 1330 proposal payloads only when an SA bundle is negotiated. Also: unlike 1331 IKE, the Nonce Payload Nr is not required, and if it exists, an 1332 acknowledgment must be requested to indicate that the initiator's 1333 outgoing SAs must be modified. If any of the first proposals are not 1334 chosen by the recipient, it SHOULD include the nonce payload. 1336 KINK, like IKE, allows the creation of many SAs in one create 1337 command. If any of the optimistic proposals is not chosen by the 1338 responder, it MUST request an ACK. 1340 If an IPsec DOI specific error is encountered, the responder must 1341 reply with a Notify payload describing the error: 1343 REPLY KINK Header 1344 KINK_AP_REP 1345 [KINK_ENCRYPT] 1346 [KINK_ERROR] 1347 KINK_ISAKMP payloads 1348 [Notification Payloads] 1350 If the responder finds a Kerberos error for which it can produce a 1351 valid authenticator, the REPLY takes the following form: 1353 REPLY KINK Header 1354 KINK_AP_REP 1355 [KINK_ENCRYPT] 1356 KINK_KRB_ERROR 1358 Finally, if the responder finds a Kerberos or KINK type of error 1359 which it cannot create an AP-REP for, it MUST reply with a lone 1360 KINK_KRB_ERROR or KINK_ERROR payload: 1362 REPLY KINK Header 1363 [KINK_KRB_ERROR] 1364 [KINK_ERROR] 1366 6.4. DELETE Message 1368 This message indicates that the sending peer has deleted or will 1369 shortly delete Security Association(s) with the other peer. 1371 DELETE KINK Header 1372 KINK_AP_REQ 1373 [KINK_ENCRYPT] 1374 KINK_ISAKMP payloads 1375 Delete Payloads 1376 [Notification Payloads] 1378 There are three forms of replies for a DELETE. The normal form is: 1380 REPLY KINK Header 1381 KINK_AP_REP 1382 [KINK_ENCRYPT] 1383 [KINK_ERROR] 1384 KINK_ISAKMP payloads 1385 Delete Payloads 1386 [Notification Payloads] 1388 If an IPsec DOI specific error is encountered, the responder must 1389 reply with a Notify payload describing the error: 1391 REPLY KINK Header 1392 KINK_AP_REP 1393 [KINK_ENCRYPT] 1394 [KINK_ERROR] 1395 KINK_ISAKMP payloads 1396 [Notification Payloads] 1398 If the responder finds a Kerberos error for which it can produce a 1399 valid authenticator, the REPLY takes the following form: 1401 REPLY KINK Header 1402 KINK_AP_REP 1403 [KINK_ENCRYPT] 1404 KINK_KRB_ERROR 1406 If the responder finds a KINK or Kerberos type of error, it MUST 1407 reply with a lone KINK_KRB_ERROR or KINK_ERROR payload: 1409 REPLY KINK Header 1410 [KINK_KRB_ERROR] 1411 [KINK_ERROR] 1413 6.5. STATUS Message 1415 The STATUS command is used in two ways: 1417 1) As a means to relay an ISAKMP Notification message. 1419 2) As a means of probing a peer whether its epoch has changed for 1420 dead peer detection. 1422 STATUS contains the following payloads: 1423 KINK Header 1424 KINK_AP_REQ 1425 [[KINK_ENCRYPT] 1426 KINK_ISAKMP payload 1427 [Notification Payloads]] 1429 There are three forms of replies for a STATUS. The normal form is: 1431 REPLY KINK Header 1432 KINK_AP_REP 1433 [[KINK_ENCRYPT] 1434 [KINK_ERROR] 1435 KINK_ISAKMP payload 1436 [Notification Payloads]] 1438 If the responder finds a Kerberos error for which it can produce a 1439 valid authenticator, the REPLY takes the following form: 1441 REPLY KINK Header 1442 KINK_AP_REP 1443 [KINK_ENCRYPT] 1444 KINK_KRB_ERROR 1446 If the responder finds a KINK or Kerberos type of error, it MUST 1447 reply with a lone KINK_KRB_ERROR or KINK_ERROR payload: 1449 REPLY KINK Header 1450 [KINK_KRB_ERROR] 1451 [KINK_ERROR] 1453 6.6. GETTGT Message 1455 A GETTGT command is only used to carry a Kerberos TGT and is not 1456 related to SA management, therefore it contains only KINK_TGT_REQ 1457 payload and does not contain any DOI specific payload. 1459 There are two forms of replies for a GETTGT. In the normal form, 1460 where the responder is allowed to return its TGT, the REPLY contains 1461 KINK_TGT_REP payload. If the responder is not allowed to return its 1462 TGT, it MUST reply with a KINK_ERROR payload. 1464 7. ISAKMP Key Derivation 1466 KINK uses the same key derivation mechanisms defined in section 5.5 1467 of [IKE], which is: 1469 KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b]) 1471 The following differences apply: 1473 o prf is the pseudo-random function corresponding to the session 1474 key's etype. They are defined in [KCRYPTO]. 1476 o SKEYID_d is the session key in the Kerberos service ticket from 1477 the AP-REQ. Note that subkeys are not used in KINK and MUST be 1478 ignored if received. 1480 o Both Ni_b and Nr_b are the part of the nonce payloads (Ni and Nr 1481 respectively) as described in section 3.2 of [IKE]. Nr_b is 1482 optional, which means that Nr_b is treated as if a zero length 1483 value was supplied when the responder's nonce (Nr) does not exist. 1485 When Nr exists, Nr_b MUST be included in the calculation. 1487 Note that g(qm)^xy refers to the keying material generated when KE 1488 payloads are supplied using Diffie Hellman key agreement. This is 1489 explained in section 5.5 of [IKE]. 1491 The rest of the key derivation (e.g., how to expand KEYMAT) follows 1492 IKE. How to use derived keying materials is up to each service 1493 (e.g., section 4.6.2 of [IPSEC]). 1495 8. Key Usage Numbers for Kerberos Key Derivation 1497 Kerberos encrypt/decrypt functions and get_mic/verify_mic functions 1498 require "key usage numbers". They are used to generate specific keys 1499 for cryptographic operations so that different keys are used for 1500 different purposes/objects. KINK uses two usage numbers listed 1501 below. 1503 Purpose Usage number 1504 ------- ------------ 1505 KINK_ENCRYPT payload (for encryption) XXX -- TBA by rfc1510ter 1506 Cksum field (for checksum) XXX -- TBA by rfc1510ter 1508 9. Transport Considerations 1510 KINK uses UDP on port [XXX -- TBA by IANA] to transport its messages. 1511 There is one timer T which SHOULD take into consideration round trip 1512 considerations and MUST implement a truncated exponential back off 1513 mechanism. The state machine is simple: any message which expects a 1514 response MUST retransmit the request using timer T. Since Kerberos 1515 requires that messages be retransmitted with new times for replay 1516 protection, the message MUST be recreated each time including the 1517 checksum of the message. Both commands and replies with the ACKREQ 1518 bit set are kept on retransmit timers. When a KINK initiator 1519 receives a REPLY with the ACKREQ bit set, it MUST retain the ability 1520 to regenerate the ACK message for the transaction for a minimum of 1521 its full retransmission timeout cycle or until it notices that 1522 packets have arrived on the newly constructed SA, whichever comes 1523 first. 1525 When a KINK peer retransmits a message, it MUST create a new Kerberos 1526 authenticator for the AP-REQ so that the peer can differentiate 1527 between replays and dropped packets. This results in a potential 1528 race condition when a retransmission occurs before an in-flight reply 1529 is received/processed. To counter this race condition, the 1530 retransmitting party SHOULD keep a list of valid authenticators which 1531 are outstanding for any particular transaction. 1533 When a KINK peer retransmits a command, it MUST use the same ticket 1534 within the retransmissions. This is to avoid race conditions on 1535 using different keys, which result in different KEYMATs between an 1536 initiator and a responder. For this reason, (1) an initiator MUST 1537 obtain a ticket whose lifetime is greater than the initiator's 1538 maximum transaction time including timeouts, or (2) it MUST continue 1539 to use the same ticket within a set of retransmissions, and iff it 1540 receives an error (most likely KRB_AP_ERR_TKT_EXPIRED) from the 1541 responder, it starts a new transaction with a new ticket. 1543 10. Security Considerations 1545 The principal names are the identities of the KINK services, but the 1546 traffic protected by SAs are identified by DOI specific selectors (IP 1547 addresses, port numbers, etc). This may lead to a breakaway of SA- 1548 protected data from authentication. For example, if two different 1549 host claims that they have the same IP address, it may be impossible 1550 to predict which principal's key protect the data. Thus, an 1551 implementation must take care for the binding between principal names 1552 and the SA selectors. 1554 Sending errors without cryptographic protection must be handled very 1555 carefully. There is a trade-off between wanting to be helpful in 1556 diagnosing a problem and wanting to avoid being a dupe in a denial of 1557 service attack. 1559 KINK cobbles together and reuses many parts of both Kerberos and IKE, 1560 the latter which in turn is cobbled together from many other memos. 1561 As such, KINK inherits many of the weaknesses and considerations of 1562 each of its components. However, KINK uses only IKE Phase II 1563 payloads to create and delete SAs, the security considerations which 1564 pertain to IKE Phase I may be safely ignored. However, being able to 1565 ignore IKE's authentication phase necessarily means that KINK 1566 inherits all of the security considerations of Kerberos 1567 authentication as outlined in [KERBEROS]. For one, a KDC, like an 1568 AAA server, is a point of attack and all that implies. Much has been 1569 written about various shortcomings and mitigations of Kerberos and 1570 they should be evaluated for any deployment. 1572 KINK's use of Kerberos presents a couple of considerations. First, 1573 KINK explicitly expects that the KDC will provide adequate entropy 1574 when it generates session keys. Second, Kerberos is used as a user 1575 authentication protocol with the possibility of dictionary attacks on 1576 user passwords. This memo does not describe a particular method to 1577 avoid these pitfalls, but recommends that suitable randomly generated 1578 keys should be used for the service principals such as using the 1579 -randomkey option with MIT's "kadmin addprinc" command as well as for 1580 clients when that is practical. 1582 Kerberos does not currently provide perfect forward secrecy in 1583 general. KINK with the KE payload can provide PFS for a service key 1584 from a Kerberos key, but the KE is not mandatory because of the 1585 computational cost. This is a trade-off and operators can choose the 1586 PFS over the cost, and vice versa. KINK itself should be secure from 1587 offline analysis from compromised principal passphrases if PFS is 1588 used, but from an overall system's standpoint, the existence of other 1589 Kerberized services which do not provide PFS makes this a less than 1590 optimal situation. 1592 11. IANA Considerations 1594 This document requests IANA to assign a well known port number. 1596 This document also requests IANA to create a new registry for KINK, 1597 and register the following identifiers. 1599 KINK Message Types (section 4) 1600 KINK Next Payload Types (section 4.2) 1601 KINK Error Codes (section 4.2.8) 1603 Changes and additions to this registry follow the policies described 1604 below. Their meanings are described in [BCP26]. 1606 o Using the numbers in the "Private Use" range is Private Use. 1608 o Assignment from the "RESERVED TO IANA" range needs Standards 1609 Action, or non standards-track RFCs with Expert Review. (Though 1610 the full specification may be a public and permanent document of a 1611 standards body other than IETF, an RFC referring it is needed.) 1613 o Other change requires Standards Action. 1615 12. Forward Compatibility Considerations 1617 KINK can accommodate future versions of Quick Mode through the use of 1618 the version field in the ISAKMP payload as well as new domains of 1619 interpretation. In this memo, the only supported Quick Mode version 1620 is 1.0 which corresponds to [IKE]. Likewise, the only DOI supported 1621 is the IPsec domain of interpretation [IPDOI]. New Quick Mode 1622 versions and DOIs MUST be described in subsequent memos. 1624 KINK implementations MUST reject ISAKMP versions which are greater 1625 than the highest currently supported version with a KINK_BADQMVERS 1626 error type. A KINK implementation which receives a KINK_BADQMVERS 1627 message SHOULD be capable of reverting back to version 1.0. 1629 12.1. New Versions of Quick Mode 1631 The IPsec working group is defining the next generation IKE protocol 1632 [IKEv2] which does not use Quick Mode, but it is similar to the one 1633 in IKEv1. The difference between the two is summarized in the 1634 Appendix A in [IKEv2]. Each of them must be considered in order to 1635 use IKEv2 with KINK. 1637 12.2. New DOI 1639 The KINK message header contains a field called "Domain of 1640 Interpretation (DOI)" to allow other domains of interpretation to use 1641 KINK as a secure transport mechanism for keying. 1643 As one example of a new DOI, the MSEC working group defined the Group 1644 Domain of Interpretation [GDOI], which defines a few new messages, 1645 which look like ISAKMP messages, but are not defined in ISAKMP. 1647 In order to carry GDOI messages in KINK, the DOI field in the KINK 1648 header would indicate that GDOI is being used, instead of IPSEC-DOI, 1649 and the KINK_ISAKMP payload would contain the payloads defined in the 1650 GDOI draft rather than the payloads used by [IKE] Quick Mode. The 1651 version number in the KINK_ISAKMP header is related to the DOI in the 1652 KINK header, so a maj.min version 1.0 under DOI GDOI is different 1653 from a maj.min version 1.0 under DOI IPSEC-DOI. 1655 13. Related Work 1657 The IPsec working group has defined a number of protocols that 1658 provide the ability to create and maintain cryptographically secure 1659 SAs at layer three (i.e. the IP layer). This effort has produced two 1660 distinct protocols: 1662 o a mechanism for encrypting and authenticating IP datagram payloads 1663 which assumes a shared secret between the sender and receiver 1665 o a mechanism for IPsec peers to perform mutual authentication and 1666 exchange keying material 1668 The IPsec working group has defined a peer to peer authentication and 1669 keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer to 1670 peer protocol is that each peer must know and implement a site's 1671 security policy which in practice can be quite complex. In addition, 1672 the peer to peer nature of IKE requires the use of Diffie Hellman 1673 (DH) to establish a shared secret. DH, unfortunately, is 1674 computationally quite expensive and prone to denial of service 1675 attacks. IKE also relies on X.509 certificates to realize scalable 1676 authentication of peers. Digital signatures are also computationally 1677 expensive and certificate based trust models are difficult to deploy 1678 in practice. While IKE does allow for a pre-shared key, key 1679 distribution is required between all peers -- an O(n2) problem -- 1680 which is problematic for large deployments. 1682 14. Acknowledgments 1684 Many have contributed to the KINK effort, including our working group 1685 chairs Derek Atkins and Jonathan Trostle. The original inspiration 1686 came from Cablelab's Packetcable effort which defined a simplified 1687 version of Kerberized IPsec, including Sasha Medvinsky, Mike Froh, 1688 and Matt Hur and David McGrew. The inspiration for wholly reusing 1689 IKE Phase II is the result of the Tero Kivinen's draft suggesting 1690 grafting Kerberos authentication onto quick mode. 1692 15. References 1694 15.1. Normative References 1696 [BCP26] T. Narten, H. Alvestrand, "Guidelines for Writing an 1697 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1698 October 1998. 1700 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange 1701 (IKE)", RFC 2409, November 1998. 1703 [IPDOI] D. Piper, "The Internet IP Security Domain Of 1704 Interpretation for ISAKMP", RFC 2407, November 1998. 1706 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the 1707 Internet Protocol", RFC 2401, November 1998. 1709 [ISAKMP] D. Maughhan, M. Schertler, M. Schneider, J. Turner, 1710 "Internet Security Association and Key Management 1711 Protocol (ISAKMP)", RFC 2408, November 1998. 1713 [ISAKMP-REG] IANA, "Internet Security Association and Key Management 1714 Protocol (ISAKMP) Identifiers", 1715 . 1717 [KCRYPTO] K. Raeburn, "Encryption and Checksum Specifications for 1718 Kerberos 5", RFC 3961, February 2005. 1720 [KERBEROS] C. Neuman, T. Yu, S. Hartman, K. Raeburn, "The Kerberos 1721 Network Authentication Service (V5)", RFC 4120, July 1722 2005. 1724 [RFC1964] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 1725 RFC 1964, June 1996. 1727 15.2. Informative References 1729 [GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group 1730 Domain of Interpretation", RFC 3547, July 2003. 1732 [IKEv2] C. Kaufman, Ed, "Internet Key Exchange (IKEv2) 1733 Protocol", draft-ietf-ipsec-ikev2-17.txt. 1735 [PKINIT] L. Zhu, B. Tung, "Public Key Cryptography for Initial 1736 Authentication in Kerberos", draft-ietf-cat-kerberos- 1737 pk-init-30.txt. 1739 [REQ4KINK] M. Thomas, "Requirements for Kerberized Internet 1740 Negotiation of Keys", RFC 3129, June 2001. 1742 [RFC793] J. Postel, "Transmission Control Protocol", STD 7, RFC 1743 793, September 1981. 1745 [RFC2743] J. Linn, "Generic Security Service Application Program 1746 Interface Version 2, Update 1", RFC 2743, January 2000. 1748 Authors' Addresses 1750 Shoichi Sakane 1751 Ken'ichi Kamada 1752 Yokogawa Electric Corporation 1753 2-9-32 Nakacho, Musashino-shi, 1754 Tokyo 180-8750 Japan 1755 E-mail: Shouichi.Sakane@jp.yokogawa.com, 1756 Ken-ichi.Kamada@jp.yokogawa.com 1758 Michael Thomas 1759 Jan Vilhuber 1760 Cisco Systems 1761 170 West Tasman Drive 1762 San Jose, CA 95134 1763 E-mail: mat@cisco.com, vilhuber@cisco.com 1765 Change History (To be removed from RFC) 1767 H.08 1768 1) improved the notify payloads section. 1769 2) simplified the IANA consideration. 1770 3) removed the KINK minor version. 1771 4) improved the message flow section 1773 H.07 1774 1) Modified lots of editorial things. 1775 2) Added I-D boilerplate concerning Copyright and IPR claim 1776 disclosure. 1778 Full Copyright Statement 1780 Copyright (C) The Internet Society (2005). 1782 This document is subject to the rights, licenses and restrictions 1783 contained in BCP 78, and except as set forth therein, the authors 1784 retain all their rights. 1786 This document and the information contained herein are provided on an 1787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1789 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1790 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1791 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1794 Intellectual Property Statement 1796 The IETF takes no position regarding the validity or scope of any 1797 Intellectual Property Rights or other rights that might be claimed to 1798 pertain to the implementation or use of the technology described in 1799 this document or the extent to which any license under such rights 1800 might or might not be available; nor does it represent that it has 1801 made any independent effort to identify any such rights. Information 1802 on the procedures with respect to rights in RFC documents can be 1803 found in BCP 78 and BCP 79. 1805 Copies of IPR disclosures made to the IETF Secretariat and any 1806 assurances of licenses to be made available, or the result of an 1807 attempt made to obtain a general license or permission for the use of 1808 such proprietary rights by implementers or users of this 1809 specification can be obtained from the IETF on-line IPR repository at 1810 http://www.ietf.org/ipr. 1812 The IETF invites any interested party to bring to its attention any 1813 copyrights, patents or patent applications, or other proprietary 1814 rights that may cover technology that may be required to implement 1815 this standard. Please address the information to the IETF at ietf- 1816 ipr@ietf.org.