idnits 2.17.1 draft-ietf-kink-kink-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 38 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 76 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 264 has weird spacing: '...service ticke...' == Line 282 has weird spacing: '...ecurity assoc...' == Line 283 has weird spacing: '... takes an "...' == Line 284 has weird spacing: '...pondent will ...' == Line 285 has weird spacing: '... the initia...' == (71 more instances...) -- 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 (January 21, 2003) is 7766 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: 'KERB' is mentioned on line 107, but not defined == Missing Reference: 'IKE' is mentioned on line 1511, but not defined == Missing Reference: 'STD-2' is mentioned on line 571, but not defined == Missing Reference: 'KRBREVS' is mentioned on line 786, but not defined == Missing Reference: 'KE' is mentioned on line 1203, but not defined == Missing Reference: 'IDci' is mentioned on line 1217, but not defined == Missing Reference: 'IDcr' is mentioned on line 1217, but not defined == Unused Reference: 'RFC2412' is defined on line 1568, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (ref. 'KERBEROS') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. 'IPDOI') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-11 == Outdated reference: A later version (-08) exists of draft-ietf-cat-kerberos-pk-cross-06 Summary: 8 errors (**), 0 flaws (~~), 20 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT KINK M. Thomas 3 J. Vilhuber 4 January 21, 2003 6 Kerberized Internet Negotiation of Keys (KINK) 7 draft-ietf-kink-kink-05.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2003). All Rights Reserved. 32 Abstract 34 The Kerberized Internet Negotiation of Keys protocol (KINK) defines a 35 low-latency, computationally inexpensive, easily managed, and 36 cryptographically sound protocol to set up and maintain IPsec 37 security associations using Kerberos authentication. KINK reuses many 38 ISAKMP Quick Mode payloads to create, delete and maintain IPsec 39 security associations which should lead to substantial reuse of 40 existing IKE implementations. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119. 48 Table of Contents 50 Introduction .................................................... 2 51 Terminology ..................................................... 2 52 Protocol Overview ............................................... 4 53 Message Flows ................................................... 5 54 Standard KINK Message Flow ..................................... 5 55 GETTGT Message Flow ............................................ 5 56 CREATE Security Association .................................... 5 57 DELETE Security Association .................................... 7 58 STATUS Message Flow ............................................ 10 59 KINK Message Format ............................................. 10 60 KINK Payloads .................................................. 13 61 KINK Quick Mode Payload Profile ................................. 22 62 General Quick Mode Differences ................................. 22 63 Security Association Payloads .................................. 23 64 Proposal and Transform Payloads ................................ 23 65 Identification Payloads ........................................ 23 66 Nonce Payloads ................................................. 24 67 Notify Payloads ................................................ 24 68 Delete Payloads ................................................ 25 69 KE Payloads .................................................... 25 70 IPsec DOI Message Formats ....................................... 26 71 REPLY Message Considerations ................................... 26 72 ACK Message Considerations ..................................... 26 73 CREATE Message ................................................. 27 74 DELETE Message ................................................. 28 75 STATUS Message ................................................. 29 76 Key Derivation .................................................. 30 77 Transport Considerations ........................................ 30 78 Security Considerations ......................................... 31 79 Security Policy Database Considerations ........................ 31 80 IANA Considerations ............................................. 32 81 Forward Compatibility Considerations ............................ 32 82 New Versions of Quick Mode ..................................... 32 83 New DOI ........................................................ 33 84 Related Work .................................................... 33 85 Normative References ............................................ 34 86 Informative References .......................................... 35 87 Mailing List .................................................... 35 88 Author's Addresses .............................................. 35 89 Acknowledgments ................................................. 36 90 IPR Notice ...................................................... 36 91 Full Copyright .................................................. 36 93 1. Introduction 95 KINK is designed to provide a secure, scalable mechanism for estab- 96 lishing keys between communicating entities within a centrally 97 managed environment in which it is important to maintain consistent 98 security policy. The security goals of KINK are to provide privacy, 99 authentication, and replay protection of key management messages, and 100 to avoid denial of service vulnerabilities whenever possible. The 101 performance goals of the protocol are to incur a low computational 102 cost, to have low latency, to have a small footprint, and to avoid or 103 minimize the use of public key operations. In particular, the proto- 104 col provides the capability to establish security associations in two 105 messages with minimal computational effort. 107 Kerberos [KERB] and [KERBEROS] provides an efficient mechanism for 108 trusted third party authentication for clients and servers. (Ker- 109 beros also provides an mechanisms for inter-realm authentication 110 natively and with [PKCROSS].) Clients obtain tickets from an online 111 authentication server (the Key Distribution Center or KDC). Tickets 112 are then used to construct credentials for authenticating the client 113 to the server. As a result of this authentication operation, the 114 client and the server will also share a secret. KINK uses this pro- 115 perty as the basis of distributing keys for IPsec. 117 The central key management provided by Kerberos is efficient because 118 it limits computational cost and limits complexity versus IKE's 119 necessity of using public key cryptography. Initial authentication 120 to the KDC may be performed using either symmetric keys or asymmetric 121 keys using [PKINIT]; however, subsequent requests for tickets, as 122 well as authenticated exchanges between client and server always 123 utilize symmetric cryptography. Therefore, public key operations (if 124 any) are limited and are amortized over the lifetime of the initial 125 authentication operation to the Kerberos KDC. For example, a client 126 may use a single public key exchange with the KDC to efficiently 127 establish multiple security associations with many other servers in 128 the extended realm of the KDC. Kerberos also scales better than 129 direct peer to peer keying when symmetric keys are used. The reason 130 is that since the keys are stored in the KDC, the number of principal 131 keys is O(n) rather than O(n*m), where "n" is the number of clients 132 and "m" is the number of servers. 134 This document specifies the Kerberized Internet Negotiation of Keys 135 Protocol and the domain of interpretation (DOI) for establishing and 136 maintaining IPsec Security Associations [IPSEC]. No other domains of 137 interpretation are defined in this document. 139 2. Terminology 141 Ticket 142 A Kerberos term for a record that helps a client authenticate 143 itself to a server; it contains the client's identity, a session 144 key, a lifetime, and other information, all sealed using the 145 server's secret key. The combination of a ticket and an authentica- 146 tor (which proves freshness and knowledge of the key within the 147 ticket) creates an authentication credential. 149 KDC 150 Key Distribution Center, a network service that supplies tickets 151 and temporary session keys; or an instance of that service or the 152 host on which it runs. The KDC services both initial ticket and 153 Ticket-Granting Ticket (TGT) requests. The initial ticket portion 154 is referred to as the Authentication Server (or service). The 155 Ticket-Granting Ticket portion is referred to as the Ticket- 156 Granting Server (or service). 158 Realm 159 A Kerberos administrative domain. A single KDC may be responsible 160 for one or more realms. A fully qualified principal name includes 161 a realm name along with a principal name unique within that realm. 163 TGT 164 A ticket granting ticket is a normal Kerberos ticket which the KDC 165 issues for the Kerberos service. The main purpose of a TGT is to 166 capture the results of initial authentication for subsequent ticket 167 granting requests, thus providing a single sign-on service. 169 User-User 170 Kerberos normally divides the world into clients and servers where 171 the server maintains a table of keys (keytab) which is used to 172 encrypt/decrypt service tickets. In situations where a principal 173 may not have a keytab (ex. a human/client principal rather than a 174 service principal), Kerberos provides the means of issuing what is 175 known as a User-User ticket. To produce the User-User ticket, the 176 KDC requires the ticket granting tickets from both client princi- 177 pals. Kerberos does not specify a means obtaining a client's 178 ticket granting ticket, and is thus application specific. 180 Principal 181 Kerberos named entities are known as principals, Principals are 182 either client or service principals. A principal is an entity that 183 engages in a security relationship. A Kerberos principal name is 184 roughly equivalent to an X.509 distinguished name (it associates 185 the principal with an adminsitrative domain). Principals may be 186 client or servers. A server principal is generally distinguished 187 by a flag in a KDC principal database and by a keytab maintained by 188 the server. 190 DER 191 ASN.1 Distinguished Encoding Rules; Kerberos version 5 uses this 192 encoding format of ASN.1. 194 Quick-Mode 195 IKE defines two phases: an authentication phase (phase 1, or Main 196 Mode) and a security association maintenance phase (phase 2, or 197 Quick Mode). KINK reuses IKE Quick Mode. 199 AP-REQ/AP-REP 200 Kerberos defines an standardized message format and transport for 201 contacting a KDC to perform initial authentication, and for grant- 202 ing subsequent service tickets. When a client needs to authenticate 203 to a server, Kerberos provides a standardized message format, but 204 leaves the transport as application specific. The messages which 205 perform this function are AP-REQ between the client and the server, 206 and AP-REP between the server and client if mutual authentication 207 is needed. 209 3. Protocol Overview 211 KINK is a command/response protocol which can create, delete and 212 maintain IPsec security associations. Each command or response con- 213 tains a common header along with a set of type-length-value payloads 214 which are constrained according to the type of command or response. 215 KINK itself is a stateless protocol in that each command or response 216 does not require storage of hard state for KINK itself. This is in 217 contrast to IKE's use of Main Mode to first establish an ISAKMP secu- 218 rity association followed by subsequent Quick Mode exchanges. 220 KINK uses Kerberos mechanisms to provide mutual authentication, 221 replay protection. For security association establishment. KINK pro- 222 vides privacy of the payloads which follow the Kerberos authentica- 223 tor. KINK's design mitigates denial of service attacks by requiring 224 authenticated exchanges before the use of any public key operations 225 and the installation of any state. KINK also provides the means of 226 using Kerberos User-User mechanisms when there isn't a key shared 227 between the server and the KDC. This is typically -- but not limited 228 to -- the case with IPsec peers using [PKINIT] for initial authenti- 229 cation. 231 KINK directly reuses [ISAKMP] Quick Mode payloads, with some minor 232 changes and omissions. In most cases, KINK exchanges are a single 233 command and its response. The lone exception is the CREATE command 234 which allows a final acknowledgment message when the respondent needs 235 a full three-way handshake. This is only needed when the optimistic 236 keying route is not taken, though it is expected that that will not 237 be the norm. KINK also provides rekeying and dead peer detection as 238 basic features. 240 4. Message Flows 242 KINK message flows all follow the same pattern between the two peers: 243 a command, a response and a possible acknowledgment with CREATE's. 244 The actual Kerberos KDC traffic here is for illustrative purposes 245 only. In practice, when a principal obtains various tickets is a sub- 246 ject of Kerberos and local policy consideration. In these flows, we 247 assume that A and B both have TGT's from their KDC. 249 4.1. Standard KINK Message Flow 251 A B KDC 252 ------ ------ --- 253 1 COMMAND-------------------> 255 2 <------------------REPLY 257 3 [ ACK---------------------> ] 259 Figure 1: KINK Message Flow 261 4.2. GETTGT Message Flow 263 If the initiator determines that it will not be able to get a normal 264 service ticket for the respondent (eg, B is a client principal), it 265 MUST first fetch the TGT from the respondent in order to get a User- 266 User service ticket: 268 A B KDC 269 ------ ------ --- 270 1 GETTGT+KRB_TGT_REQ-------> 272 2 <-------REPLY+KRB_TGT_REP 274 3 TGS-REQ+TGT(B)-------------------------------------> 276 4 <--------------------------------------------TGS-REP 278 Figure 2: GETTGT Message Flow 280 4.3. CREATE Security Association 282 This flow instantiates a security association. The CREATE command 283 takes an "optimistic" approach where security associations are 284 initially created on the expectation that the respondent will chose 285 the initial proposed payload. The optimistic payload is defined as 286 the first transform of the first proposal of the first conjugate. 287 The initiator MUST checks to see if the optimistic payload was 288 selected by comparing all transforms and attributes which MUST be 289 identical from the initiator's optimistic proposal with the lone 290 exception of LIFE_KILOBYTES and LIFE_SECONDS. Both of these 291 attributes MAY be set to a lower value by the respondent and still 292 expect optimistic keying, but MUST NOT be set to a higher value which 293 MUST generate an error. 295 CREATE'ing a security association on an existing SPI is an error in 296 KINK and MUST be rejected with an ISAKMP notification of INVALID-SPI. 298 A B KDC 299 ------ ------ --- 301 A creates initial inbound SA (B->A) 303 1 CREATE+ISAKMP------------> 305 B creates inbound SA to A (A->B). If B chooses A's optimistic 306 proposal, it creates the outbound SA as well (B->A). 308 2 <------------REPLY+ISAKMP 310 A creates outbound SA and modifies inbound SA if it first 311 proposal wasn't acceptable. 313 3 [ ACK--------------------> ] 315 [ B creates the outbound SA to A (B-A). ] 317 Figure 3: CREATE Message Flow 319 The security associations are instantiated as follows: In step one 320 host A creates an inbound security association in its security asso- 321 ciation database from B->A using the optimistic proposal in the 322 ISAKMP SA proposal. It is then ready to receive any messages from B. 323 A then sends the CREATE message to B. If B agrees to A's optimistic 324 proposal, B instantiates a security association in its database from 325 A->B. B then instantiates the security association from B->A. It then 326 sends a REPLY to A without a NONCE payload and without requesting an 327 ACK. If B does not choose the first proposal, it sends the actual 328 choice in the REPLY, a NONCE payload and requests that the REPLY be 329 acknowledged. Upon receipt of the REPLY, A modifies the inbound secu- 330 rity association as necessary, instantiates the security association 331 from A->B, If B requested an ACK, A now sends the ACK message. Upon 332 receipt of the ACK, B installs the final security association from 333 B->A. 335 Note: if B adds a nonce, or does not choose the first proposal, it 336 MUST request an ACK so that it can install the final outbound secu- 337 rity association. The initiator MUST always generate an ACK if the 338 ACKREQ bit is set in the KINK header, even if it believes that the 339 respondent was in error. 341 4.3.1. CREATE Key Derivation Considerations 343 The CREATE command's optimistic approach allows a security associa- 344 tion to be created in two messages rather than three. The implication 345 of a two message exchange is that B will not contribute to the key 346 since A must set up the inbound security association before it 347 receives any additional keying material from B. Under normal cir- 348 cumstances this may be suspect, however KINK takes advantage of the 349 fact that the KDC provides a reliable source of randomness which is 350 used in key derivation. In many cases, this will provide an adequate 351 session key so that B will not require an acknowledgment. Since B is 352 always at liberty to contribute to the keying material, this is 353 strictly a key strength versus number of messages tradeoff which KINK 354 implementations may decide as a matter of policy. 356 4.4. DELETE Security Association 358 The DELETE command deletes an existing security association. The DOI 359 specific payloads describe the actual security association to be 360 deleted. For the IPSEC DOI, those payloads will include an ISAKMP 361 payload contains the SPI to be deleted in each direction. 363 A B KDC 364 ------ ------ --- 366 A deletes outbound SA to B 368 1 DELETE+ISAKMP------------> 370 B deletes inbound and outbound SA to A 372 2 <-------------REPLY+ISAKMP 374 A deletes inbound SA to B 376 Figure 4: DELETE Message Flow 378 The DELETE command takes a "pessimistic approach" which does not 379 delete incoming security associations until it receives acknowledg- 380 ment that the other host has received the DELETE. The exception to 381 the pessimistic approach is if the initiator wants to immediately 382 cease all activity on an incoming SA. In this case, it MAY delete the 383 incoming SA as well in step one. If the receiver cannot find an 384 appropriate SPI to delete, it MUST return an ISAKMP INVALID_SPI 385 notification which also serves to inform the initiator that it can 386 delete the incoming SA. For simplicity, KINK does not allow half open 387 security associations; thus upon receiving a DELETE, the responder 388 MUST delete its security associations, and MUST reply with ISAKMP 389 delete notification messages if the SPI is found. 391 A race condition with DELETE exists. Packets in flight while the 392 DELETE operation is taking place may, due to network reordering, etc, 393 arrive after the diagrams above recommend deleting the incoming secu- 394 rity association. A KINK implementation SHOULD implement a grace 395 timer which SHOULD be set to a period of at least two times the aver- 396 age round trip time, or to a configurable value. A KINK implementa- 397 tion MAY chose to set the grace period to zero at appropriate times 398 to ungracefully delete a security association. The behavior described 399 here loosely mimics the behavior of the TCP [RFC793] flags FIN and 400 RST. 402 4.4.1. Rekeying Security Associations 404 KINK requires the initiator of a security association to be responsi- 405 ble for rekeying a security association. The reason is twofold: the 406 first is to prevent needless duplication of security associations as 407 the result of collisions due to an initiator and respondent both try- 408 ing to renew an existing security association. The second reason is 409 due to the client/server nature of Kerberos exchanges which expects 410 the client to get and maintain tickets. While KINK requires that a 411 KINK host be able to get and maintain tickets, in practice it is 412 often advantageous for servers to wait for clients to initiate ses- 413 sions so that they do not need to maintain a large ticket cache. 415 There are no special semantics for rekeying security associations in 416 KINK. That is, in order to rekey an existing security association, 417 the initiator must CREATE a new security association followed by 418 either DELETE'ing the old security association or letting it time 419 out. When identical flow selectors are available on different secu- 420 rity associations, KINK implementations SHOULD choose the security 421 association most recently created. It should be noted that KINK 422 avoids most of the problems of [IKE] rekeying by having a reliable 423 delete mechanism. 425 Normally a KINK implementation which rekeys existing security associ- 426 ations will try to rekey the security association ahead of a hard SA 427 expiration. We call this time the rekey time Trekey. In order to 428 avoid synchronization with similar implementations, KINK initiators 429 MUST randomly pick a rekeying time between Trekey and the SA expira- 430 tion time minus the amount of time it would take to go through a full 431 retransmission time cycle, Tretrans. Trk SHOULD be set at least twice 432 as high as Tretrans. 434 4.4.2. Dead Peer Detection 436 In order to determine that a KINK peer has lost its security database 437 information, KINK peers MUST record the current epoch for which they 438 have valid SADB information and reflect that epoch in each AP-REQ and 439 AP-REP message. When a KINK peer creates state for a given security 440 association, it MUST also record the principal's epoch as well. If it 441 discovers on a subsequent message that the principal's epoch has 442 changed, it MUST consider all security associations created by that 443 principal as invalid, and take some action such as tearing those SA's 444 down. 446 While a KINK peer SHOULD use feedback from routing (in the form of 447 ICMP messages) as a trigger to check whether the peer is still alive 448 or not, a KINK peer MUST NOT conclude the peers is dead simply based 449 on unprotected routing information (said ICMP messages). 451 If there is suspicion that a peer may be dead (based on any informa- 452 tion available to the KINK peer, including lack of IPsec traffic, 453 etc), the KINK STATUS message SHOULD be used to coerce an acknowledg- 454 ment out of the peer. Since nothing is negiotiated about dead peer 455 detection in KINK, each peer can decide its own metric for 'suspi- 456 cion' and also what time-outs to use before declaring a peer dead due 457 to lack of response to the STATUS message. This is desireable, and 458 does not break interoperability. 460 The STATUS message has a two-fold effect: First, it elicits a crypto- 461 graphically secured (and replay-protected) response from the peer, 462 which tells us whether the peer is reachable/alive or not. Further, 463 it carries the epoch number of the peer, so we know whether the peer 464 has rebooted and lost all state or not. This is crucial to the KINK 465 protocol: In IKE, if a peer reboots, we loose all cryptographic con- 466 text, and no cryptographically secure communication is possible 467 without renegotiating keys. In KINK, due to Kerberos tickets, we can 468 communicate securely with a peer, even if the peer rebooted, as the 469 shared cryptographic key used is carried in the Kerberos ticket. 470 Thus, active cryptographic communication is not an indication that 471 the peer has not rebooted and lost all state, and the epoch is 472 needed. 474 Assume a Peer A sending a STATUS and a peer B sending the REPLY (see 475 section 4.5). Peer B MAY assume that the sender is alive, and the 476 epoch in the STATUS message will indicate whether the peer A has lost 477 state or not. Peer B MUST acknowledge the STATUS message with a REPLY 478 message, as described in section 4.5. 480 The REPLY message will indicate to peer A that the peer is alive, and 481 the epoch in the REPLY will indicate whether peer B has lost its 482 state or not. If peer A does not receive a REPLY message from peer B 483 in a suitable timeout, peer A MAY send another STATUS message. It is 484 up to peer A to decide how aggressively to declare peer B dead. The 485 level of aggressiveness may depend on many factors such as rapid 486 failover versus number of messages sent by nodes with large numbers 487 of security associations. 489 Note that peer B MUST NOT make any inferences about a lack of STATUS 490 message from peer A. Peer B MAY use a STATUS message from peer A as 491 indication of A's aliveness, but peer B MUST NOT expect another 492 STATUS message at any time (i.e. Dead Peer detection is not periodic 493 keepalives). 495 Strategies for sending STATUS messages: Peer A may decide to send a 496 STATUS message only after a prolonged period where no traffic was 497 sent in either direction over the IPsec SA's with the peer. Once 498 there is traffic, peer A may want to know if the traffic going into a 499 black hole, and send a STATUS message. Alternatively, peer A may use 500 an idle timer to detect lack of traffic with the peer, and send 501 STATUS messages in the quiet phase to make sure the peer is still 502 alive for when traffic needs to finally be sent. 504 4.5. STATUS Message Flow 506 At any point, a sender may send status, normally in the form of DOI 507 specific payloads to its peer. In the case of the IPsec DOI, these 508 are generally in the form of ISAKMP Notification Payloads. 510 A B KDC 511 ------ ------ --- 513 1 STATUS+ISAKMP------------> 515 2 <-------------REPLY+ISAKMP 517 Figure 5: STATUS Message Flow 519 5. KINK Message Format 521 All values in KINK are formatted in network byte order: Most 522 Significant Byte first. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type | MjVer | MnVer | Length | 528 +---------------+---------------+---------------+---------------+ 529 | Domain of Interpretation (DOI) | 530 +-------------------------------+-------------------------------+ 531 | Transaction ID (XID) | 532 +---------------+---------------+-+-----------------------------+ 533 | CksumLen | NextPayload |A| Reserved | 534 +---------------+---------------+-+-----------------------------+ 535 | | 536 ~ Cksum ~ 537 | | 538 +-------------------------------+-------------------------------+ 539 | | 540 ~ A series of payloads ~ 541 | | 542 +-------------------------------+-------------------------------+ 544 Figure 6: Format of a KINK message 546 Fields: 548 o Type (1 octet) - The type of message of this packet 550 Type Value 551 ----- ----- 552 RESERVED 0 553 CREATE 1 554 DELETE 2 555 REPLY 3 556 GETTGT 4 557 ACK 5 558 STATUS 6 560 o MjVer (4 bits) - Major protocol version number. This MUST be set 561 to 1. 563 o MnVer (4 bits) - Minor protocol version number. This MUST be set 564 to 0. 566 o Length (2 octets) - Length of the message in octets. Note that it 567 is legal within KINK to omit the last bytes of padding in the last 568 payload in the overall length. 570 o DOI (4 octets) - The domain of interpretation. All DOI's must be 571 registered with the IANA in the "Assigned Numbers" RFC [STD-2]. 573 The IANA Assigned Number for the Internet IP Security DOI (IPSEC 574 DOI) is one (1). This field defines the context of all other sub- 575 payloads in this payloads. If other sub-payloads have a DOI field 576 (example: Security Association Payload), then the DOI in that 577 sub-payload MUST be checked against the DOI in this header, and 578 the values MUST be the same. 580 o XID (4 octets) - The transaction ID. A KINK transaction is bound 581 together by a transaction ID which is created by the command ini- 582 tiator and replicated in subsequent messages in the transaction. A 583 transaction is defined as a command, a reply, and an optional ack- 584 nowledgment. Transaction ID's are used by the initiator to 585 discriminate between multiple outstanding requests to a respon- 586 dent. It is not used for replay protection because that func- 587 tionality is provided by Kerberos. The value of XID is chosen by 588 the initiator and MUST be unique with all outstanding transac- 589 tions. XID's MAY be constructed by using a monotonic counter, or 590 random number generator. 592 o CksumLen (2 octets) -- CksumLen is the length in octets of the 593 keyed hash of the message. A CksumLen of zero implies that the 594 message is unauthenticated. Note that as with payload padding, the 595 length here denotes the actual number of octets of the checksum 596 structure not including any padding required. 598 o NextPayload (1 octet) -- Indicates the type of the first payload 599 after the message header 601 o A (1 bit) -- ACK Request. Set to one if the responder requires an 602 explicit acknowledgment that a REPLY was received. An initiator 603 MUST NOT set this flag, nor should any other command other than 604 CREATE request an ACK and then only when the optimistic SA is not 605 chosen. 607 o Reserved (15 bits) -- Reserved and must be zero 609 o Cksum (variable) - Keyed checksum over the entire message. This 610 field MUST always be present whenever a key is available via an 611 AP-REQ or AP-REP payload. The key used MUST be the session key in 612 the ticket. When a key is not available, this field is not 613 present, and the CksumLen field is set to zero. The hash algorithm 614 used is the same as specified in the etype for the Kerberos ses- 615 sion key in the Kerberos ticket. If the etype does not specify a 616 hash algorithm, the message MUST be rejected. 618 The format of the Cksum field is as follows: 620 0 1 2 3 621 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 622 +---------------+---------------+---------------+---------------+ 623 | checksum (variable) ~ padding (variable) | 624 +---------------+---------------+---------------+---------------+ 626 Figure 7: KINK Checksum 628 To compute the checksum, the checksum field is zeroed out and the 629 appropriate algorithm is run over the entire message (as given by 630 the Length field in the KINK header), and placed in the Checksum 631 field. To verify the checksum, the checksum is saved, and the 632 checksum field is zeroed out. The checksum algorithm is run over 633 the message, and the result is compared with the saved version. If 634 they do not match, the message MUST be dropped. 636 The KINK header is followed immediately by a series of 637 Type/Length/Value fields, defined in the next section. 639 5.1. KINK Payloads 641 Immediately following the header, there is a list of 642 Type/Length/Value (TLV) payloads. There can be any number of payloads 643 following the header. Each payload MUST begin with a payload header. 644 Each payload header is built on the generic payload header. Any data 645 immediately follows the generic header. Payloads are all implicitly 646 padded to 4 octet boundaries, though the payload length field MUST 647 accurately reflect the actual number of octets in the payload. 649 0 1 2 3 650 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 651 +---------------+---------------+---------------+---------------+ 652 | Next Payload | RESERVED | Payload Length | 653 +---------------+---------------+---------------+---------------+ 654 | value (variable) | 655 +---------------+---------------+---------------+---------------+ 657 Figure 8: Format of a KINK payload 659 Fields: 661 o NextPayload (2 octets) - The type of the next payload 663 NextPayload Number 664 ---- ------ 665 KINK_DONE 0 (same as ISAKMP_NEXT_NONE) 666 KINK_AP_REQ KINK_ISAKMP_PAYLOAD_BASE+0 667 KINK_AP_REP KINK_ISAKMP_PAYLOAD_BASE+1 668 KINK_KRB_ERROR KINK_ISAKMP_PAYLOAD_BASE+2 669 KINK_TGT_REQ KINK_ISAKMP_PAYLOAD_BASE+3 670 KINK_TGT_REP KINK_ISAKMP_PAYLOAD_BASE+4 671 KINK_ISAKMP KINK_ISAKMP_PAYLOAD_BASE+5 672 KINK_ENCRYPT KINK_ISAKMP_PAYLOAD_BASE+6 673 KINK_ERROR KINK_ISAKMP_PAYLOAD_BASE+7 675 NextPayload type KINK_DONE denotes that the current payload is the 676 final payload in the message. 678 Note: the payload types are taken from the ISAKMP registry for 679 payload types. See the IANA consideration section for the value of 680 KINK_ISAKMP_PAYLOAD_BASE. 682 o RESERVED (1 octet) - Unused, MUST be set to 0. 684 o Length (2 octets) - The length of this payload, including the Type 685 and Length fields. 687 o Value (variable) - This value of this field depends on the Type. 689 5.1.1. KINK Padding Rules 691 KINK has the following rules regarding alignment and padding: 693 o All length fields MUST reflect the actual number of octets in the 694 structure; ie they do not account for padding bytes 696 o Between KINK payloads, checksums, headers or any other other vari- 697 able length data, the adjacent fields MUST be aligned on 4 octet 698 boundaries. 700 o Variable length fields MUST always start immediately after the 701 last octet of the previous field. Ie, they are not padded to a 4 702 octet boundary. 704 5.1.2. KINK_AP_REQ Payload 706 The KINK_AP_REQ payload relays a Kerberos AP-REQ to the respondent. 707 The AP-REQ MUST request mutual authentication. The service that the 708 KINK peer SHOULD request is "kink/fqdn@REALM" where "kink" is the 709 KINK IPsec service, "fqdn" is the fully qualified domain name of the 710 service host, and REALM is the Kerberos realm of the service. The 711 exception to this rule is when User-User service is requested in 712 which case the service name MUST be the service returned in the 713 GetTGT response payload. 715 The value field of this payload has the following format: 717 0 1 2 3 718 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 719 +---------------+---------------+---------------+---------------+ 720 | Next Payload | RESERVED | Payload Length | 721 +---------------+---------------+---------------+---------------+ 722 | EPOCH | 723 +---------------------------------------------------------------+ 724 | | 725 ~ KRB_AP_REQ ~ 726 | | 727 +---------------------------------------------------------------+ 729 Figure 9: KINK_AP_REQ Payload 730 Fields: 732 o EPOCH - the absolute time at which the creator of the AP-REQ has 733 valid security database (SADB) information. Typically this is when 734 the KINK keying daemon started if it does not retain SADB informa- 735 tion across different restarts. The format of this fields is net- 736 work order encoding of the standard posix four octet time stamp. 738 o KRB_AP_REQ - The value field of this payload contains a raw Ker- 739 beros KRB_AP_REQ. 741 5.1.3. KINK_AP_REP Payload 743 The KINK_AP_REP payload relays a kerberos AP-REP to the initiator. 744 The AP-REP MUST be checked for freshness as described in [KERBEROS]. 746 The value field of this payload has the following format: 748 0 1 2 3 749 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 750 +---------------+---------------+---------------+---------------+ 751 | Next Payload | RESERVED | Payload Length | 752 +---------------+---------------+---------------+---------------+ 753 | EPOCH | 754 +---------------------------------------------------------------+ 755 | | 756 ~ KRB_AP_REP ~ 757 | | 758 +---------------------------------------------------------------+ 760 Figure 10: KINK_AP_REP Payload 761 Fields: 763 o EPOCH - the absolute time at which the creator of the AP-REP has 764 valid security database (SADB) information. Typically this is when 765 the KINK keying daemon started if it does not retain SADB informa- 766 tion across different restarts. The format of this fields is net- 767 work order encoding of the standard posix four octet time stamp. 769 o KRB_AP_REP - The value field of this payload contains a raw Ker- 770 beros KRB_AP_REP. 772 5.1.4. KINK_KRB_ERROR Payload 774 The KINK_KRB_ERROR payload relays Kerberos type errors back to the 775 initiator. The receiver MUST be prepared to receive any valid 776 [KERBEROS] error type, but the sender SHOULD send only the following 777 errors: 779 KRB5KRB_AP_ERR_BAD_INTEGRITY 780 KRB5KRB_AP_ERR_TKT_EXPIRED 781 KRB5KRB_AP_ERR_SKEW 782 KRB5KRB_AP_ERR_NOKEY 783 KRB5KRB_AP_ERR_BADKEYVER 785 KINK implementations MUST make use of keyed Kerberos errors when the 786 appropriate service key is available as specified in [KRBREVS]. In 787 particular, clock skew errors MUST be integrity protected. For 788 unauthenticated Kerberos errors, the receiver MAY choose to act on 789 them, but SHOULD take precautions against make-work kinds of attacks. 791 Note that KINK does not make use of the text or e_data field of the 792 Kerberos error message, though a compliant KINK implementation MUST 793 be prepared to receive them and MAY log them. 795 The value field of this payload has the following format: 797 0 1 2 3 798 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 799 +---------------+---------------+---------------+---------------+ 800 | Next Payload | RESERVED | Payload Length | 801 +---------------+---------------+---------------+---------------+ 802 | | 803 ~ KRB_ERROR ~ 804 | | 805 +---------------------------------------------------------------+ 807 Figure 11: KINK_KRB_ERROR Payload 809 Fields: 811 o KRB_ERROR - The value field of this payload contains a raw 812 Kerberos KRB_ERROR. 814 5.1.5. KINK_TGT_REQ Payload 816 The KINK_TGT_REQ payload provides a means to get a TGT from the peer 817 in order to obtain a User to User service ticket from the KDC 819 The value field of this payload has the following format: 821 0 1 2 3 822 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 823 +---------------+---------------+---------------+---------------+ 824 | Next Payload | RESERVED | Payload Length | 825 +---------------+---------------+---------------+---------------+ 826 | RealmNameLen | RealmName (variable) ~ 827 +---------------+---------------+---------------+---------------+ 828 | | 829 ~ RealmName(variable) ~ 830 | | 831 +---------------------------------------------------------------+ 833 Figure 12: KINK_TGT_REQ Payload 835 Fields: 837 o RealmNameLen - The length of the realm name that follows 839 o RealmName - The realm name that the responder should return a TGT 840 for. The responder MUST return a ticket for the principal 841 krbtgt/REALM/@REALM to the initiator so that a User-User service 842 ticket can be obtained by the initiator. 844 o RESERVED - reserved and must be zero 846 If the responder is unable to get a TGT for the domain, it must 847 reply with a KRB_ERROR payload type. 849 5.1.6. KINK_TGT_REP Payload 851 The value field of this payload contains the TGT requested in a 852 previous KINK_TGT_REP command. 854 0 1 2 3 855 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 856 +---------------+---------------+---------------+---------------+ 857 | Next Payload | RESERVED | Payload Length | 858 +---------------+---------------+---------------+---------------+ 859 | PrincNameLen | PrincName (variable) ~ 860 +---------------+---------------+---------------+---------------+ 861 | | 862 ~ PrincName(variable) +---------------+ 863 | ~ padding | 864 +---------------------------------------------------------------+ 865 | TGTlength | TGT (variable) | 866 +-------------------------------+---------------+---------------+ 867 | ~ 868 ~ TGT (variable) +---------------+ 869 | ~ padding | 870 +---------------------------------------------------------------+ 872 Figure 13: KINK_TGT_REQ Payload 874 Fields: 876 o PrincNameLen - The length of the principal name that immediately 877 follows 879 o PrincName - The client principal that the initiator should request 880 a User to User service ticket for. 882 o TGTlength - The length of TGT that immediately follows 884 o TGT - the DER encoded TGT of the responder 886 5.1.7. KINK_ISAKMP Payload 888 The value field of this payload has the following format: 890 0 1 2 3 891 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 892 +---------------+---------------+---------------+---------------+ 893 | Next Payload | RESERVED | Payload Length | 894 +---------------+-------+-------+---------------+---------------+ 895 | InnerNextPload| QMMaj | QMMin | RESERVED | 896 +---------------+-------+-------+---------------+---------------+ 897 | Quick Mode Payloads (variable) | 898 +---------------+---------------+---------------+---------------+ 900 Figure 14: KINK_ISAKMP Payload 902 Fields: 904 o InnerNextPload - First payload type of the inner series of ISAKMP 905 payloads. 907 o QMMaj - The major version of the inner payloads. MUST be set to 1. 909 o QMMin - The minor version of the inner payloads. MUST be set to 0. 911 o RESERVED - reserved and must be zero 913 The KINK_ISAKMP payload encapsulates the IKE Quick Mode (phase 914 two) payloads to take the appropriate action dependent on the KINK 915 command. There may be any number of KINK_ISAKMP payloads within a 916 single KINK message. While IKE is somewhat fuzzy about whether 917 multiple different SA's may be created within a single IKE mes- 918 sage, KINK explicitly requires that a new ISAKMP header be used 919 for each discrete SA operation. In other words, a KINK sender MUST 920 NOT send multiple quick mode transactions within a single 921 KINK_ISAKMP payload. 923 The purpose of the Quick Mode version is to allow backward compa- 924 tibility with IKE and ISAKMP if there are subsequent revisions. At 925 the present time, the Quick Mode major and minor versions are set 926 to one and zero (1.0) respectively. These versions do not 927 correspond to the ISAKMP version in the ISAKMP header. A compliant 928 KINK implementation MUST support receipt of 1.0 payloads. It MAY 929 support subsequent versions (both sending and receiving), and 930 SHOULD provide a means to resort back to Quick Mode version 1.0 if 931 the KINK peer is unable to process future versions. A compliant 932 KINK implementation MUST NOT mix Quick Mode versions in any given 933 transaction. 935 5.1.8. KINK_ENCRYPT Payload 937 The KINK_ENCRYPT payload encapsulates other payloads and is encrypted 938 using the encryption algorithm specified by the etype of the session 939 key. This payload MUST be the final payload in the message. KINK 940 encrypt payloads MUST be encrypted before the final KINK checksum is 941 applied. 943 0 1 2 3 944 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 945 +---------------+---------------+---------------+---------------+ 946 | Next Payload | RESERVED | Payload Length | 947 +---------------+---------------+---------------+---------------+ 948 | InnerNextPload| RESERVED | 949 +---------------+---------------+---------------+---------------+ 950 | Payload (variable) | 951 +---------------+---------------+---------------+---------------+ 953 Figure 15: KINK_ENCRYPT Payload 954 Fields: 956 o InnerNextPload (variable) - First payload type of the inner series 957 of encrypted KINK payloads. 959 o RESERVED - reserved and must be zero 961 Note: the coverage of the encrypted data begins at InnerNextPload 962 so that first payload's type is kept confidential. Thus, the 963 number of encrypted octets is PayloadLength - 4. 965 The format of the encryption payload uses the normal [KERBEROS] 966 semantics of prepending a crypto-specific initialization vector 967 and padding the entire message out to the crypto-specific number 968 of bytes. For example, with DES-CBC, the initialization vector 969 will be 8 octets long, and the entire message will be padded to an 970 8 octet boundary. Note that KINK Encrypt payload MUST NOT include 971 a checksum since this is redundant with the message integrity 972 checksum in the KINK header. 974 5.1.9. KINK_ERROR Payload 976 The KINK_ERROR payload type provides a protocol level mechanism of 977 returning an error condition. This payload should not be used for 978 either Kerberos generated errors, or DOI specific errors which have 979 their own payloads defined. The error code is in network order. 981 0 1 2 3 982 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 983 +---------------+---------------+---------------+---------------+ 984 | Next Payload | RESERVED | Payload Length | 985 +---------------+---------------+---------------+---------------+ 986 | ErrorCode | 987 +---------------+---------------+---------------+---------------+ 989 Figure 16: KINK_ERROR Payload 991 ErrorCode Number Purpose 992 --------- ------ ------------------- 993 KINK_OK 0 - No error detected 994 KINK_PROTOERR 1 - The message was malformed 995 KINK_INVDOI 2 - Invalid DOI 996 KINK_INVMAJ 3 - Invalid Major Version 997 KINK_INVMIN 4 - Invalid Minor Version 998 KINK_INTERR 5 - An unrecoverable internal error 999 KINK_BADQMVERS 6 - Unsupported Quick Mode Version 1000 RESERVED 7 - 8191 1001 Private Use 8192 - 16383 1003 6. KINK Quick Mode Payload Profile 1005 KINK directly uses ISAKMP payloads to negotiate security associa- 1006 tions. In particular, KINK uses IKE phase II payload types (aka Quick 1007 Mode). In general, there should be very few changes necessary to an 1008 IKE implementation to establish the security associations, and unless 1009 there is a note to the contrary in the memo, all capabilities and 1010 requirements in [IKE] MUST be supported. IKE Phase I payloads MUST 1011 NOT be sent. 1013 Unlike IKE, KINK defines specific commands for creation, deletion, 1014 and status of security associations, mainly to facilitate predictable 1015 SA creation/deletion (see section 4.3 and 4.4). As such, KINK places 1016 certain restrictions on what payloads may be sent with which com- 1017 mands, and some additional restrictions and semantics of some of the 1018 payloads. Implementors should refer to [IKE] and [ISAKMP] for the 1019 actual format and semantics. If a particular IKE phase II payload is 1020 not mentioned here, it means that there are no differences in its 1021 use. 1023 6.1. General Quick Mode Differences 1025 o The Security Association Payload header for IP is defined in 1026 [IPDOI] section 4.6.1. For this memo, the Domain of Interpreta- 1027 tion MUST be set to 1 (IPSec) and the Situation bitmap MUST be 1028 set to 1 (SIT_IDENTITY_ONLY). All other fields are omitted 1029 (because SIT_IDENTITY_ONLY is set). 1031 o KINK also expands the semantics of IKE in it defines an optmis- 1032 tic proposal for CREATE commands to allow SA creation to com- 1033 plete in two messages. 1035 o IKE Quick Mode (phase 2) uses the hash algorithm used in main 1036 mode (phase 1) to generate the keying material. KINK MUST use 1037 the hashing algorithm specified in the session ticket's etype. 1039 o KINK does not use the HASH payload at all. 1041 o KINK allows the NONCE payload Nr to be optional to facilitate 1042 optimistic keying. 1044 6.2. Security Association Payloads 1046 KINK supports the following security association attributes from 1047 [IPDOI]: 1049 class value type 1050 ------------------------------------------------- 1051 SA Life Type 1 B 1052 SA Life Duration 2 V 1053 Encapsulation Mode 4 B 1054 Authentication Algorithm 5 B 1055 Key Length 6 B 1056 Key Rounds 7 B 1058 Refer to [IPDOI] for the actual definitions for these attributes. 1060 6.3. Proposal and Transform Payloads 1062 KINK directly uses the Proposal and Transform payloads with no 1063 differences. KINK, however, places additional relevance to the first 1064 proposal and first transform of each conjugate for optimistic keying. 1066 6.4. Identification Payloads 1068 The Identification payload carries information that is used to iden- 1069 tify the traffic that is to be protected using the keys exchanges in 1070 this memo. KINK restricts the ID types to the following values: 1072 ID Type Value 1073 ------- ----- 1074 ID_IPV4_ADDR 1 1075 ID_IPV4_ADDR_SUBNET 4 1076 ID_IPV6_ADDR 5 1077 ID_IPV6_ADDR_SUBNET 6 1078 ID_IPV4_ADDR_RANGE 7 1079 ID_IPV6_ADDR_RANGE 8 1081 6.5. Nonce Payloads 1083 The Nonce payload contains random data that MUST be used in key 1084 generation by the initiating KINK peer, and MAY be used by the 1085 responding KINK peer. See section 8 for the discussion of their use 1086 in key generation. 1088 6.6. Notify Payloads 1090 Notification information can be error messages specifying why an SA 1091 could not be established. It can also be status data that a process 1092 managing an SA database wishes to communicate with a peer process. 1093 For example, a secure front end or security gateway may use the 1094 Notify message to synchronize SA communication. The table below 1095 lists the Notification messages and their corresponding values that 1096 are supported in KINK. 1098 NOTIFY MESSAGES - ERROR TYPES 1100 Errors Value 1101 INVALID-PAYLOAD-TYPE 1 1102 SITUATION-NOT-SUPPORTED 3 1103 INVALID-MAJOR-VERSION 5 1104 INVALID-MINOR-VERSION 6 1105 INVALID-EXCHANGE-TYPE 7 1106 INVALID-FLAGS 8 1107 INVALID-MESSAGE-ID 9 1108 INVALID-PROTOCOL-ID 10 1109 INVALID-SPI 11 1110 INVALID-TRANSFORM-ID 12 1111 ATTRIBUTES-NOT-SUPPORTED 13 1112 NO-PROPOSAL-CHOSEN 14 1113 BAD-PROPOSAL-SYNTAX 15 1114 PAYLOAD-MALFORMED 16 1115 INVALID-KEY-INFORMATION 17 1116 INVALID-ID-INFORMATION 18 1117 ADDRESS-NOTIFICATION 26 1118 NOTIFY-SA-LIFETIME 27 1119 UNEQUAL-PAYLOAD-LENGTHS 30 1120 RESERVED (Future Use) 31 - 8191 1121 Private Use 8192 - 16383 1123 NOTIFY MESSAGES - STATUS TYPES 1125 Status Value 1126 CONNECTED 16384 1127 RESERVED (Future Use) 16385 - 24575 1128 DOI-specific codes 24576 - 32767 1129 Private Use 32768 - 40959 1130 RESERVED (Future Use) 40960 - 65535 1132 6.7. Delete Payloads 1134 KINK directly uses ISAKMP delete payloads with no changes. 1136 6.8. KE Payloads 1137 IKE requires that perfect forward secrecy be supported through the 1138 use of the KE payload. However, Kerberos in general does not provide 1139 PFS so it is somewhat questionable whether a system which is heavily 1140 relying on Kerberos benefits from PFS. KINK retains the ability to 1141 use PFS, but relaxes the requirement from must implement to SHOULD 1142 implement. 1144 7. IPsec DOI Message Formats 1146 KINK messages are either commands, replies, or acknowledgments. A 1147 command is sent by an initiator to the respondent. A reply is sent 1148 by the respondent to the initiator. If the respondent desires confir- 1149 mation of the reply, it sets the ACKREQ bit in the message header. 1150 The ACKREQ bit MUST NOT be set by the respondent except in the lone 1151 case of a CREATE message for which one of the security associations 1152 did not use the optimistic payload. In that case, the ACKREQ bit MUST 1153 be set. All commands, responses and acknowledgments are bound 1154 together by the XID field of the message header. The XID is normally 1155 a monotonically incrementing field, and is used by the initiator to 1156 differentiate between outstanding requests to a responder. The XID 1157 field does not provide replay protection as that functionality is 1158 provided by Kerberos mechanisms. In addition, commands and responses 1159 MUST use a cryptographic hash over the entire message if the two 1160 peers share a symmetric key via a ticket exchange. 1162 7.1. REPLY Message Considerations 1164 The REPLY message is a generic reply which MUST contain either a 1165 KINK_AP_REP, a KRB-ERROR, or KINK_ERROR payload. REPLY's MAY contain 1166 additional DOI specific payloads such as ISAKMP payloads which are 1167 defined in the following sections. The checksum in the KRB-ERROR 1168 message is not used, since the KINK header already contains a check- 1169 sum field. 1171 The server MUST return a KRB_AP_ERR_SKEW if the server clock and the 1172 client clock are off by more than the policy-determined clock skew 1173 limit (usually 5 minutes). The optional client's time in the KRB- 1174 ERROR MUST be filled out, and the client MUST compute the difference 1175 (in seconds) between the two clocks based upon the client and server 1176 time contained in the KRB-ERROR message. The client SHOULD store 1177 this clock difference and use it to adjust its clock in subsequent 1178 messages. 1180 7.2. ACK Message Considerations 1182 ACK's are sent only when the ACKREQ bit is set in a REPLY message. 1183 ACK's MUST NOT contain any payloads beside a lone AP-REQ header. If 1184 the initiator detects an error in the AP-REP or any other KINK or 1185 Kerberos error, it SHOULD take remedial action by reinitiating the 1186 initial command with the appropriate error to instruct the KINK 1187 receiver how to correct its original problem. 1189 7.3. CREATE 1191 This message initiates an establishment of new Security 1192 Association(s). The CREATE message must contain an AP-REQ payload and 1193 any DOI specific payloads. 1195 CREATE KINK Header 1196 KINK_AP_REQ 1197 [KINK_ENCRYPT] 1198 KINK_ISAKMP payload 1199 SA Payload[s] 1200 Proposal Payloads 1201 Transform Payloads 1202 Nonce Payload (Ni) 1203 [KE] 1204 [IDci, IDcr] 1205 [Notification Payloads] 1207 Replies are of the following forms: 1209 REPLY KINK Header 1210 KINK_AP_REP 1211 [KINK_ENCRYPT] 1212 KINK_ISAKMP 1213 SA Payload[s] 1214 Proposal Payload 1215 Transform Payload 1216 [ Nonce Payload (Nr)] 1217 [IDci, IDcr] 1218 [Notification Payloads] 1220 Note that there MUST be at least a single proposal payload and a 1221 single transform payload in REPLY messages. Also: unlike IKE, the 1222 Nonce Payload Nr is not required, and its absence means that the 1223 optimistic mode SA's installed by the initiator are valid. If any of 1224 the first proposals are not chosen by the recipient, it MUST include 1225 the nonce payload as well to indicate that the initiator's outgoing 1226 SA's must be modified. 1228 KINK, like IKE allows the creation of many security associations in 1229 one create command. If any of the optimistic creation mode proposals 1230 is not chosen by the respondent, it MUST request an ACK. 1232 If an IPspec DOI specific error is encountered, the respondent must 1233 reply with a Notify payload describing the error: 1235 REPLY KINK Header 1236 KINK_AP_REP 1237 [KINK_ENCRYPT] 1238 [KINK_ERROR] 1239 KINK_ISAKMP 1240 [Notification Payloads] 1242 If the respondent finds a Kerberos error for which it can produce a 1243 valid authenticator, the REPLY takes the following form: 1245 REPLY KINK Header 1246 KINK_AP_REP 1247 [KINK_ENCRYPT] 1248 KINK_KRB_ERROR 1250 Finally, if the respondent finds a Kerberos or KINK type of error it 1251 which it cannot create a AP-REP for, MUST reply with a lone 1252 KINK_KRB_ERROR or KINK_ERROR payload: 1254 REPLY KINK Header 1255 [KINK_KRB_ERROR] 1256 [KINK_ERROR] 1258 7.4. DELETE 1260 This message indicates that the sending peer has deleted or will 1261 shortly delete Security Association(s) with the other peer. 1263 DELETE KINK Header 1264 KINK_AP_REQ 1265 [KINK_ENCRYPT] 1266 [ KINK_ERROR payload ] 1267 KINK_ISAKMP payload 1268 Delete Payload[s] 1269 [Notification Payloads] 1271 There are three forms of replies for a DELETE. The normal form is: 1273 REPLY KINK Header 1274 KINK_AP_REP 1275 [KINK_ENCRYPT] 1276 [ KINK_ERROR payload ] 1277 KINK_ISAKMP payload 1278 Delete Payload[s] 1279 [Notification Payloads] 1281 If an IPsec DOI specific error is encountered, the respondent must 1282 reply with a Notify payload describing the error: 1284 REPLY KINK Header 1285 KINK_AP_REP payload 1286 [ KINK_ENCRYPT payload ] 1287 [ KINK_ERROR payload ] 1288 KINK_ISAKMP payload 1289 [Notification Payloads] 1291 If the respondent finds a Kerberos error for which it can produce a 1292 valid authenticator, the REPLY takes the following form: 1294 REPLY KINK Header 1295 KINK_AP_REP 1296 [KINK_ENCRYPT] 1297 KINK_KRB_ERROR 1299 If the respondent finds a KINK or Kerberos type of error it MUST 1300 reply with a lone KINK_KRB_ERROR or KINK_ERROR payload: 1302 REPLY KINK Header 1303 [KRB_ERROR] 1304 [KINK_KRB_ERROR] 1306 7.5. STATUS 1308 The STATUS command is used in two ways: 1310 1) As a means to relay an ISAKMP Notification message 1312 2) As a means of probing a peer whether its epoch has changed for 1313 dead peer detection. 1315 STATUS contains the following payloads: 1316 KINK Header 1317 KINK_AP_REQ payload 1318 [ [KINK_ENCRYPT] 1319 [ KINK_ERROR payload ] 1320 KINK_ISAKMP payload 1321 [Notification Payloads] ] 1323 There are two forms of replies for a STATUS. The normal form is: 1325 REPLY KINK Header 1326 KINK_AP_REP 1327 [ [KINK_ENCRYPT] 1328 [KINK_ERROR] 1329 KINK_ISAKMP 1330 [Notification Payloads] ] 1332 If the respondent finds a Kerberos error for which it can produce a 1333 valid authenticator, the REPLY takes the following form: 1335 REPLY KINK Header 1336 KINK_AP_REP 1337 [KINK_ENCRYPT] 1338 KINK_KRB_ERROR 1340 If the respondent finds a KINK or Kerberos type of error it MUST 1341 reply with a lone KINK_KRB_ERROR or KINK_ERROR payload: 1343 REPLY 1344 KINK Header 1345 [KRB_ERROR] 1346 [KINK_KRB_ERROR] 1348 8. Key Derivation 1350 KINK uses the same key derivation mechanisms that [IKE] uses in sec- 1351 tion 5.5, which is: 1353 KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b]) 1355 The following differences apply: 1357 o SKEYID_d is the session key in the Kerberos service ticket from 1358 the AP-REQ. 1360 o Nr_b is optional 1362 By optional, it is meant that the equivalent of a zero length 1363 nonce was supplied. 1365 Note that g(qm)^xy refers to the keying material generated when KE 1366 payloads are supplied using Diffie Hellman key agreement. This is 1367 explained in section 5.5 of [IKE]. 1369 9. Transport Considerations 1371 KINK uses UDP on port [XXX -- TBA by IANA] to transport its messages. 1372 There is one timer T which SHOULD take into consideration round trip 1373 considerations and MUST implement a truncated exponential backoff 1374 mechanism. The state machine is simple: any message which expects a 1375 response MUST retransmit the request using timer T. Since Kerberos 1376 requires that messages be retransmitted with new times for replay 1377 protection, the message MUST be recreated each time including the 1378 checksum of the message. Both commands and replies with the ACKREQ 1379 bit set are kept on retransmit timers. When a KINK initiator receives 1380 a REPLY with the ACKREQ bit set, it MUST retain the ability to regen- 1381 erate the ACK message for the transaction for a minimum of its a full 1382 retransmission timeout cycle or until it notices that packets have 1383 arrived on the newly constructed SA, whichever comes first. 1385 When a KINK peer retransmits a message, it MUST create a new Kerberos 1386 authenticator for the AP-REQ so that the peer can differentiate 1387 between replays and dropped packets. This results in a potential race 1388 condition when a retransmission occurs before an in-flight reply is 1389 received/processed. To counter this race condition, the retransmit- 1390 ting party SHOULD keep a list of valid authenticators which are out- 1391 standing for any particular transaction. 1393 10. Security Considerations 1395 KINK cobbles together and reuses many parts of both Kerberos and IKE, 1396 the latter which in turn is cobbled together from many other memos. 1397 As such, KINK inherits many of the weaknesses and considerations of 1398 each of its components. However, KINK uses only IKE Phase II payloads 1399 to create and delete security associations, the security considera- 1400 tions which pertain to IKE Phase I may be safely ignored. 1402 KINK's use of Kerberos presents a couple of considerations. First, 1403 KINK explicitly expects that the KDC will provide adequate entropy 1404 when it generates session keys. Second, Kerberos is used as a user 1405 authentication protocol with the possibility of dictionary attacks on 1406 user passwords. This memo does not describe a particular method to 1407 avoid these pitfalls, but recommends that suitable randomly generated 1408 keys be used for the service principals such as using the -randomkey 1409 option with MIT's "kadmin addprinc" command as well as for clients 1410 when that is practical. 1412 Kerberos itself does not provide for perfect forward secrecy which 1413 makes KINK's reliance on the IKE ability to do PFS somewhat suspect 1414 from an overall system's standpoint. In isolation KINK itself should 1415 be secure from offline analysis from compromised principal 1416 passphrases if PFS is used, but the existence of other Kerberized 1417 service which do not provide PFS makes this a less than optimal 1418 situation on the whole. 1420 10.1. Security Policy Database Considerations 1422 KINK leaves the population of the IPsec security policy database out 1423 of scope. There are, however, considerations which should be pointed 1424 out. First, even though when and when not to initiate a user to user 1425 flow is left to the discretion of the KINK implementation, a Kerberos 1426 client which initially authenticated using a symmetric key SHOULD NOT 1427 use a user-user flow if the respondent is also in the same realm. 1428 Likewise, a KINK initiator which authenticated in a public key realm 1429 SHOULD use a user-user flow if the respondent is in the same realm. 1431 At a minimum the security policy database for a KINK implementation 1432 SHOULD contain a logical record of the KDC to contact, principal name 1433 for the respondent, and whether the KINK implementation should use a 1434 direct AP-REQ/AP-REP flow, or a User-User flow to CREATE/DELETE the 1435 security association. 1437 That said, there is considerable room for improvement on how a KINK 1438 initiator could auto-discover how a respondent in a different realm 1439 initially authenticated. This is left as an implementation detail as 1440 well as the subject of possible future standardization efforts which 1441 are outside of the scope of the KINK working group. 1443 11. IANA Considerations 1445 KINK requires that a new well known system port for UDP be created. 1446 Since KINK uses standard message types from [IKE], KINK does not 1447 require any new registries. Any new DOI's, ISAKMP types, etc for 1448 future versions of KINK MUST use the registries defined for [IKE]. 1450 In addition, the ISAKMP payload types currently don't have a IANA 1451 registry, but needs one. KINK defines its payload constants as a 1452 sequential set of integers from KINK_ISAKMP_PAYLOAD_BASE to 1453 KINK_ISAKMP_PAYLOAD_BASE+7. 1455 12. Forward Compatibility Considerations 1457 KINK can accommodate future versions of Quick Mode through the use of 1458 the version field in the ISAKMP payload as well as new domains of 1459 interpretation. In this memo, the only supported Quick Mode version 1460 is 1.0 which corresponds to [IKE]. Likewise, the only DOI suported is 1461 the IPsec domain of interpretation [IPDOI]. New Quick Mode versions 1462 and DOI's MUST be described in subsequent memos. 1464 KINK implementations MUST reject ISAKMP versions which are greater 1465 than the highest currently supported version with a KINK_BADQMVERS 1466 error type. A KINK implementation which receives a KINK_BADQMVERS 1467 message SHOULD be capable of reverting back to version 1.0. 1469 The following sections describe how different quick-modes and dif- 1470 ferent DOI's can be used within the KINK framework. 1472 12.1. New Versions of Quick Mode 1474 The ipsec working group is defining the next generation IKE protocol 1475 (IKEv2) which uses a slightly different quick mode from the one in 1476 IKE v1. While the format of IKEv2 is not yet finalized, it does serve 1477 as an example. 1479 The only difference between the two is the format of the payloads 1480 that contain the IPsec traffic selectors. Formerly, these were over- 1481 loaded into the ID payloads, and now they are carried in slightly 1482 more powerful TS (Traffic Selector) payloads. 1484 Were KINK to replace the IKEv2 'CREATE_CHILD_SA' for the current 1485 scheme, we would replace the contents of the KINK_ISAKMP payload 1486 (which currently contains a simplified version of the IKEv1 Quick- 1487 mode payloads) with the set of new payloads. Since the IKEv2 1488 CREATE_CHILD_SA exchange is still part of the IPsec DOI (see A.2), 1489 only the QMMaj version number in the KINK_ISAKMP header would be 1490 bumped to a new (higher) version number to indicate the new expected 1491 format of the contents of the KINK_ISAKMP payload. No other changes 1492 would be needed. 1494 KINK, therefore, merely acts as a transport mechanism to a Quick-mode 1495 exchange. 1497 12.2. New DOI 1499 The KINK message header contains a field called "Domain of Interpre- 1500 tation (DOI)" to allow other domains of interpretation to use KINK 1501 as a secure transport mechanism for keying. 1503 As one example of a new DOI, the MSEC working group is currently 1504 defining the GDOI (Group Domain of Interpretation), which defines a 1505 few new messages, which look like ISAKMP messages, but are not 1506 defined in ISAKMP. 1508 In order to carry GDOI messages in KINK, the DOI field in the KINK 1509 header would indicate that GDOI is being used, instead of IPSEC-DOI, 1510 and the KINK_ISAKMP payload would contain the payloads defined in the 1511 GDOI draft rather than the payloads used by [IKE] Quick Mode. The 1512 version number in the KINK_ISAKMP header is related to the DOI in the 1513 KINK header, so a maj.min version 1.0 under DOI GDOI is different 1514 from a maj.min version 1.0 under DOI IPSEC-DOI. 1516 13. Related Work 1518 The IPsec working group has defined a number of protocols that pro- 1519 vide the ability to create and maintain cryptographically secure 1520 security associations at layer three (ie, the IP layer). This effort 1521 has produced two distinct protocols: 1523 o a mechanism for encrypting and authenticating IP datagram 1524 payloads which assumes a shared secret between the sender and 1525 receiver 1527 o a mechanism for IPsec peers to perform mutual authentication 1528 and exchange keying material 1530 The IPsec working group has defined a peer to peer authentication and 1531 keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer to 1532 peer protocol is that each peer must know and implement a site's 1533 security policy which in practice can be quite complex. In addition, 1534 the peer to peer nature of IKE requires the use of Diffie Hellman 1535 (DH) to establish a shared secret. DH, unfortunately, is computation- 1536 ally quite expensive and prone to denial of service attacks. IKE also 1537 relies on X.509 certificates to realize scalable authentication of 1538 peers. Digital signatures are also computationally expensive and cer- 1539 tificate based trust models are difficult to deploy in practice. 1540 While IKE does allow for pre-shared symmetric keys, key distribution 1541 is required between all peers -- an O(n2) problem -- which is prob- 1542 lematic for large deployments. 1544 14. Normative References 1546 [KERBEROS] 1547 J. Kohl, C. Neuman. The Kerberos Network Authentication Service 1548 (V5). Request for Comments 1510. 1550 [IPSEC] 1551 S. Kent, R. Atkinson. Security Architecture for the Internet 1552 Protocol. Request for Comments 2401. 1554 [IKE]D. Harkins, D. Carrel. The Internet Key Exchange (IKE). 1555 Request for Comments 2409. 1557 [ISAKMP] 1558 Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 1559 "Internet Security Association and Key Management Protocol 1560 (ISAKMP)", RFC 2408, November 1998. 1562 [IPDOI] 1563 Piper, D., "The Internet IP Security Domain Of Interpretation 1564 for ISAKMP", RFC 2407, November 1998. 1566 15. Informative References 1568 [RFC2412] 1569 Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 1570 November 1998. 1572 [RFC793] 1573 Postel, J., "Transmission Control Protocol", RFC 793, Sep-01- 1574 1981 1576 [KERB]B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 1577 for Computer Networks, IEEE Communications, 32(9):33-38. Sep- 1578 tember 1994. 1580 [PKINIT] 1581 B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray, 1582 J. Trostle. Public Key Cryptography for Initial Authentication 1583 in Kerberos. draft-ietf-cat-kerberos-pk-init-11.txt 1585 [PKCROSS] 1586 M.Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik, A. Medvinsky, 1587 B. Sommerfeld. Public Key Cryptography for Cross-Realm Authen- 1588 tication in Kerberos. draft-ietf-cat-kerberos-pk-cross-06.txt 1590 16. Mailing List 1592 Please send comments to the KINK mailing list (ietf-kink@vpnc.org). 1593 You can subscribe by sending mail to ietf-kink-request@vpnc.org with 1594 a line in the body of the mail with the word SUBSCRIBE in it. 1596 17. Author's Addresses 1598 Michael Thomas 1599 Jan Vilhuber 1600 Cisco Systems 1601 170 West Tasman Drive 1602 San Jose, CA 95134 1603 E-mail: {mat,vilhuber}@cisco.com 1605 18. Acknowledgments 1607 Many have contributed to the KINK effort, including our working group 1608 chairs Derek Atkins and Jonathan Trostle. The original inspiration 1609 came from Cablelab's Packetcable effort which defined a simplifed 1610 version of Kerberized IPsec, including Sasha Medvinsky, Mike Froh, 1611 and Matt Hur and David McGrew. The inspiration for wholly reusing IKE 1612 Phase II is the result of the Tero Kivinen's draft suggesting graft- 1613 ing Kerberos authentication onto quick mode. 1615 19. IPR Notice 1617 The IETF takes no position regarding the validity or scope of any 1618 intellectual property or other rights that might be claimed to per- 1619 tain to the implementation or use of the technology described in this 1620 document or the extent to which any license under such rights might 1621 or might not be available; neither does it represent that it has made 1622 any effort to identify any such rights. Information on the IETF's 1623 procedures with respect to rights in standards-track and standards- 1624 related documentation can be found in BCP-11. Copies of claims of 1625 rights made available for publication and any assurances of licenses 1626 to be made available, or the result of an attempt made to obtain a 1627 general license or permission for the use of such proprietary rights 1628 by implementors or users of this specification can be obtained from 1629 the IETF Secretariat. 1631 The IETF invites any interested party to bring to its attention any 1632 copyrights, patents or patent applications, or other proprietary 1633 rights which may cover technology that may be required to practice 1634 this standard. Please address the information to the IETF Executive 1635 Director. 1637 20. Full Copyright 1639 Copyright (C) The Internet Society (2003). All Rights Reserved. 1641 This document and translations of it may be copied and furnished to 1642 others, and derivative works that comment on or otherwise explain it 1643 or assist in its implementation may be prepared, copied, published 1644 and distributed, in whole or in part, without restriction of any 1645 kind, provided that the above copyright notice and this paragraph are 1646 included on all such copies and derivative works. However, this 1647 document itself may not be modified in any way, such as by removing 1648 the copyright notice or references to the Internet Society or other 1649 Internet organizations, except as needed for the purpose of develop- 1650 ing Internet standards in which case the procedures for copyrights 1651 defined in the Internet Standards process must be followed, or as 1652 required to translate it into languages other than English. 1654 The limited permissions granted above are perpetual and will not be 1655 revoked by the Internet Society or its successors or assigns. 1657 This document and the information contained herein is provided on an 1658 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1659 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1660 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1661 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 1662 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. #.PX