idnits 2.17.00 (12 Aug 2021) /tmp/idnits15479/draft-ietf-kink-kink-02.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 32 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 33 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 74 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([KERBEROS], [IPSEC], [ISAKMP], [IKE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 227 has weird spacing: '...service ticke...' == Line 245 has weird spacing: '...ecurity assoc...' == Line 246 has weird spacing: '... takes an "...' == Line 247 has weird spacing: '...pondent will ...' == Line 248 has weird spacing: '... the initia...' == (69 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 (October 20, 2001) is 7517 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: 'IKE' is mentioned on line 1358, but not defined == Missing Reference: 'KERB' is mentioned on line 69, but not defined == Missing Reference: 'STD-2' is mentioned on line 489, but not defined == Missing Reference: 'KRBREVS' is mentioned on line 702, but not defined == Missing Reference: 'KE' is mentioned on line 1116, but not defined == Missing Reference: 'IDci' is mentioned on line 1130, but not defined == Missing Reference: 'IDcr' is mentioned on line 1130, but not defined == Unused Reference: 'RFC2412' is defined on line 1424, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (ref. 'KERBEROS') (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 == Outdated reference: A later version (-08) exists of draft-ietf-cat-kerberos-pk-cross-06 -- Possible downref: Normative reference to a draft: ref. 'PKCROSS' ** 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) ** Downref: Normative reference to an Informational RFC: RFC 2412 Summary: 12 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 Editor 4 M. Froh 5 Cybersafe 6 M. Hur 7 D. McGrew 8 J. Vilhuber 9 Cisco 10 S Medvinsky 11 Motorola 12 October 20, 2001 14 Kerberized Internet Negotiation of Keys (KINK) 15 draft-ietf-kink-kink-02.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-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 Copyright Notice 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 Abstract 42 KINK defines a low-latency, computationally inexpensive, easily 43 managed, and cryptographically sound protocol to set up and maintain 44 [IPSEC] security associations using [KERBEROS] authentication. KINK 45 reuses many [ISAKMP] Quick Mode payloads to create, delete and 46 maintain IPsec security associations which should lead to substantial 47 reuse of existing [IKE] implementations. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119. 55 1. Introduction 57 KINK is designed to provide a secure, scalable mechanism for estab- 58 lishing keys between communicating entities within a centrally 59 managed environment in which it is important to maintain consistent 60 security policy. The security goals of KINK are to provide privacy, 61 authentication, and replay protection of key management messages, and 62 to avoid denial of service vulnerabilities whenever possible. The 63 performance goals of the protocol are to incur a low computational 64 cost, to have low latency, to have a small footprint, and to avoid or 65 minimize the use of public key operations. In particular, the proto- 66 col provides the capability to establish security associations in two 67 messages with minimal computational effort. 69 Kerberos [KERB] and [KERBEROS] provides an efficient mechanism for 70 trusted third party authentication for clients and servers. (Ker- 71 beros also provides an mechanisms for inter-realm authentication 72 natively and with [PKCROSS].) Clients obtain tickets from an online 73 authentication server (the Key Distribution Center or KDC). Tickets 74 are then used to construct credentials for authenticating the client 75 to the server. As a result of this authentication operation, the 76 client and the server will also share a secret. KINK uses this pro- 77 perty as the basis of distributing keys for IPsec. 79 The central key management provided by Kerberos is efficient because 80 it limits computational cost and limits complexity versus IKE's 81 necessity of using public key cryptography. Initial authentication 82 to the KDC may be performed using either symmetric keys or asymmetric 83 keys using [PKINIT]; however, subsequent requests for tickets, as 84 well as authenticated exchanges between client and server always 85 utilize symmetric cryptography. Therefore, public key operations (if 86 any) are limited and are amortized over the lifetime of the initial 87 authentication operation to the Kerberos KDC. For example, a client 88 may use a single public key exchange with the KDC to efficiently 89 establish multiple security associations with many other servers in 90 the extended realm of the KDC. Kerberos also scales better than 91 direct peer to peer keying when symmetric keys are used. The reason 92 is that since the keys are stored in the KDC, the number of principal 93 keys is O(n) rather than O(n*m), where "n" is the number of clients 94 and "m" is the number of servers. 96 This document specifies the Kerberized Internet Negotiation of Keys 97 Protocol and the domain of interpretation (DOI) for establishing and 98 maintaining IPsec Security Associations [IPSEC]. No other domains of 99 interpretation are defined in this document. 101 2. Terminology 103 Ticket 104 A Kerberos term for a record that helps a client authenticate 105 itself to a server; it contains the client's identity, a session 106 key, a lifetime, and other information, all sealed using the 107 server's secret key. The combination of a ticket and an authentica- 108 tor (which proves freshness and knowledge of the key within the 109 ticket) creates an authentication credential. 111 KDC 112 Key Distribution Center, a network service that supplies tickets 113 and temporary session keys; or an instance of that service or the 114 host on which it runs. The KDC services both initial ticket and 115 Ticket-Granting Ticket (TGT) requests. The initial ticket portion 116 is referred to as the Authentication Server (or service). The 117 Ticket-Granting Ticket portion is referred to as the Ticket- 118 Granting Server (or service). 120 Realm 121 A Kerberos administrative domain. A single KDC may be responsible 122 for one or more realms. A fully qualified principal name includes 123 a realm name along with a principal name unique within that realm. 125 TGT 126 A ticket granting ticket is a normal Kerberos ticket which the KDC 127 issues for the Kerberos service. The main purpose of a TGT is to 128 capture the results of initial authentication for subsequent ticket 129 granting requests, thus providing a single sign-on service. 131 User-User 132 Kerberos normally divides the world into clients and servers where 133 the server maintains a table of keys (keytab) which is used to 134 encrypt/decrypt service tickets. In situations where a principal 135 may not have a keytab (ex. a human/client principal rather than a 136 service principal), Kerberos provides the means of issuing what is 137 known as a User-User ticket. To produce the User-User ticket, the 138 KDC requires the ticket granting tickets from both client princi- 139 pals. Kerberos does not specify a means obtaining a client's 140 ticket granting ticket, and is thus application specific. 142 Principal 143 Kerberos named entities are known as principals, and are roughly 144 equivalent to X.509 distinguished names. Principals are either 145 client or service principals. A principal is an entity that 146 engages in a security relationship. A Kerberos principal name is 147 roughly equivalent to an X.509 distinguished name (it associates 148 the principal with an adminsitrative domain). Principals may be 149 client or servers. A server principal is generally distinguished 150 by a flag in a KDC principal database and by a keytab maintained by 151 the server. 153 DER 154 ASN.1 Distinguished Encoding Rules; Kerberos version 5 uses this 155 encoding format of ASN.1. 157 Quick-Mode 158 IKE defines two phases: an authentication phase (phase 1, or Main 159 Mode) and a security association maintenance phase (phase 2, or 160 Quick Mode). KINK reuses IKE Quick Mode. 162 AP-REQ/AP-REP 163 Kerberos defines an standardized message format and transport for 164 contacting a KDC to perform initial authentication, and for grant- 165 ing subsequent service tickets. When a client needs to authenticate 166 to a server, Kerberos provides a standardized message format, but 167 leaves the transport as application specific. The messages which 168 perform this function are AP-REQ between the client and the server, 169 and AP-REP between the server and client if mutual authentication 170 is needed. 172 3. Protocol Overview 174 KINK is a command/response protocol which can create, delete and 175 maintain IPsec security associations. Each command or response con- 176 tains a common header along with a set of type-length-value payloads 177 which are constrained according to the type of command or response. 178 KINK itself is a stateless protocol in that each command or response 179 does not require storage of hard state for KINK itself. This is in 180 contrast to IKE's use of Main Mode to first establish an ISAKMP secu- 181 rity association followed by subsequent Quick Mode exchanges. 183 KINK uses Kerberos mechanisms to provide mutual authentication, 184 replay protection. For security association establishment. KINK pro- 185 vides privacy of the payloads which follow the Kerberos authentica- 186 tor. KINK's design mitigates denial of service attacks by requiring 187 authenticated exchanges before the use of any public key operations 188 and the installation of any state. KINK also provides the means of 189 using Kerberos User-User mechanisms when there isn't a key shared 190 between the server and the KDC. This is typically -- but not limited 191 to -- the case with IPsec peers using [PKINIT] for initial authenti- 192 cation. 194 KINK directly reuses [ISAKMP] Quick Mode payloads, with some minor 195 changes and omissions. In most cases, KINK exchanges are a single 196 command and its response. The lone exception is the CREATE command 197 which allows a final acknowledgment message when the respondent needs 198 a full three-way handshake. This is only needed when the optimistic 199 keying route is not taken, though it is expected that that will not 200 be the norm. KINK also provides rekeying and dead peer detection as 201 basic features. 203 4. Message Flows 205 KINK message flows all follow the same pattern between the two peers: 206 a command, a response and a possible acknowledgment with CREATE's. 207 The actual Kerberos KDC traffic here is for illustrative purposes 208 only. In practice, when a principal obtains various tickets is a sub- 209 ject of Kerberos and local policy consideration. In these flows, we 210 assume that A and B both have TGT's from their KDC. 212 4.1. Standard KINK Message Flow 214 A B KDC 215 ------ ------ --- 216 1 COMMAND-------------------> 218 2 <------------------REPLY 220 3 [ ACK---------------------> ] 222 Figure 1: KINK Message Flow 224 4.2. GETTGT Message Flow 226 If the initiator determines that it will not be able to get a normal 227 service ticket for the respondent (eg, B is a client principal), it 228 MUST first fetch the TGT from the respondent in order to get a User- 229 User service ticket: 231 A B KDC 232 ------ ------ --- 233 1 GETTGT+KRB_TGT_REQ-------> 235 2 <-------REPLY+KRB_TGT_REP 237 3 TGS-REQ+TGT(B)-------------------------------------> 239 4 <--------------------------------------------TGS-REP 241 Figure 2: GETTGT Message Flow 243 4.3. CREATE Security Association 245 This flow instantiates a security association. The CREATE command 246 takes an "optimistic" approach where security associations are 247 initially created on the expectation that the respondent will chose 248 the initial proposed payload. The optimistic payload is defined as 249 the first transform of the first proposal of the first conjugate. 250 The initiator MUST checks to see if the optimistic payload was 251 selected by comparing all transforms and attributes which MUST be 252 identical from the initiator's optimistic proposal with the lone 253 exception of LIFE_KILOBYTES and LIFE_SECONDS. Both of these 254 attributes MAY be set to a lower value by the respondent and still 255 expect optimistic keying, but MUST NOT be set to a higher value which 256 MUST generate an error. 258 CREATE'ing a security association on an existing SPI is an error in 259 KINK and MUST be rejected with an ISAKMP notification of INVALID-SPI. 261 A B KDC 262 ------ ------ --- 264 A creates initial inbound SA (B->A) 266 1 CREATE+ISAKMP------------> 268 B creates inbound SA to A (A->B). If B chooses A's optimistic 269 proposal, it creates the outbound SA as well (B->A). 271 2 <------------REPLY+ISAKMP 273 A creates outbound SA and modifies inbound SA if it first 274 proposal wasn't acceptable. 276 3 [ ACK--------------------> ] 278 [ B creates the outbound SA to A (B-A). ] 280 Figure 3: CREATE Message Flow 282 The security associations are instantiated as follows: In step one 283 host A creates an inbound security association in its security asso- 284 ciation database from B->A using the optimistic proposal in the 285 ISAKMP SA proposal. It is then ready to receive any messages from B. 286 A then sends the CREATE message to B. If B agrees to A's optimistic 287 proposal, B instantiates a security association in its database from 288 A->B. B then instantiates the security association from B->A. It then 289 sends a REPLY to A without a NONCE payload and without requesting an 290 ACK. If B does not choose the first proposal, it sends the actual 291 choice in the REPLY, a NONCE payload and requests that the REPLY be 292 acknowledged. Upon receipt of the REPLY, A modifies the inbound secu- 293 rity association as necessary, instantiates the security association 294 from A->B, If B requested an ACK, A now sends the ACK message. Upon 295 receipt of the ACK, B installs the final security association from 296 B->A. 298 Note: if B adds a nonce, or does not choose the first proposal, it 299 MUST request an ACK so that it can install the final outbound secu- 300 rity association. The initiator MUST always generate an ACK if the 301 ACKREQ bit is set in the KINK header, even if it believes that the 302 respondent was in error. 304 4.3.1. CREATE Key Derivation Considerations 306 The CREATE command's optimistic approach allows a security associa- 307 tion to be created in two messages rather than three. The implication 308 of a two message exchange is that B will not contribute to the key 309 since A must set up the inbound security association before it 310 receives any additional keying material from B. Under normal cir- 311 cumstances this may be suspect, however KINK takes advantage of the 312 fact that the KDC provides a reliable source of randomness which is 313 used in key derivation. In many cases, this will provide an adequate 314 session key so that B will not require an acknowledgment. Since B is 315 always at liberty to contribute to the keying material, this is 316 strictly a key strength versus number of messages tradeoff which KINK 317 implementations may decide as a matter of policy. 319 4.4. DELETE Security Association 321 The DELETE command deletes an existing security association. The DOI 322 specific payloads describe the actual security association to be 323 deleted. For the IPSEC DOI, those payloads will include an ISAKMP 324 payload contains the SPI to be deleted in each direction. 326 A B KDC 327 ------ ------ --- 329 A deletes outbound SA to B 331 1 DELETE+ISAKMP------------> 333 B deletes inbound and outbound SA to A 335 2 <-------------REPLY+ISAKMP 337 A deletes inbound SA to B 339 Figure 4: DELETE Message Flow 341 The DELETE command takes a "pessimistic approach" which does not 342 delete incoming security associations until it receives acknowledg- 343 ment that the other host has received the DELETE. The exception to 344 the pessimistic approach is if the initiator wants to immediately 345 cease all activity on an incoming SA. In this case, it MAY delete the 346 incoming SA as well in step one. If the receiver cannot find an 347 appropriate SPI to delete, it MUST return an ISAKMP INVALID_SPI 348 notification which also serves to inform the initiator that it can 349 delete the incoming SA. For simplicity, KINK does not allow half open 350 security associations; thus upon receiving a DELETE, the responder 351 MUST delete its security associations, and MUST reply with ISAKMP 352 delete notification messages if the SPI is found. 354 A race condition with DELETE exists. Packets in flight while the 355 DELETE operation is taking place may, due to network reordering, etc, 356 arrive after the diagrams above recommend deleting the incoming secu- 357 rity association. A KINK implementation SHOULD implement a grace 358 timer which SHOULD be set to a period of at least two times the aver- 359 age round trip time, or to a configurable value. A KINK implementa- 360 tion MAY chose to set the grace period to zero at appropriate times 361 to ungracefully delete a security association. The behavior described 362 here loosely mimics the behavior of the TCP [RFC793] flags FIN and 363 RST. 365 4.4.1. Rekeying Security Associations 367 KINK requires the initiator of a security association to be responsi- 368 ble for rekeying a security association. The reason is twofold: the 369 first is to prevent needless duplication of security associations as 370 the result of collisions due to an initiator and respondent both try- 371 ing to renew an existing security association. The second reason is 372 due to the client/server nature of Kerberos exchanges which expects 373 the client to get and maintain tickets. While KINK requires that a 374 KINK host be able to get and maintain tickets, in practice it is 375 often advantageous for servers to wait for clients to initiate ses- 376 sions so that they do not need to maintain a large ticket cache. 378 There are no special semantics for rekeying security associations in 379 KINK. That is, in order to rekey an existing security association, 380 the initiator must CREATE a new security association followed by 381 either DELETE'ing the old security association or letting it time 382 out. When identical flow selectors are available on different secu- 383 rity associations, KINK implementations SHOULD choose the security 384 association most recently created. It should be noted that KINK 385 avoids most of the problems of [IKE] rekeying by having a reliable 386 delete mechanism. 388 Normally a KINK implementation which rekeys existing security associ- 389 ations will try to rekey the security association ahead of a hard SA 390 expiration. We call this time the rekey time Trekey. In order to 391 avoid synchronization with similar implementations, KINK initiators 392 MUST randomly pick a rekeying time between Trekey and the SA expira- 393 tion time minus the amount of time it would take to go through a full 394 retransmission time cycle, Tretrans. Trk SHOULD be set at least twice 395 as high as Tretrans. 397 4.4.2. Dead Peer Detection 399 In order to determine that a KINK peer has lost its security database 400 information, KINK peers MUST record the current epoch for which they 401 have valid SADB information and reflect that epoch in each AP-REQ and 402 AP-REP message. When a KINK peer creates state for a given security 403 association, it MUST also record the principal's epoch as well. If it 404 discovers on a subsequent message that the principal's epoch has 405 changed, it MUST consider all security associations created by that 406 principal as invalid, and take some action such as tearing those SA's 407 down. 409 It should be noted that KINK alone cannot provide a complete solution 410 for dead peer detection since in many situations a KINK peer would 411 have no reason to send subsequent KINK messages from whence it could 412 determine the epoch mismatch. The larger picture may require some 413 assistance from the IP layer itself to inform IPsec peers that they 414 are sending SA protected data into a black hole. Assuming this 415 mechanism is eventually defined, KINK peers SHOULD use this informa- 416 tion as a hint that something is amiss and perform a dead peer detec- 417 tion operation by using the STATUS message to elicit a response which 418 contains the peer's current epoch. Since the STATUS message is 419 integrity protected, it in combination with network layer messaging 420 should provide a secure means of recovery from dead peers. 422 4.5. STATUS Message Flow 424 At any point, a sender may send status, normally in the form of DOI 425 specific payloads to its peer. In the case of the IPsec DOI, these 426 are generally in the form of ISAKMP Notification Payloads. 428 A B KDC 429 ------ ------ --- 431 1 STATUS+ISAKMP------------> 433 2 <-------------REPLY+ISAKMP 435 Figure 5: STATUS Message Flow 437 5. KINK Message Format 439 All values in KINK are formatted in network byte order: Most 440 Significant Byte first. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type | MjVer | MnVer | Length | 446 +---------------+---------------+---------------+---------------+ 447 | Domain of Interpretation (DOI) | 448 +-------------------------------+-------------------------------+ 449 | Transaction ID (XID) | 450 +---------------+---------------+-+-----------------------------+ 451 | CksumLen | NextPayload |A| Reserved | 452 +---------------+---------------+-+-----------------------------+ 453 | | 454 ~ Cksum ~ 455 | | 456 +-------------------------------+-------------------------------+ 457 | | 458 ~ A series of payloads ~ 459 | | 460 +-------------------------------+-------------------------------+ 462 Figure 6: Format of a KINK message 464 Fields: 466 o Type (1 octet) - The type of message of this packet 468 Type Value 469 ----- ----- 470 RESERVED 0 471 CREATE 1 472 DELETE 2 473 REPLY 3 474 GETTGT 4 475 ACK 5 476 STATUS 6 478 o MjVer (4 bits) - Major protocol version number. This MUST be set 479 to 1. 481 o MnVer (4 bits) - Minor protocol version number. This MUST be set 482 to 0. 484 o Length (2 octets) - Length of the message in octets. Note that it 485 is legal within KINK to omit the last bytes of padding in the last 486 payload in the overall length. 488 o DOI (4 octets) - The domain of interpretation. All DOI's must be 489 registered with the IANA in the "Assigned Numbers" RFC [STD-2]. 491 The IANA Assigned Number for the Internet IP Security DOI (IPSEC 492 DOI) is one (1). This field defines the context of all other sub- 493 payloads in this payloads. If other sub-payloads have a DOI field 494 (example: Security Association Payload), then the DOI in that 495 sub-payload MUST be checked against the DOI in this header, and 496 the values MUST be the same. 498 o XID (4 octets) - The transaction ID. A KINK transaction is bound 499 together by a transaction ID which is created by the command ini- 500 tiator and replicated in subsequent messages in the transaction. A 501 transaction is defined as a command, a reply, and an optional ack- 502 nowledgment. Transaction ID's are used by the initiator to 503 discriminate between multiple outstanding requests to a respon- 504 dent. It is not used for replay protection because that func- 505 tionality is provided by Kerberos. The value of XID is chosen by 506 the initiator and MUST be unique with all outstanding transac- 507 tions. XID's MAY be constructed by using a monotonic counter, or 508 random number generator. 510 o CksumLen (2 octets) -- CksumLen is the length in octets of the 511 keyed hash of the message. A CksumLen of zero implies that the 512 message is unauthenticated. Note that as with payload padding, the 513 length here denotes the actual number of octets of the checksum 514 structure not including any padding required. 516 o NextPayload (1 octet) -- Indicates the type of the first payload 517 after the message header 519 o A (1 bit) -- ACK Request. Set to one if the responder requires an 520 explicit acknowledgment that a REPLY was received. An initiator 521 MUST NOT set this flag, nor should any other command other than 522 CREATE request an ACK and then only when the optimistic SA is not 523 chosen. 525 o Reserved (15 bits) -- Reserved and must be zero 527 o Cksum (variable) - Keyed checksum over the entire message. This 528 field MUST always be present whenever a key is available via an 529 AP-REQ or AP-REP payload. The key used MUST be the session key in 530 the ticket. When a key is not available, this field is not 531 present, and the CksumLen field is set to zero. The hash algorithm 532 used is the same as specified in the etype for the Kerberos ses- 533 sion key in the Kerberos ticket. If the etype does not specify a 534 hash algorithm, SHA1 with a 20 byte checksum MUST be used. The 535 format of the Cksum field is as follows: 537 0 1 2 3 538 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 539 +---------------+---------------+---------------+---------------+ 540 | checksum (variable) ~ padding (variable) | 541 +---------------+---------------+---------------+---------------+ 543 Figure 7: KINK Checksum 544 To compute the checksum, the checksum field is zeroed out and the 545 appropriate algorithm is run over the entire message (as given by 546 the Length field in the KINK header), and placed in the Checksum 547 field. To verify the checksum, the checksum is saved, and the 548 checksum field is zeroed out. The checksum algorithm is run over 549 the message, and the result is compared with the saved version. If 550 they do not match, the message MUST be dropped. 552 The KINK header is followed immediately by a series of 553 Type/Length/Value fields, defined in the next section. 555 5.1. KINK Payloads 557 Immediately following the header, there is a list of 558 Type/Length/Value (TLV) payloads. There can be any number of payloads 559 following the header. Each payload MUST begin with a payload header. 560 Each payload header is built on the generic payload header. Any data 561 immediately follows the generic header. Payloads are all implicitly 562 padded to 4 octet boundaries, though the payload length field MUST 563 accurately reflect the actual number of octets in the payload. 565 0 1 2 3 566 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 567 +---------------+---------------+---------------+---------------+ 568 | Next Payload | RESERVED | Payload Length | 569 +---------------+---------------+---------------+---------------+ 570 | value (variable) | 571 +---------------+---------------+---------------+---------------+ 573 Figure 8: Format of a KINK payload 575 Fields: 577 o NextPayload (2 octets) - The type of the next payload 579 NextPayload Number 580 ---- ------ 581 KINK_DONE 0 (same as ISAKMP_NEXT_NONE) 582 KINK_AP_REQ 14 583 KINK_AP_REP 15 584 KINK_KRB_ERROR 16 585 KINK_TGT_REQ 17 586 KINK_TGT_REP 18 587 KINK_ISAKMP 19 588 KINK_ENCRYPT 20 589 KINK_ERROR 21 591 NextPayload type KINK_DONE denotes that the current payload is the 592 final payload in the message. 594 Note: the payload types are taken from the ISAKMP registry for 595 payload types. As such, payloads 0-13 are used for ISAKMP, and 596 22-127 are reserved to IANA. 598 o RESERVED (1 octet) - Unused, MUST be set to 0. 600 o Length (2 octets) - The length of this payload, including the Type 601 and Length fields. 603 o Value (variable) - This value of this field depends on the Type. 605 5.1.1. KINK Padding Rules 607 KINK has the following rules regarding alignment and padding: 609 o All length fields MUST reflect the actual number of octets in the 610 structure; ie they do not account for padding bytes 612 o Between KINK payloads, checksums, headers or any other other vari- 613 able length data, the adjacent fields MUST be aligned on 4 octet 614 boundaries. 616 o Variable length fields MUST always start immediately after the 617 last octet of the previous field. Ie, they are not padded to a 4 618 octet boundary. 620 5.1.2. 5.1.1 KINK_AP_REQ Payload 622 The KINK_AP_REQ payload relays a Kerberos AP-REQ to the respondent. 623 The AP-REQ MUST request mutual authentication. The service that the 624 KINK peer SHOULD request is "kink/fqdn@REALM" where "kink" is the 625 KINK IPsec service, "fqdn" is the fully qualified domain name of the 626 service host, and REALM is the Kerberos realm of the service. The 627 exception to this rule is when User-User service is requested in 628 which case the service name MUST be the service returned in the 629 GetTGT response payload. 631 The value field of this payload has the following format: 633 0 1 2 3 634 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 635 +---------------+---------------+---------------+---------------+ 636 | Next Payload | RESERVED | Payload Length | 637 +---------------+---------------+---------------+---------------+ 638 | EPOCH | 639 +---------------------------------------------------------------+ 640 | | 641 ~ KRB_AP_REQ ~ 642 | | 643 +---------------------------------------------------------------+ 645 Figure 9: KINK_AP_REQ Payload 646 Fields: 648 o EPOCH - the absolute time at which the creator of the AP-REQ has 649 valid security database (SADB) information. Typically this is when 650 the KINK keying daemon started if it does not retain SADB informa- 651 tion across different restarts. The format of this fields is net- 652 work order encoding of the standard posix four octet time stamp. 654 o KRB_AP_REQ - The value field of this payload contains a raw Ker- 655 beros KRB_AP_REQ. 657 5.1.3. KINK_AP_REP Payload 659 The KINK_AP_REP payload relays a kerberos AP-REP to the initiator. 660 The AP-REP MUST be checked for freshness as described in [KERBEROS]. 662 The value field of this payload has the following format: 664 0 1 2 3 665 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 666 +---------------+---------------+---------------+---------------+ 667 | Next Payload | RESERVED | Payload Length | 668 +---------------+---------------+---------------+---------------+ 669 | EPOCH | 670 +---------------------------------------------------------------+ 671 | | 672 ~ KRB_AP_REP ~ 673 | | 674 +---------------------------------------------------------------+ 676 Figure 10: KINK_AP_REP Payload 677 Fields: 679 o EPOCH - the absolute time at which the creator of the AP-REP has 680 valid security database (SADB) information. Typically this is when 681 the KINK keying daemon started if it does not retain SADB informa- 682 tion across different restarts. The format of this fields is net- 683 work order encoding of the standard posix four octet time stamp. 685 o KRB_AP_REP - The value field of this payload contains a raw Ker- 686 beros KRB_AP_REP. 688 5.1.4. KINK_KRB_ERROR Payload 690 The KINK_KRB_ERROR payload relays Kerberos type errors back to the 691 initiator. The receiver MUST be prepared to receive any valid 692 [KERBEROS] error type, but the sender SHOULD send only the following 693 errors: 695 KRB5KRB_AP_ERR_BAD_INTEGRITY 696 KRB5KRB_AP_ERR_TKT_EXPIRED 697 KRB5KRB_AP_ERR_SKEW 698 KRB5KRB_AP_ERR_NOKEY 699 KRB5KRB_AP_ERR_BADKEYVER 701 KINK implementations MUST make use of keyed Kerberos errors when the 702 appropriate service key is available as specified in [KRBREVS]. In 703 particular, clock skew errors MUST be integrity protected. For 704 unauthenticated Kerberos errors, the receiver MAY choose to act on 705 them, but SHOULD take precautions against make-work kinds of attacks. 707 Note that KINK does not make use of the text or e_data field of the 708 Kerberos error message, though a compliant KINK implementation MUST 709 be prepared to receive them and MAY log them. 711 The value field of this payload has the following format: 713 0 1 2 3 714 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 715 +---------------+---------------+---------------+---------------+ 716 | Next Payload | RESERVED | Payload Length | 717 +---------------+---------------+---------------+---------------+ 718 | | 719 ~ KRB_ERROR ~ 720 | | 721 +---------------------------------------------------------------+ 723 Figure 11: KINK_KRB_ERROR Payload 725 Fields: 727 o KRB_ERROR - The value field of this payload contains a raw 728 Kerberos KRB_ERROR. 730 5.1.5. KINK_TGT_REQ Payload 732 The KINK_TGT_REQ payload provides a means to get a TGT from the peer 733 in order to obtain a User to User service ticket from the KDC 735 The value field of this payload has the following format: 737 0 1 2 3 738 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 739 +---------------+---------------+---------------+---------------+ 740 | Next Payload | RESERVED | Payload Length | 741 +---------------+---------------+---------------+---------------+ 742 | RealmNameLen | RealmName (variable) ~ 743 +---------------+---------------+---------------+---------------+ 744 | | 745 ~ RealmName(variable) ~ 746 | | 747 +---------------------------------------------------------------+ 749 Figure 12: KINK_TGT_REQ Payload 751 Fields: 753 o RealmNameLen - The length of the realm name that follows 755 o RealmName - The realm name that the responder should return a TGT 756 for. 758 o RESERVED - reserved and must be zero 760 If the responder is unable to get a TGT for the domain, it must 761 reply with a KRB_ERROR payload type. 763 5.1.6. KINK_TGT_REP Payload 765 The value field of this payload contains the TGT requested in a 766 previous KINK_TGT_REP command. 768 0 1 2 3 769 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 770 +---------------+---------------+---------------+---------------+ 771 | Next Payload | RESERVED | Payload Length | 772 +---------------+---------------+---------------+---------------+ 773 | PrincNameLen | PrincName (variable) ~ 774 +---------------+---------------+---------------+---------------+ 775 | | 776 ~ PrincName(variable) +---------------+ 777 | ~ padding | 778 +---------------------------------------------------------------+ 779 | TGTlength | TGT (variable) | 780 +-------------------------------+---------------+---------------+ 781 | ~ 782 ~ TGT (variable) +---------------+ 783 | ~ padding | 784 +---------------------------------------------------------------+ 786 Figure 13: KINK_TGT_REQ Payload 788 Fields: 790 o PrincNameLen - The length of the principal name that immediately 791 follows 793 o PrincName - The client principal that the initiator should request 794 a User to User service ticket for. 796 o TGTlength - The length of TGT that immediately follows 798 o TGT - the DER encoded TGT of the responder 800 5.1.7. KINK_ISAKMP Payload 802 The value field of this payload has the following format: 804 0 1 2 3 805 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 806 +---------------+---------------+---------------+---------------+ 807 | Next Payload | RESERVED | Payload Length | 808 +---------------+-------+-------+---------------+---------------+ 809 | InnerNextPload| QMMaj | QMMin | RESERVED | 810 +---------------+-------+-------+---------------+---------------+ 811 | Quick Mode Payloads (variable) | 812 +---------------+---------------+---------------+---------------+ 814 Figure 14: KINK_ISAKMP Payload 816 Fields: 818 o InnerNextPload - First payload type of the inner series of ISAKMP 819 payloads. 821 o QMMaj - The major version of the inner payloads. MUST be set to 1. 823 o QMMin - The minor version of the inner payloads. MUST be set to 0. 825 o RESERVED - reserved and must be zero 827 The KINK_ISAKMP payload encapsulates the IKE Quick Mode (phase 828 two) payloads to take the appropriate action dependent on the KINK 829 command. There may be any number of KINK_ISAKMP payloads within a 830 single KINK message. While IKE is somewhat fuzzy about whether 831 multiple different SA's may be created within a single IKE mes- 832 sage, KINK explicitly requires that a new ISAKMP header be used 833 for each discrete SA operation. In other words, a KINK sender MUST 834 NOT send multiple quick mode transactions within a single 835 KINK_ISAKMP payload. 837 The purpose of the Quick Mode version is to allow backward compa- 838 tibility with IKE and ISAKMP if there are subsequent revisions. At 839 the present time, the Quick Mode major and minor versions are set 840 to one and zero (1.0) respectively. These versions do not 841 correspond to the ISAKMP version in the ISAKMP header. A compliant 842 KINK implementation MUST support receipt of 1.0 payloads. It MAY 843 support subsequent versions (both sending and receiving), and 844 SHOULD provide a means to resort back to Quick Mode version 1.0 if 845 the KINK peer is unable to process future versions. A compliant 846 KINK implementation MUST NOT mix Quick Mode versions in any given 847 transaction. 849 5.1.8. KINK_ENCRYPT Payload 851 The KINK_ENCRYPT payload encapsulates other payloads and is encrypted 852 using the encryption algorithm specified by the etype of the session 853 key. This payload MUST be the final payload in the message. KINK 854 encrypt payloads MUST be encrypted before the final KINK checksum is 855 applied. 857 0 1 2 3 858 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 859 +---------------+---------------+---------------+---------------+ 860 | Next Payload | RESERVED | Payload Length | 861 +---------------+---------------+---------------+---------------+ 862 | InnerNextPload| RESERVED | 863 +---------------+---------------+---------------+---------------+ 864 | Payload (variable) | 865 +---------------+---------------+---------------+---------------+ 867 Figure 15: KINK_ENCRYPT Payload 868 Fields: 870 o InnerNextPload (variable) - First payload type of the inner series 871 of encrypted KINK payloads. 873 o RESERVED - reserved and must be zero 875 Note: the coverage of the encrypted data begins at InnerNextPload 876 so that first payload's type is kept confidential. Thus, the 877 number of encrypted octets is PayloadLength - 4. 879 The format of the encryption payload uses the normal [KERBEROS] 880 semantics of prepending a crypto-specific initialization vector 881 and padding the entire message out to the crypto-specific number 882 of bytes. For example, with DES-CBC, the initialization vector 883 will be 8 octets long, and the entire message will be padded to an 884 8 octet boundary. Note that KINK Encrypt payload MUST NOT include 885 a checksum since this is redundant with the message integrity 886 checksum in the KINK header. 888 5.1.9. KINK_ERROR Payload 890 The KINK_ERROR payload type provides a protocol level mechanism of 891 returning an error condition. This payload should not be used for 892 either Kerberos generated errors, or DOI specific errors which have 893 their own payloads defined. The error code is in network order. 895 0 1 2 3 896 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 897 +---------------+---------------+---------------+---------------+ 898 | Next Payload | RESERVED | Payload Length | 899 +---------------+---------------+---------------+---------------+ 900 | ErrorCode | 901 +---------------+---------------+---------------+---------------+ 903 Figure 16: KINK_ERROR Payload 905 ErrorCode Number Purpose 906 --------- ------ ------------------- 907 KINK_OK 0 - No error detected 908 KINK_PROTOERR 1 - The message was malformed 909 KINK_INVDOI 2 - Invalid DOI 910 KINK_INVMAJ 3 - Invalid Major Version 911 KINK_INVMIN 4 - Invalid Minor Version 912 KINK_INTERR 5 - An unrecoverable internal error was 913 detected 914 RESERVED 6 - 8191 915 Private Use 8192 - 16383 917 6. KINK Quick Mode Payload Profile 919 KINK directly uses ISAKMP payloads to negotiate security associa- 920 tions. In particular, KINK uses IKE phase II payload types (aka Quick 921 Mode). In general, there should be very few changes necessary to an 922 IKE implementation to establish the security associations, and unless 923 there is a note to the contrary in the memo, all capabilities and 924 requirements in [IKE] MUST be supported. IKE Phase I payloads MUST 925 NOT be sent. 927 Unlike IKE, KINK defines specific commands for creation, deletion, 928 and status of security associations, mainly to facilitate predictable 929 SA creation/deletion (see section 4.3 and 4.4). As such, KINK places 930 certain restrictions on what payloads may be sent with which com- 931 mands, and some additional restrictions and semantics of some of the 932 payloads. Implementors should refer to [IKE] and [ISAKMP] for the 933 actual format and semantics. If a particular IKE phase II payload is 934 not mentioned here, it means that there are no differences in its 935 use. 937 6.1. General Quick Mode Differences 939 o The Security Association Payload header for IP is defined in 940 [IPDOI] section 4.6.1. For this memo, the Domain of Interpreta- 941 tion MUST be set to 1 (IPSec) and the Situation bitmap MUST be 942 set to 1 (SIT_IDENTITY_ONLY). All other fields are omitted 943 (because SIT_IDENTITY_ONLY is set). 945 o KINK also expands the semantics of IKE in it defines an optmis- 946 tic proposal for CREATE commands to allow SA creation to com- 947 plete in two messages. 949 o IKE Quick Mode (phase 2) uses the hash algorithm used in main 950 mode (phase 1) to generate the keying material. KINK MUST use 951 the hashing algorithm specified in the session ticket's etype. 953 o KINK does not use the HASH payload at all. 955 o KINK allows the NONCE payload Nr to be optional to facilitate 956 optimistic keying. 958 6.2. Security Association Payloads 960 KINK supports the following security association attributes from 961 [IPDOI]: 963 class value type 964 ------------------------------------------------- 965 SA Life Type 1 B 966 SA Life Duration 2 V 967 Encapsulation Mode 4 B 968 Authentication Algorithm 5 B 969 Key Length 6 B 970 Key Rounds 7 B 972 Refer to [IPDOI] for the actual definitions for these attributes. 974 6.3. Proposal and Transform Payloads 976 KINK directly uses the Proposal and Transform payloads with no 977 differences. KINK, however, places additional relevance to the first 978 proposal and first transform of each conjugate for optimistic keying. 980 6.4. Identification Payloads 982 The Identification payload carries information that is used to iden- 983 tify the traffic that is to be protected using the keys exchanges in 984 this memo. KINK restricts the ID types to the following values: 986 ID Type Value 987 ------- ----- 988 ID_IPV4_ADDR 1 989 ID_IPV4_ADDR_SUBNET 4 990 ID_IPV6_ADDR 5 991 ID_IPV6_ADDR_SUBNET 6 992 ID_IPV4_ADDR_RANGE 7 993 ID_IPV6_ADDR_RANGE 8 995 6.5. Nonce Payloads 997 The Nonce payload contains random data that MUST be used in key 998 generation by the initiating KINK peer, and MAY be used by the 999 responding KINK peer. 1001 6.6. Notify Payloads 1003 Notification information can be error messages specifying why an SA 1004 could not be established. It can also be status data that a process 1005 managing an SA database wishes to communicate with a peer process. 1006 For example, a secure front end or security gateway may use the 1007 Notify message to synchronize SA communication. The table below 1008 lists the Notification messages and their corresponding values that 1009 are supported in KINK. 1011 NOTIFY MESSAGES - ERROR TYPES 1013 Errors Value 1014 INVALID-PAYLOAD-TYPE 1 1015 SITUATION-NOT-SUPPORTED 3 1016 INVALID-MAJOR-VERSION 5 1017 INVALID-MINOR-VERSION 6 1018 INVALID-EXCHANGE-TYPE 7 1019 INVALID-FLAGS 8 1020 INVALID-MESSAGE-ID 9 1021 INVALID-PROTOCOL-ID 10 1022 INVALID-SPI 11 1023 INVALID-TRANSFORM-ID 12 1024 ATTRIBUTES-NOT-SUPPORTED 13 1025 NO-PROPOSAL-CHOSEN 14 1026 BAD-PROPOSAL-SYNTAX 15 1027 PAYLOAD-MALFORMED 16 1028 INVALID-KEY-INFORMATION 17 1029 INVALID-ID-INFORMATION 18 1030 ADDRESS-NOTIFICATION 26 1031 NOTIFY-SA-LIFETIME 27 1032 UNEQUAL-PAYLOAD-LENGTHS 30 1033 RESERVED (Future Use) 31 - 8191 1034 Private Use 8192 - 16383 1036 NOTIFY MESSAGES - STATUS TYPES 1038 Status Value 1039 CONNECTED 16384 1040 RESERVED (Future Use) 16385 - 24575 1041 DOI-specific codes 24576 - 32767 1042 Private Use 32768 - 40959 1043 RESERVED (Future Use) 40960 - 65535 1045 6.7. Delete Payloads 1047 KINK directly uses ISAKMP delete payloads with no changes. 1049 6.8. KE Payloads 1051 IKE requires that perfect forward secrecy be supported through the 1052 use of the KE payload. However, Kerberos in general does not provide 1053 PFS so it is somewhat questionable whether a system which is heavily 1054 relying on Kerberos benefits from PFS. KINK retains the ability to 1055 use PFS, but relaxes the requirement from must implement to SHOULD 1056 implement. 1058 7. IPsec DOI Message Formats 1060 KINK messages are either commands, replies, or acknowledgments. A 1061 command is sent by an initiator to the respondent. A reply is sent 1062 by the respondent to the initiator. If the respondent desires confir- 1063 mation of the reply, it sets the ACKREQ bit in the message header. 1064 The ACKREQ bit MUST NOT be set by the respondent except in the lone 1065 case of a CREATE message for which one of the security associations 1066 did not use the optimistic payload. In that case, the ACKREQ bit MUST 1067 be set. All commands, responses and acknowledgments are bound 1068 together by the XID field of the message header. The XID is normally 1069 a monotonically incrementing field, and is used by the initiator to 1070 differentiate between outstanding requests to a responder. The XID 1071 field does not provide replay protection as that functionality is 1072 provided by Kerberos mechanisms. In addition, commands and responses 1073 MUST use a cryptographic hash over the entire message if the two 1074 peers share a symmetric key via a ticket exchange. 1076 7.1. REPLY Message Considerations 1078 The REPLY message is a generic reply which MUST contain either a 1079 KINK_AP_REP, a KRB-ERROR, or KINK_ERROR payload. REPLY's MAY contain 1080 additional DOI specific payloads such as ISAKMP payloads which are 1081 defined in the following sections. The checksum in the KRB-ERROR 1082 message is not used, since the KINK header already contains a check- 1083 sum field. 1085 The server MUST return a KRB_AP_ERR_SKEW if the server clock and the 1086 client clock are off by more than the policy-determined clock skew 1087 limit (usually 5 minutes). The optional client's time in the KRB- 1088 ERROR MUST be filled out, and the client MUST compute the difference 1089 (in seconds) between the two clocks based upon the client and server 1090 time contained in the KRB-ERROR message. The client SHOULD store 1091 this clock difference and use it to adjust its clock in subsequent 1092 messages. 1094 7.2. ACK Message Considerations 1095 ACK's are sent only when the ACKREQ bit is set in a REPLY message. 1096 ACK's MUST NOT contain any payloads beside a lone AP-REQ header. If 1097 the initiator detects an error in the AP-REP or any other KINK or 1098 Kerberos error, it SHOULD take remedial action by reinitiating the 1099 initial command with the appropriate error to instruct the KINK 1100 receiver how to correct its original problem. 1102 7.3. CREATE 1104 This message initiates an establishment of new Security 1105 Association(s). The CREATE message must contain an AP-REQ payload and 1106 any DOI specific payloads. 1108 CREATE KINK Header 1109 KINK_AP_REQ 1110 [KINK_ENCRYPT] 1111 KINK_ISAKMP payload 1112 SA Payload[s] 1113 Proposal Payloads 1114 Transform Payloads 1115 Nonce Payload (Ni) 1116 [KE] 1117 [IDci, IDcr] 1118 [Notification Payloads] 1120 Replies are of the following forms: 1122 REPLY KINK Header 1123 KINK_AP_REP 1124 [KINK_ENCRYPT] 1125 KINK_ISAKMP 1126 SA Payload[s] 1127 Proposal Payload 1128 Transform Payload 1129 [ Nonce Payload (Nr)] 1130 [IDci, IDcr] 1131 [Notification Payloads] 1133 Note that there MUST be at least a single proposal payload and a 1134 single transform payload in REPLY messages. Also: unlike IKE, the 1135 Nonce Payload Nr is not required, and its absence means that the 1136 optimistic mode SA's installed by the initiator are valid. If any of 1137 the first proposals are not chosen by the recipient, it MUST include 1138 the nonce payload as well to indicate that the initiator's outgoing 1139 SA's must be modified. 1141 KINK, like IKE allows the creation of many security associations in 1142 one create command. If any of the optimistic creation mode proposals 1143 is not chosen by the respondent, it MUST request an ACK. 1145 If an IPspec DOI specific error is encountered, the respondent must 1146 reply with a Notify payload describing the error: 1148 REPLY KINK Header 1149 KINK_AP_REP 1150 [KINK_ENCRYPT] 1151 [KINK_ERROR] 1152 KINK_ISAKMP 1153 [Notification Payloads] 1155 If the respondent finds a Kerberos error for which it can produce a 1156 valid authenticator, the REPLY takes the following form: 1158 REPLY KINK Header 1159 KINK_AP_REP 1160 [KINK_ENCRYPT] 1161 KINK_KRB_ERROR 1163 Finally, if the respondent finds a Kerberos or KINK type of error it 1164 which it cannot create a AP-REP for, MUST reply with a lone 1165 KINK_KRB_ERROR or KINK_ERROR payload: 1167 REPLY KINK Header 1168 [KINK_KRB_ERROR] 1169 [KINK_ERROR] 1171 7.4. DELETE 1173 This message indicates that the sending peer has deleted or will 1174 shortly delete Security Association(s) with the other peer. 1176 DELETE KINK Header 1177 KINK_AP_REQ 1178 [KINK_ENCRYPT] 1179 [ KINK_ERROR payload ] 1180 KINK_ISAKMP payload 1181 Delete Payload[s] 1182 [Notification Payloads] 1184 There are three forms of replies for a DELETE. The normal form is: 1186 REPLY KINK Header 1187 KINK_AP_REP 1188 [KINK_ENCRYPT] 1189 [ KINK_ERROR payload ] 1190 KINK_ISAKMP payload 1191 Delete Payload[s] 1192 [Notification Payloads] 1194 If an IPsec DOI specific error is encountered, the respondent must 1195 reply with a Notify payload describing the error: 1197 REPLY KINK Header 1198 KINK_AP_REP payload 1199 [ KINK_ENCRYPT payload ] 1200 [ KINK_ERROR payload ] 1201 KINK_ISAKMP payload 1202 [Notification Payloads] 1204 If the respondent finds a Kerberos error for which it can produce a 1205 valid authenticator, the REPLY takes the following form: 1207 REPLY KINK Header 1208 KINK_AP_REP 1209 [KINK_ENCRYPT] 1210 KINK_KRB_ERROR 1212 If the respondent finds a KINK or Kerberos type of error it MUST 1213 reply with a lone KINK_KRB_ERROR or KINK_ERROR payload: 1215 REPLY KINK Header 1216 [KRB_ERROR] 1217 [KINK_KRB_ERROR] 1219 7.5. STATUS 1221 The STATUS command is used in two ways: 1223 1) As a means to relay an ISAKMP Notification message 1225 2) As a means of probing a peer whether its epoch has changed for 1226 dead peer detection. 1228 STATUS contains the following payloads: 1229 KINK Header 1230 KINK_AP_REQ payload 1231 [ [KINK_ENCRYPT] 1232 [ KINK_ERROR payload ] 1233 KINK_ISAKMP payload 1234 [Notification Payloads] ] 1236 There are two forms of replies for a STATUS. The normal form is: 1238 REPLY KINK Header 1239 KINK_AP_REP 1240 [ [KINK_ENCRYPT] 1241 [KINK_ERROR] 1242 KINK_ISAKMP 1243 [Notification Payloads] ] 1245 If the respondent finds a Kerberos error for which it can produce a 1246 valid authenticator, the REPLY takes the following form: 1248 REPLY KINK Header 1249 KINK_AP_REP 1250 [KINK_ENCRYPT] 1251 KINK_KRB_ERROR 1253 If the respondent finds a KINK or Kerberos type of error it MUST 1254 reply with a lone KINK_KRB_ERROR or KINK_ERROR payload: 1256 REPLY 1257 KINK Header 1258 [KRB_ERROR] 1259 [KINK_KRB_ERROR] 1261 8. Key Derivation 1263 KINK uses the same key derivation mechanisms that [IKE] uses in sec- 1264 tion 5.5, which is: 1266 KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b [ | Nr_b]) 1268 The following differences apply: 1270 o SKEYID_d is the session key in the Kerberos service ticket from 1271 the AP-REQ. 1273 o Nr_b is optional 1275 By optional, it is meant that the equivalent of a zero length 1276 nonce was supplied. 1278 9. Transport Considerations 1280 KINK uses UDP on port [XXX -- TBA by IANA] to transport its messages. 1281 There is one timer T which SHOULD take into consideration round trip 1282 considerations and MUST implement a truncated exponential backoff 1283 mechanism. The state machine is simple: any message which expects a 1284 response MUST retransmit the request using timer T. Since Kerberos 1285 requires that messages be retransmitted with new times for replay 1286 protection, the message MUST be recreated each time including the 1287 checksum of the message. Both commands and replies with the ACKREQ 1288 bit set are kept on retransmit timers. When a KINK initiator receives 1289 a REPLY with the ACKREQ bit set, it MUST retain the ability to regen- 1290 erate the ACK message for the transaction for a minimum of its a full 1291 retransmission timeout cycle or until it notices that packets have 1292 arrived on the newly constructed SA, whichever comes first. 1294 When a KINK peer retransmits a message, it MUST create a new Kerberos 1295 authenticator for the AP-REQ so that the peer can differentiate 1296 between replays and dropped packets. This results in a potential race 1297 condition when a retransmission occurs before an in-flight reply is 1298 received/processed. To counter this race condition, the retransmit- 1299 ting party SHOULD keep a list of valid authenticators which are out- 1300 standing for any particular transaction. 1302 10. Security Considerations 1304 KINK cobbles together and reuses many parts of both Kerberos and IKE, 1305 the latter which in turn is cobbled together from many other memos. 1306 As such, KINK inherits many of the weaknesses and considerations of 1307 each of its components. However, KINK uses only IKE Phase II payloads 1308 to create and delete security associations, the security considera- 1309 tions which pertain to IKE Phase I may be safely ignored. 1311 KINK's use of Kerberos presents a couple of considerations. First, 1312 KINK explicitly expects that the KDC will provide adequate entropy 1313 when it generates session keys. Second, Kerberos is used as a user 1314 authentication protocol with the possibility of dictionary attacks on 1315 user passwords. This memo does not describe a particular method to 1316 avoid these pitfalls, but recommends that suitable randomly generated 1317 keys be used for the service principals such as using the -randomkey 1318 option with MIT's "kadmin addprinc" command as well as for clients 1319 when that is practical. 1321 Kerberos itself does not provide for perfect forward secrecy which 1322 makes KINK's reliance on the IKE ability to do PFS somewhat suspect 1323 from an overall system's standpoint. In isolation KINK itself should 1324 be secure from offline analysis from compromised principal 1325 passphrases if PFS is used, but the existence of other Kerberized 1326 service which do not provide PFS makes this a less than optimal 1327 situation on the whole. 1329 10.1. Security Policy Database Considerations 1331 KINK leaves the population of the IPsec security policy database out 1332 of scope. There are, however, considerations which should be pointed 1333 out. First, even though when and when not to initiate a user to user 1334 flow is left to the discretion of the KINK implementation, a Kerberos 1335 client which initially authenticated using a symmetric key SHOULD NOT 1336 use a user-user flow if the respondent is also in the same realm. 1338 Likewise, a KINK initiator which authenticated in a public key realm 1339 SHOULD use a user-user flow if the respondent is in the same realm. 1341 At a minimum the security policy database for a KINK implementation 1342 SHOULD contain a logical record of the KDC to contact, principal name 1343 for the respondent, and whether the KINK implementation should use a 1344 direct AP-REQ/AP-REP flow, or a User-User flow to CREATE/DELETE the 1345 security association. 1347 That said, there is considerable room for improvement on how a KINK 1348 initiator could auto-discover how a respondent in a different realm 1349 initially authenticated. This is left as an implementation detail as 1350 well as the subject of possible future standardization efforts which 1351 are outside of the scope of the KINK working group. 1353 11. IANA Considerations 1355 KINK requires that a new well known system port for UDP be created. 1356 Since KINK uses standard message types from [IKE], KINK does not 1357 require any new registries. Any new DOI's, ISAKMP types, etc for 1358 future versions of KINK MUST use the registries defined for [IKE]. 1360 12. Related Work 1362 The IPsec working group has defined a number of protocols that pro- 1363 vide the ability to create and maintain cryptographically secure 1364 security associations at layer three (ie, the IP layer). This effort 1365 has produced two distinct protocols: 1367 o a mechanism for encrypting and authenticating IP datagram 1368 payloads which assumes a shared secret between the sender and 1369 receiver 1371 o a mechanism for IPsec peers to perform mutual authentication 1372 and exchange keying material 1374 The IPsec working group has defined a peer to peer authentication and 1375 keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer to 1376 peer protocol is that each peer must know and implement a site's 1377 security policy which in practice can be quite complex. In addition, 1378 the peer to peer nature of IKE requires the use of Diffie Hellman 1379 (DH) to establish a shared secret. DH, unfortunately, is computation- 1380 ally quite expensive and prone to denial of service attacks. IKE also 1381 relies on X.509 certificates to realize scalable authentication of 1382 peers. Digital signatures are also computationally expensive and cer- 1383 tificate based trust models are difficult to deploy in practice. 1384 While IKE does allow for pre-shared symmetric keys, key distribution 1385 is required between all peers -- an O(n2) problem -- which is prob- 1386 lematic for large deployments. 1388 13. References 1390 [KERBEROS] 1391 J. Kohl, C. Neuman. The Kerberos Network Authentication Service 1392 (V5). Request for Comments 1510. 1394 [KERB]B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 1395 for Computer Networks, IEEE Communications, 32(9):33-38. Sep- 1396 tember 1994. 1398 [PKINIT] 1399 B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray, 1400 J. Trostle. Public Key Cryptography for Initial Authentication 1401 in Kerberos. draft-ietf-cat-kerberos-pk-init-11.txt 1403 [PKCROSS] 1404 M.Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik, A. Medvinsky, 1405 B. Sommerfeld. Public Key Cryptography for Cross-Realm Authen- 1406 tication in Kerberos. draft-ietf-cat-kerberos-pk-cross-06.txt 1408 [IPSEC] 1409 S. Kent, R. Atkinson. Security Architecture for the Internet 1410 Protocol. Request for Comments 2401. 1412 [IKE]D. Harkins, D. Carrel. The Internet Key Exchange (IKE). 1413 Request for Comments 2409. 1415 [ISAKMP] 1416 Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 1417 "Internet Security Association and Key Management Protocol 1418 (ISAKMP)", RFC 2408, November 1998. 1420 [IPDOI] 1421 Piper, D., "The Internet IP Security Domain Of Interpretation 1422 for ISAKMP", RFC 2407, November 1998. 1424 [RFC2412] 1425 Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 1426 November 1998. 1428 [RFC793] 1429 Postel, J., "Transmission Control Protocol", RFC 793, Sep-01- 1430 1981 1432 14. Mailing List 1434 Please send comments to the KINK mailing list (ietf-kink@vpnc.org). 1435 You can subscribe by sending mail to ietf-kink-request@vpnc.org with 1436 a line in the body of the mail with the word SUBSCRIBE in it. 1438 15. Author's Addresses 1440 Mike Froh 1441 CyberSafe Corporation 1442 180 Elgin Street 1443 Ottawa, Ontario K2P 2K3 1444 Phone: +1 613 234 7300 1445 E-mail: mike.froh@cybersafe.com 1447 Matthew Hur 1448 David McGrew 1449 Michael Thomas 1450 Jan Vilhuber 1451 Cisco Systems 1452 170 West Tasman Drive 1453 San Jose, CA 95134 1454 E-mail: {mcgrew,mat,mhur,vilhuber}@cisco.com 1456 Sasha Medvinsky 1457 Motorola 1458 6450 Sequence Drive 1459 San Diego, CA 92121 1460 +1 858 404 2367 1461 E-mail: smedvinsky@gi.com 1463 16. Acknowledgments 1465 Many have contributed to the KINK effort, including our working group 1466 chairs Derek Atkins and Jonathan Trostle. The original inspiration 1467 came from Cablelab's Packetcable effort which defined a simplifed 1468 version of Kerberized IPsec. The inspiration for wholly reusing IKE 1469 Phase II is the result of the Tero Kivinen's initial draft suggesting 1470 the obvious.