idnits 2.17.1 draft-shima-ipsec-isakmp-cke-type-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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.) ** There are 4 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 178: '... MUST be set to payload type value o...' RFC 2119 keyword, line 199: '...ads. An initiator MAY provide multiple...' RFC 2119 keyword, line 200: '...tion; a responder MUST reply with only...' RFC 2119 keyword, line 276: '...ion provided by both parties SHOULD be...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'ISAKMP' on line 327 looks like a reference -- Missing reference section? 'IPSEC-CERT' on line 331 looks like a reference -- Missing reference section? 'DNSSEC-CERT' on line 338 looks like a reference -- Missing reference section? 'RFC2230' on line 342 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC Working Group 2 INTERNET-DRAFT 3 NEC Shigeyoshi Shima 4 Expires in six months from July,31 1998 6 ISAKMP Certificate Key Exchange Type Specification 7 9 Status of This Document 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of 6 months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za(Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document defines a new key exchange type of ISAKMP that reduce 30 the number of transmission and encrypt message contents from first 31 transmission. 32 The Certificate Key Exchange is effective since it does not use 33 Diffie-Hellman key exchange algorithm but public key cryptography. 34 The Certificate Key Exchange use certificates as authentication 35 information. Please send comments on this document to the 36 ipsec@tis.com. 38 Table of Contents 40 Status of This Document ...................................1 42 Abstract ..................................................1 43 Table of Contents .........................................2 45 1. Introduction ..........................................2 46 2. Definitions ...........................................3 47 2.1. Certificate ......................................3 48 2.2. Certification Authority ..........................3 49 3. Certificate Key Exchange ..............................4 50 3.1. Overview .........................................4 51 3.2. ISAKMP Exchange Type Field .......................4 52 3.3. Notation .........................................5 53 3.4. Certificate Key Exchange Type ....................5 54 4. Security Considerations ...............................7 56 Reference .............................................8 57 Acknowledgments .......................................8 58 Editor's Address ......................................8 60 1. Introduction 62 The IPSEC Working Group of the IETF has defined some key management 63 protocols (ISAKMP, IKE, SKIP etc), which are used for the 64 establishment of Security Association of AH (Authentication Header) 65 and ESP (Encapsulation Security Payload Header). This document 66 particularly describes about ISAKMP. 68 ISAKMP is based on Diffie-Hellman key exchange algorithms as a key 69 establishment method between hosts. Never the less, ISAKMP does not 70 guarantee correct correspondence between the host and the public key 71 used for Diffie-Hellman key exchange algorithms. If a host continues 72 to use an unguaranteed public key with Diffie-Hellman key exchange 73 algorithms, a cracker can wiretap message contents between hosts 74 after gaining unauthorized access to the host and obtain the public 75 key of the host. The public key cryptography has a similar problem. 76 This problem is generally settled through the third party with CA. 77 CA issue certificates to hosts. Certificates are guaranteed to 78 correspond the host and the public key with certificates if the host 79 verifies them. Only the host, which corresponds to the public key, 80 can access message contents if the message is encrypted with the 81 public key. 83 This document defines the Certificate Key Exchange type as a new 84 ISAKMP Key Exchange type [ISAKMP], which uses a public key 85 certificate. The Certificate Key Exchange does not use Diffie-Hellman 86 key exchange algorithms but public key cryptography, which has an 87 encryption and a signature mechanism. Therefore, the host can apply 88 to both key exchange and encryption of a message at the first 89 transmission, before the host shares secret information with a pair 90 of host. 92 2. Definitions 94 2.1. Certificate 96 For the contents of certificates that IPsec use, refer to 97 [IPSEC-CERT]. [IPSEC-CERT] defines processes for handling IPsec 98 certificates, including fulfillment, retrieval, validation, and 99 management, to realize the 100 IPsec certificate. 102 o IPsec-aware devices have requirements to retrieve and to share 103 certificates and CRLs. 105 o There are two means of certificate exchange for IPsec devices 107 1. Two IPsec devices exchange certificate information through 108 a combination of out-of-band operations and IKE payload 109 messages. 111 2. IPsec devices may use PKIX protocols or other mechanisms 112 such as LDAP or HTTP to retrieve PKI information. 114 o This certificate is used to identify an IPsec entity with the 115 IKE protocol and is based on the X.509 format {X.509], which 116 contains the public key, cryptography algorithm information, 117 and naming information. 119 2.2. Certification Authority (CA) 121 CAs generally have mechanisms for generation, verification, 122 revocation, management and distribution of certification as 123 described in section 2.1. 125 It is assumed that there exists multiple CAs on the Internet, with 126 each belonging to an organization and an area and some of them 127 forming a CA hierarchy. There are two types of CA; CA to issue 128 certificates to hosts and CA to issue certificates to other CAs. 129 Since a host obtains a CA certificate by off-line or through 130 installation of software before the host communicates on the 131 network, the host relies on the CA certificate. 133 3 Certificate Key Exchange 135 3.1 Overview 137 Key Exchange Types of ISAKMP can't encrypt a message from first 138 transmission. The AGGRESSIVE Exchange Type of ISAKMP can encrypt a 139 message from first transmission, if the host send a message in 140 advance to share secret information with a pair of host. 142 In the Certificate Key Exchange, the host can create an encrypted 143 message with the public key using public key cryptography. The 144 encrypted message can only be decrypted by a host which has the 145 secret key. Since correspondence of the host and the public key 146 of the responder is certified by a CA, the initiator verifies the 147 responder's certificate with the CA certificate, then the initiator 148 make an encrypted message with the public key of the responder in 149 the responder's certificate. 151 The Certificate Key Exchange can reduce the number of transmissions 152 in the key exchange, since a common key (secret) and identification 153 related information can be set to payloads from first transmission. 154 For example, in comparison with the BASE Key Exchange and the 155 IDENTITY PROTECTION Key Exchange the number of transmissions in the 156 Certificate Key Exchange is fewer, and in comparison with the 157 AGGRESSIVE Key Exchange, the number of transmissions is the same. 159 In the Certificate Key Exchange it is possible to detect masquerade 160 faster than with other types. In the case of the BASE Key Exchange, 161 masquerade is detected after finishing the key exchange with 162 Diffie-Hellman key exchange algorithms, while in the case of the 163 Certificate Key Exchange they are detected at start point of the key 164 exchange. 166 The details of the Certificate Key Exchange will be explained in 3.4. 168 3.2 ISAKMP Exchange Field 170 This section defines a new type of Exchange field for a ISAKMP 171 header; the Certificate Key Exchange, which is assigned the value 172 six(6). 174 In the Certificate Key Exchange, the Key Exchange payload is set to 175 ISAKMP packet of the first message before the all payloads and the 176 common key of the Key Exchange payload is used for encryption and 177 decryption of payloads. Therefore 4 as the Key Exchange payload(KE) 178 MUST be set to payload type value of the ISAKMP Header MUST be set 179 to 4 as the Key Exchange payload (KE). 181 ____Exchange_Type______Value___ 182 NONE 0 183 Base 1 184 Identity Protection 2 185 Authentication Only 3 186 Aggressive 4 187 Informational 5 188 Certificate 6 (New) 189 ISAKMP Future Use 7 - 31 190 DOI Specific Use 32 - 255 192 3.3 Notation 194 The following notation is used throughout this draft. 196 HDR is an ISAKMP header whose exchange type defines the payload 197 orderings 198 SA is an SA negotiation payload with one or more Proposal and 199 Transform payloads. An initiator MAY provide multiple 200 proposals for negotiation; a responder MUST reply with only 201 one. 202 KE is the key exchange payload. 203 IDx is the identity payload for "x". x can be: "ii" or "ir" 204 for the ISAKMP initiator and responder, respectively, or x 205 can be: "ui", "ur" (when the ISAKMP daemon is a proxy 206 negotiator), for the user initiator and responder, 207 respectively. 208 HASH is the hash payload. 209 SIG is the signature payload. The data to sign is exchange- 210 specific. 211 AUTH is a generic authentication mechanism, such as HASH or SIG. 212 NONCE is the nonce payload. 213 CERT is the certificate payload. 214 '( )*' signifies ISAKMP header and payloads in ( ) encryption 215 with Common Key Cryptography. 216 '**' signifies payload encryption with Public Key Cryptography. 217 This encryption is generally used for KE. 219 => signifies "initiator to responder" communication (requests). 220 <= signifies "responder to initiator" communication (replies). 222 3.4 Certificate Key Exchange 224 The Certificate Key Exchange is designed to allow the Security 225 Association, Key Exchange, Nonce, Identification, and Certificate 226 payloads to be transmitted together. The following diagram shows 227 messages with possible payloads sent in each message and notes 228 regarding an example of Certificate Exchange. 230 CERTIFICATE EXCHANGE 232 _#______Initiator____Direction_____Responder______________________NOTE____________________ 234 (1) HDR; KE**; (SA => Begin ISAKMP-SA or Proxy negotiation 235 NONCE; IDii; CERT)* and Key Exchange 236 (2) <= HDR; KE**; (SA 237 NONCE; IDir; AUTH)* 238 Initiator Identity Verified by Responder 239 Key Generated 240 SA agreed upon 241 (3) (HDR; AUTH)* 242 Responder Identity Verified by Initiator 243 SA established 245 In the first message (1), It assume that the initiator already 246 finished verifying the responder's certificate. The initiator 247 generates a Proposal payload considered adequate to protect traffic 248 in the preceding sessions. The Security Association, Proposal, and 249 Transform payloads are included in the Security Association payload 250 (for notation purposes). The initiator generates the common key to 251 encrypt other payloads, such as SA, NONCE, IDx, and CERT, sets the 252 Key Exchange payload to it, and encrypts the payload with the public 253 key in the responder's certificate. Random information which is used 254 to guarantee liveness and protect against replay attacks is also 255 transmitted. Additionally, the initiator transmits identification 256 information. The initiator can obtain the public key, public key 257 cryptography attribute, and common key cryptography attribute with 258 the responder's certificate. The initiator encrypts Security 259 Association, Proposal, Transform, Nonce, Identification, and 260 Certificate payloads with the generated common key. Since the ISAKMP 261 Header is not encrypted with the public key, hosts prevented from 262 wasting computation capacity by Denial of Service Attacks. The 263 responder confirms that the header and payloads are data of the 264 Certificate key Exchange and decrypts the Key Exchange payload with 265 the secret key of the responder since the ISAKMP Header contains Key 266 Exchange information. The responder decrypts other payloads with 267 the common key that is set to Key Exchange Payload. 269 In the second message (2), the responder indicates the protection 270 suite that was accepted with the Security Association, Proposal, and 271 Transform payloads. The initiator generates a common key to encrypt 272 other payloads, such as SA, NONCE, IDx, and CERT, sets the Key 273 Exchange payload to it, and encrypts the payload with the public key 274 in the responder's certificate. Random information which is used to 275 guarantee liveness and protect against replay attacks is also 276 transmitted. Random information provided by both parties SHOULD be 277 used by the authentication mechanism to provide shared proof of 278 participation in the exchange. Additionally, the responder transmits 279 identification information. This information is transmitted under the 280 protection of the agreed upon authentication function. 281 The initiator encrypts Security Association, Proposal, Transform, 282 Nonce, and Identification payloads as well as authentication 283 information with the generated common key. Local security policy 284 dictates the action of the responder if no proposed protection suite 285 is accepted. One possible action is the transmission of a Notify 286 payload as part of an Informational Exchange. The initiator confirms 287 that the header and payloads are the Certificate key Exchange data 288 and decrypts the Key Exchange payload with the secret key of the 289 initiator since the ISAKMP Header has the Key Exchange information. 290 The initiator decrypts other payloads with the common key that is 291 set to the Key Exchange payload. 293 In the third message (3), the initiator transmits the results of the 294 agreed upon authentication function. This information is transmitted 295 under the protection of the common shared secret. Local security 296 policy dictates the action if an error occurs during these messages. 297 One possible action is the transmission of a Notify payload as part 298 of an Informational Exchange. 300 4. Security Considerations 302 This entire draft is based on the ISAKMP draft on security and 303 discusses a new type of ISAKMP Key Exchange. If the Certificate Key 304 Exchange applies to the following Internet-Drafts, it improves 305 security and efficiency. 307 1. Storing Certificates in the Domain Name System [DNSSEC-CERT] 309 This document describes a mechanism whereby a CERT resource record 310 (RR) is defined so that certificate and certificate revocation lists 311 can be conveniently stored in the Domain Name System(DNS). 312 The secure DNS distributes IPsec CA certificates 313 to the host. The host can securely and efficiently obtain IPsec 314 certificates. 316 2. Key Exchange Delegation Record for the DNS [RFC2230] 318 This document describes a mechanism whereby authorization for one 319 node to act as key exchanger for a second node is delegated and made 320 available via the Secure DNS. This mechanism is intended to be used 321 only with the Secure DNS. It can be used with several security 322 services. If the host wants to find the trusted CA, secure DNS can 323 record access point of the correct CA on the network. 325 Reference 327 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, 328 "Internet Security Association and Key Management 329 Protocol", draft-ietf-ipsec-isakmp-09 331 [IPSEC-CERT] Rodney Thayer, "PKI Processing Requirements for IP 332 security", draft-thayer-ipsec-pki-00.txt 334 [X.509] ITU-T Recommendation X.509 (1197 E): 335 Information Technology - Open Systems Interconnection - 336 The Directory: Authentication Framework 338 [DNSSEC-CERT] Donald E. Easrlake 3rd olafur Gudmudsson, 339 "Storing Certificares in the Domain Name System", 340 draft-ietf-dnssec-cert-02.txt 342 [RFC2230] R. Atkinson, "Key Exchange Delegation Record 343 for the DNS", rfc2230.txt 345 Acknowledgments 347 This document is the result of close consultation with Mine Sakurai, 348 Takao Miyabe, and Shiuji Ishii. We would also like to thank the 349 members of NEC Internet Technology Laboratories. 351 Editor's Address 353 Shigeyoshi Shima 354 shima@ccs.mt.nec.co.jp 355 NEC Corporation 356 +81 (03) 5476-1107 358 The IPSec working group can be contacted via the IPSec working 359 group's mailing list (ipsec@tis.com) or through its chairs: 361 Robert Moskowitz 362 rgm@icsa.net 363 International Computer Security Association 365 Theodore Y. Ts'o 366 tytso@mit.edu 367 Massachusetts Institute of Technology