idnits 2.17.1 draft-kivinen-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]), 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 (10 August 2000) is 8653 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) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XXX (KINK) T. Kivinen 2 INTERNET-DRAFT SSH Communications Security 3 draft-kivinen-ike-over-kkmp-00.txt 10 August 2000 4 Expires: 10 February 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 XXX 11 (KINK) Working Group. Comments are solicited and should be 12 addressed to the working group mailing list (ietf-kink@vpnc.org) 13 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 It defines how to calculate SKEYID, cookies and IV needed by the IKE SA 39 from the Kerberos session key. After the artificial IKE SA is created, 40 it can be used to run normal IKE [RFC-2409] phase 2 negotiations. Those 41 negotiations include quick Mode (creating IPsec SA), new group mode, 42 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 AP Messages Inside the IKE Payload . . . . . . 3 51 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 52 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 55 1. Introduction 57 After the IKE [RFC-2409] phase 1 finishes it produces following 58 information that is used to create the IKE SA: 60 CKY-I and CKY-R 61 cookies used to identify the IKE SA. 63 SKEYID 64 a string derived from secret material known only to the active 65 players in the exchange. 67 SKEYID_e 68 keying material used by the IKE SA to protect its own messages. 70 SKEYID_a 71 keying material used by the IKE SA to authenticate its own 72 messages. 74 SKEYID_d 75 keying material used to derive keys for IPsec SAs. 77 IV 78 initialization vector used by the IKE SA for the phase 2 messages. 80 IKE SA algorithms 81 encryption, hash, and authentication algorithms. 83 The SKEYID material can easily be created from the kerberos session key 84 by just hashing it in the similar way they are created in the IKE 85 [RFC-2409]. Cookies are just random numbers, but as they should remain 86 constant over the negotiation between two parties, it would be desirable 87 to derive them from the session key so they remain constant as long as 88 the kerberos ticket is valid. Encryption, hash and authentication 89 algorithms can be fixed to be 3DES, SHA-1 and HMAC-SHA1. 91 The IKE SA is authenticated using the normal kerberos AP request added 92 to first packet in each phase 2 negotiations. The mutual authentication 93 is done only if the phase 2 negotiation includes multiple packets, in 94 which case the second packet encrypted using session key authenticates 95 the responder. 97 Before this exchange can happen the initiator must first do normal 98 kerberos authentication to KDC and receive valid kerberos ticket for the 99 responder. 101 2. Specification of Requirements 103 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 104 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 105 "OPTIONAL" to describe requirements. They are to be interpreted as 106 described in [RFC-2119] document. 108 3. SKEYID material Calculation 110 >From the kerberos ticket we have the session key, which is just a shared 111 secret with the other host. We use that session key instead of the 112 Diffie-Hellman shared secret in the SKEYID calculation. Also there is no 113 point of including the cookies in the SKEYID calculation, as they are 114 generated from the session key. The SKEYID is calculated as follows: 116 SKEYID = kerberos_session_key 117 SKEYID_d = prf(SKEYID, kerberos_session_key | 0) 118 SKEYID_a = prf(SKEYID, SKEYID_d | kerberos_session_key | 1) 119 SKEYID_e = prf(SKEYID, SKEYID_a | kerberos_session_key | 2) 121 4. IV and Cookie Calculation 123 To encrypt the Phase 2 messages the IKE SA needs a "last phase 1 CBC 124 output block" to used to calculate the IV for the Phase 2 messages. 125 Because we do not have it we take the material used for the IV from the 126 kerberos AP message included in the phase 2. The IV then used for the 127 first encrypted block in the phase 2 message is derived from a hash of a 128 concatenation of the kerberos AP message and the phase 2 message id 129 using the fixed SHA-1 hash algorithm. 131 Cookies for the IKE SA are generated similarly from the AP message, i.e 132 it is taken as the 16 first bytes of the SHA-1 hash of the AP message. 133 Note, that this means that there will be two possible IKE SAs, one for 134 each direction. 136 5. Transmitting the AP Messages Inside the IKE Payload 138 The kerberos AP request and reply must be delivered from client to 139 server and back inside the IKE payloads, and they cannot be encrypted, 140 as the receiver of the packet does not yet know how to create the 141 encryption key because it has not yet seen the AP message. Because of 142 this we need to add a new payload to the beginning of each phase 2 143 payload and that must be transmitted without encryption. This means that 144 we need to define new payload type for that kerberos AP message and if 145 the next payload field in the generic header is that then the first 146 payload is in clear, and encryption starts only after that payload. The 147 whole packet is still authenticated as defined in [REVISED-HASH]. 149 The final payload will look like this: 151 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 ! Initiator ! 155 ! Cookie ! 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 ! Responder ! 158 ! Cookie ! 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 ! NP = XXX ! MjVer ! MnVer ! Exchange Type ! Flags ! 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 ! Message ID ! 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 ! Length ! 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 ! Next Payload ! RESERVED ! Payload Length ! 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 ! Kerberos AP message ! 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Encrypted phase 2 payload starts here | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 The Kerberos AP payload is only added to first phase 2 payload sent out 174 in one negotiation, i.e it is always in the first quick mode packet 175 going out, and it is always in all notifications and delete 176 notifications. 178 The initiator can authenticate the responder by verifying the hash 179 payload in the second quick mode packet. Only the responder can create 180 it because it knows the session key used to create authentication MAC. 182 Note, that when the other end responds to quick mode it will use the 183 same cookies that was inside the quick mode packet it received, but if 184 it rekeys, i.e initiates itself, then it uses cookies and IV created 185 from its own AP payload and adds the AP payload in the beginning of the 186 packet. 188 Also because this quick mode is normally used without PFS the responder 189 can immediately after receiving first packet instantiate inbound SA and 190 then send reply back to initiator. This means that when the initiator 191 receives the reply from responder it can also immediately start using 192 the SA without need to wait for the third message to reach the 193 responder. The third message only gives protection against replay 194 attacks and because ipsec keys are derived also from the nonces inside 195 the first and second packet any valid IPsec packet will also give proof 196 of liveliness. Thus responder can instantiate outbound SA immediately 197 when it receives the third quick mode message, or when it receives valid 198 authenticated IPsec packet for the inbound SA. This removes need for 199 commit bit and reduces number of round trips from 1.5 to 1 (the last 200 half round trip is already interleaved with the normal IPsec traffic). 201 This optimization should NOT be used if PFS is used, because in that 202 case instantiating the IPsec SA requires costly Diffie-Hellman 203 operation, which should be postponed to the point where replay attacks 204 are not possible. 206 6. Security Considerations 208 This document assumes that the session key generated by the kerberos is 209 safe and the whole security of the IKE SA is derived from that. The 210 IPsec SAs created using the Quick Mode negotiation over that IKE SA 211 derive entrypy also from the nonces passed in the negotiation, and also 212 from the Diffie-Hellman if PFS is used in the quick mode. 214 7. References 216 [REVISED-HASH] Kivinen T., "Fixing IKE Phase 1 Authentication HASH", 217 draft-ietf-ipsec-ike-hash-revised-01.txt (WORK IN PROGRESS) 219 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 220 November 1998 222 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 223 Requirement Levels", March 1997 225 8. Authors' Addresses 227 Tero Kivinen 228 SSH Communications Security Corp 229 Fredrikinkatu 42 230 FIN-00100 HELSINKI 231 Finland 232 E-mail: kivinen@ssh.fi