idnits 2.17.00 (12 Aug 2021) /tmp/idnits43548/draft-ietf-kink-ike-over-kkmp-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC-2409], [RFC-1510]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (16 November 2000) is 7849 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) == Outdated reference: A later version (-03) exists of draft-ietf-ipsec-ike-hash-revised-01 -- Possible downref: Normative reference to a draft: ref. 'REVISED-HASH' ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Kerberized Internet Negotiation of Keys (kink) T. Kivinen 2 INTERNET-DRAFT SSH Communications Security 3 draft-ietf-kink-ike-over-kkmp-00.txt 16 November 2000 4 Expires: 16 May 2001 6 Running IKE Phase 2 over Artificial Kerberos IKE SA 8 Status of This memo 10 This document is a submission to the IETF Kerberized Internet 11 Negotiation of Keys (KINK) Working Group. Comments are solicited and 12 should be addressed to the working group mailing list 13 (ietf-kink@vpnc.org) or to the editor. 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document defines how to create artificial IKE SA using kerberos 38 [RFC-1510]. It defines how to calculate SKEYID, cookies and IV needed by 39 the IKE SA from the Kerberos session key. After the artificial IKE SA is 40 created, it can be used to run normal IKE [RFC-2409] phase 2 negotia- 41 tions. Those negotiations include quick Mode (creating IPsec SA), new 42 group mode, delete notifications, and error notifications. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 48 3. SKEYID material Calculation . . . . . . . . . . . . . . . . . . 3 49 4. IV and Cookie Calculation . . . . . . . . . . . . . . . . . . . 3 50 5. Transmitting the KRB_AP_* Messages Inside the IKE Payload . . . 4 51 6. Example Quick Mode Negotiation . . . . . . . . . . . . . . . . . 5 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 53 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 56 1. Introduction 58 After the IKE [RFC-2409] phase 1 finishes it produces following 59 information that is used to create the IKE SA: 61 CKY-I and CKY-R 62 cookies used to identify the IKE SA. 64 SKEYID 65 a string derived from secret material known only to the active 66 players in the exchange. 68 SKEYID_e 69 keying material used by the IKE SA to protect its own messages. 71 SKEYID_a 72 keying material used by the IKE SA to authenticate its own 73 messages. 75 SKEYID_d 76 keying material used to derive keys for IPsec SAs. 78 IV 79 initialization vector used by the IKE SA for the phase 2 messages. 81 IKE SA algorithms 82 encryption, hash, and authentication algorithms. 84 The SKEYID material can easily be created from the kerberos session key 85 by just hashing it in the similar way they are created in the IKE 86 [RFC-2409]. Cookies are just random numbers, but as they should remain 87 constant over the negotiation between two parties, it would be desirable 88 to derive them from the session key so they remain constant as long as 89 the kerberos ticket is valid. Encryption, hash and authentication 90 algorithms can be fixed to be 3DES, SHA-1 and HMAC-SHA1. 92 The IKE SA identities are not used after the phase 1, thus we do not 93 need them here. 95 The IKE SA is authenticated using the normal KRB_AP_REQ added to first 96 packets in each phase 2 negotiations. The mutual authentication is done 97 only if the phase 2 negotiation includes multiple packets, in which case 98 the second packet encrypted using session key authenticates the 99 responder. 101 Before this exchange can happen the initiator must first do normal 102 kerberos authentication to KDC and receive valid kerberos ticket for the 103 responder. 105 2. Specification of Requirements 107 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 108 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 109 "OPTIONAL" to describe requirements. They are to be interpreted as 110 described in [RFC-2119] document. 112 3. SKEYID material Calculation 114 >From the kerberos ticket we have the session key, which is just a shared 115 secret with the other host. We use that session key instead of the 116 Diffie-Hellman shared secret in the SKEYID calculation. Also there is no 117 point of including the cookies in the SKEYID calculation, as they are 118 generated from the session key. The SKEYID is calculated as follows: 120 SKEYID = kerberos_session_key 121 SKEYID_d = prf(SKEYID, kerberos_session_key | 0) 122 SKEYID_a = prf(SKEYID, SKEYID_d | kerberos_session_key | 1) 123 SKEYID_e = prf(SKEYID, SKEYID_a | kerberos_session_key | 2) 125 4. IV and Cookie Calculation 127 To encrypt the Phase 2 messages the IKE SA needs a "last phase 1 CBC 128 output block". This is used to calculate the IV for the first Phase 2 129 message. Because we do not have last block of the phase 1, we calculate 130 the IV from the the KRB_AP_REQ message. The IV used for the first 131 encrypted block in the first phase 2 message is derived from a hash of a 132 concatenation of the KRB_AP_REQ and the phase 2 message id using the 133 fixed SHA-1 hash algorithm. Because the IV length for 3DES is 8 bytes, 134 we take first 8 bytes of the calculated hash. The IV is calculated like 135 this: 137 IV = SHA-1(KRB_AP_REQ | MESSAGE-ID)[0..7] 139 Cookies for the IKE SA are generated from the kerberos session key, so 140 it will remain constant as long as the kerberos session key is valid. 141 Both the initiator and responder cookies are the first 16 bytes of the 142 SHA-1 hash of the kerberos_session_key concatenated with the number 42 143 encoded as one byte. The number 42 is selected arbitrarely, so that it 144 will not match anything we already use. Initiator CKY-I and Responder 145 CKY-R are calculated like this: 147 CKY-I = SHA-1(kerberos_session_key | 42)[0..15] 148 CKY-R = SHA-1(kerberos_session_key | 42)[0..15] 150 5. Transmitting the KRB_AP_* Messages Inside the IKE Payload 152 The KRB_AP_REQ and KRB_AP_REP must be delivered from one machine to 153 another and back inside the IKE payloads, and they cannot be encrypted, 154 as the receiver of the packet does not yet know how to create the 155 encryption key because it has not yet seen the KRB_AP_REQ message. 156 Because of this we need to add a new payload to the beginning of first 157 phase 2 payload in both direction and that must be transmitted without 158 encryption. Because the rest of the payload is still encrypted the 159 encryption bit in the ISAKMP header is set. 161 This means that we need to define new payload type for that kerberos 162 message and if the next payload field in the generic header is that then 163 the first payload is in clear, and encryption starts only after that 164 payload. The whole packet is still authenticated as defined in [REVISED- 165 HASH]. 167 The phase 2 payload will look like this: 169 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 ! Initiator ! 173 ! Cookie ! 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 ! Responder ! 176 ! Cookie ! 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 ! NP = XXX ! MjVer ! MnVer ! Exchange Type ! Flags ! 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 ! Message ID ! 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 ! Length ! 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 ! Next Payload ! RESERVED ! Payload Length ! 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 ! Kerberos AP message ! 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Encrypted phase 2 payload starts here | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 The KRB_AP_REQ payload is only added to first phase 2 payload sent out 192 in one negotiation, i.e it is always in the first quick mode packet 193 going out, and it is always in all notifications and delete 194 notifications. 196 The KRB_AP_REP payload can only added to the first phase 2 payload sent 197 by the responder, i.e it is always in the second quick mode packet. It 198 is only added there if requested so. In case of kerberos error the 199 responder sends back an message containing the KRB_ERROR message in the 200 kerberos message payload, and optional IKE notification payload and 201 authentication hash payload in the body. 203 Note, that if the responder was not able to get the kerberos session key 204 from the KRB_AP_REQ, it cannot decrypt and authenticate the original 205 first message. In that case it also cannot encrypt and authenticate the 206 error message. In that case the notification and hash payloads are not 207 sent, and the encryption bit in the ISAKMP header is not set. 209 The initiator can authenticate the responder by verifying the hash 210 payload in the second quick mode packet. Only the responder can create 211 it because it knows the session key used to create authentication MAC. 212 This means that KRB_AP_REP message is not usually needed. 214 Also because this quick mode is normally used without PFS the responder 215 can immediately after receiving first packet instantiate inbound SA and 216 then send reply back to initiator. This means that when the initiator 217 receives the reply from responder it can also immediately start using 218 the SA without need to wait for the third message to reach the 219 responder. 221 The third message only gives protection against replay attacks and 222 because IPsec keys are derived also from the nonces inside the first and 223 second packet, any valid IPsec packet will also give proof of 224 liveliness. Thus responder can instantiate outbound SA immediately when 225 it receives the third quick mode message, or when it receives valid 226 authenticated IPsec packet for the inbound SA.This removes need for 227 commit bit and reduces number of round trips from 1.5 to 1 (the last 228 half round trip is already interleaved with the normal IPsec traffic). 229 This optimization should NOT be used if PFS is used, because in that 230 case instantiating the IPsec SA requires costly Diffie-Hellman 231 operation, which should be postponed to the point where replay attacks 232 are not possible. 234 6. Example Quick Mode Negotiation 236 Here is an example of quick mode negotiation between host A and host B. 238 Host A Host B 239 ------ ------ 240 HDR, KRB_AP_REQ, *HASH(1), SA, Ni, ... ---> 241 <--- HDR, [KRB_AP_REQ], *HASH(2), SA, Nr, ... 242 HDR*, HASH(3) ---> 244 Where the '*' marks where the encryption begins. 246 7. Security Considerations 248 This document assumes that the session key generated by the kerberos is 249 safe and the whole security of the IKE SA is derived from that. The 250 IPsec SAs created using the Quick Mode negotiation over that IKE SA 251 derive entropy also from the nonces passed in the negotiation, and also 252 from the Diffie-Hellman if PFS is used in the quick mode. 254 8. References 256 [REVISED-HASH] Kivinen T., "Fixing IKE Phase 1 Authentication HASH", 257 draft-ietf-ipsec-ike-hash-revised-01.txt (WORK IN PROGRESS) 259 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 260 November 1998 262 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 263 Requirement Levels", March 1997 265 [RFC-1510] Kohl, J., "The Kerberos Network Authentication Service (V5)", 266 September 1993 268 9. Authors' Addresses 270 Tero Kivinen 271 SSH Communications Security Corp 272 Fredrikinkatu 42 273 FIN-00100 HELSINKI 274 Finland 275 E-mail: kivinen@ssh.fi