idnits 2.17.1 draft-ietf-ipsec-pki-req-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 509 lines 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 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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: 'RFC 2409' is mentioned on line 170, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) -- No information found for draft-ietf-pkix-cmc-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CMC' ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Obsolete normative reference: RFC 2314 (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) -- No information found for draft-ietf-pkix-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ROADMAP' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Rodney Thayer 2 draft-ietf-ipsec-pki-req-05.txt Charles Kunzinger, IBM 3 July 10, 2000 Paul Hoffman, VPNC 4 Expires in six months 6 A PKIX Profile for IKE 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as "work 22 in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The IKE protocol allows the use of the PKIX profile of X.509v3 33 certificates for encryption and authentication. Common practice in the 34 IPsec community differs in some ways from these specifications made in 35 the PKIX format specification and other specifications that have come 36 from the PKIX WG. In order to promote interoperability in the IPsec 37 market, this document lays out a profile for using PKIX in IKE. 39 1. Introduction 41 Implementors of IKE [RFC-2409] who use public key certificates have 42 almost universally used PKIX certificates and certificate processing, 43 as described in the PKIX certificate profile [RFC-2459], often called 44 "PKIX Part 1". However, many implementors have not adhered completely 45 to the PKIX certificate profile specification for a variety of reasons. 46 Note that many IPsec implementors are not completely happy with the 47 PKIX documents and procedures, but have agreed to use the PKIX 48 protocols because they are supported in other contexts and have a 49 significant market share. 51 This document is a profile for the PKIX certificate profile and other 52 PKI-related documents. IKE Implementors should follow all requirements 53 and suggestions in those documents except where this document 54 specifies differently. 56 This document is a profile of the PKIX certificate profile and the PKIX 57 roadmap [ROADMAP]. Material from those two documents is not repeated 58 here, and readers of this document are assumed to have read and fully 59 understood both documents. All security aspects of those documents are 60 fully relevant to this one. 62 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 63 "MAY" in this document are to be interpreted as described in 64 [RFC-2119]. 66 All PKI terms used in this document are defined either in the PKIX 67 certificate profile or the PKIX roadmap [ROADMAP]. For terms where the 68 two documents differ, the definition in the PKIX roadmap is used. In 69 particular, this document follows the PKIX roadmap's use of the term 70 "root CA", meaning "a CA that is directly trusted by an end entity; 71 that is, securely acquiring the value of a root CA public key requires 72 some out-of-band step(s)". 74 This document is being discussed on the ipsec@lists.tislabs.com mailing 75 list, which is the mailing list for the IPsec Working Group. 77 2. Certificate Validation and Revocation Checking 79 As described in the PKIX certificate profile, in certificate path 80 validation for a path whose length is longer than 2, the relying party 81 needs to check the validity of the certificates of subordinate CAs. An 82 IKE system that conforms to this profile MAY get the certificates of 83 subordinate CAs during the IKE exchanges, or MAY get those certificates 84 through other methods, such as through a local certificate cache or 85 from a directory. 87 IKE systems conforming to this profile MUST support a signing hierarchy 88 containing at least seven subordinate CAs between an end entity and a 89 root CA. This means that a certificate chain might have nine 90 certificates in it (the end-entity certificate, seven intermediate CAs, 91 and the trusted root certificate). 93 IKE systems conforming to this profile MUST check the revocation status 94 of any certificate on which they rely, as described in 95 the PKIX certificate profile. Thus, every conforming IKE system MUST 96 have a method for receiving up-to-date revocation information for the 97 certificates it is validating. 99 An IKE system that conforms to this profile that learns that a 100 certificate that was used in association with the creation of an 101 existing security association becomes invalid for any reason MUST 102 delete the corresponding IKE and IPsec security associations. A 103 conforming IKE system SHOULD periodically check for revocation 104 information such as CRLs and OCSP responses. 106 3. Certificate Format 108 This profile modifies the use of two fields specified in the 109 PKIX certificate profile. 111 3.1 The extendedKeyUsage field 113 In a certificate for an IPsec end entity, the extendedKeyUsage field 114 (commonly called "EKU") MAY be present. If it is present, the field 115 SHOULD contain the object identifier iKEIntermediate 116 (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or 117 1.3.6.1.5.5.8.2.2). 119 Note that this field is not given in the PKIX certificate profile. In 120 fact, the PKIX certificate profile lists three object identifiers for 121 IPsec devices: id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- 122 ipsecUser. These object identifiers never achieved any significant use 123 in the IPsec community; they SHOULD NOT be used. 125 3.2 The subjectAltName field 127 The subjectAltName field MAY be checked for identification of the 128 device. It is explicitly valid for an IKE system that conforms to this 129 profile to reject an end entity certificate whose identification fails 130 any of the following tests. 132 - If a name is the subjectAltName is an IP address, the IKE system MAY 133 confirm that the IP address is valid for the IKE negotiation process. 135 - If a name is a domain name, the IKE system MAY find the A record in 136 the DNS that matches that domain name and MAY confirm that the IP 137 address is valid for the IKE negotiation process. 139 [[[ Should there be some discussion here about comparing the identification 140 in the cert with the ID payload? If so, what should it say? ]]] 142 4. Extending the Validity Field to SAs 144 The notAfter field of the validity field specifies the date after which 145 the certificate is always considered invalid. An IKE implementation MUST 146 examine the notAfter date in conjunction with all relevant SA lifetimes 147 (both IKE SA and IPsec SA's) at the date the certificate is used to 148 authenticate creation of an SA. If the SA would definitely expire after 149 the end of the certificate lifetime, then either: 151 - the SA SHOULD NOT be created at all 153 - the SA SHOULD be created but the lifetime of the SA SHOULD match the 154 certificate lifetime 156 5. Algorithm Requirements 158 IKE systems that conform to this profile SHOULD support DSA-with-SHA1 159 signatures and RSA-with-SHA1 signatures on certificates (as expressed 160 by the signatureAlgorithm in the certificate). The OIDs associated with 161 these algorithms are id-dsa-with-sha1 and sha-1WithRSAEncryption, 162 respectively. 164 1024-bit keys MUST be supported for each signature algorithm supported, 165 and longer keys SHOULD be supported. 167 6. ISAKMP Certificate and Certificate Request Payloads 169 The steps in this section use sequential numbering of IKE messages as 170 shown in Sections 5.1-5.5 of [RFC 2409]. The first message sent by the 171 IKE initiator is numbered 1, the response sent by the IKE responder is 172 numbered 2, the next message from the Initiator is numbered 3, and so 173 on. 175 6.1 Signature-based authentication 177 End entity certificates contain identity information about the 178 certificate's owner. Thus, some systems will want to only transmit 179 their certificates in the protected messages of the IKE exchange. Other 180 systems will not find such protection needed, such as if the identity 181 is the IP address or domain name of the device owning the certificate. 183 Certificate requests may reveal information about the system making the 184 request. For instance, a certificate request that names a particular 185 root CA could help identify that the system requesting the certificate 186 is part of a particular security realm. However, most IKE systems have 187 not to date shown much care about revealing the names of the roots they 188 trust. 190 In order to protect the identity in a Certificate payload, the IKE 191 device that wishes to deliver its own certificates to its peer MUST use 192 Main Mode MUST only include Certificate payloads in message 5 or 6. 193 Devices not concerned with protecting the identity in a Certificate 194 payload MAY put that payload in any IKE message in either Main Mode or 195 Aggressive Mode. Devices receiving certificate payloads MUST store them 196 for use during further messages in the same IKE exchange, and MAY store 197 them for longer-term use, such as for future IKE exchanges. 199 In order to protect the information in a Certificate Request payload, 200 the IKE initiator that wishes to request a certificate MUST use Main 201 Mode and MUST send the Certificate Request payload in message 5. IKE 202 responders cannot protect Certificate Request payloads. Devices not 203 concerned with protecting the information in a Certificate Request 204 payload can include those payloads in messages 1 through 5 in Main 205 Mode, or in messages 1 and 2 in Aggressive Mode. 207 6.2 Encryption-based authentication 209 In Main Mode with encryption-based authentication, Certificate Request 210 payloads, if they are to be included anywhere, SHOULD appear only in 211 messages 1 and 2 because that is the only place where they are useful 212 for the exchange. Certificate Request payloads SHOULD NOT appear in 213 Aggressive Mode encryption-based authentication because they are never 214 useful. 216 In Main Mode with encryption-based authentication, Certificate payloads 217 SHOULD only appear in messages 1, 2, and 3 because that is the only 218 place where they are useful for the exchange; note that the 219 certificates in these messages are not encrypted and will thus reveal 220 identity information. In Aggressive Mode with encryption-based 221 authentication, Certificate payloads SHOULD only appear in message 1. 223 6.3 Certificate requests that yield no results 225 If a Certificate Request payload is received for a certificate or CRL 226 that the responder does not have, the responder SHOULD silently ignore 227 the request. The responder SHOULD NOT send a notify payload in response 228 to a Certificate Request that could not be fulfilled. 230 [[[Note: the previous version said "If a responding device is not 231 offering a certificate that will chain to the certificate authority 232 named in the Certificate Request payload, the Certificate payload 233 offered in response to a Certificate Request payload MUST specify a 234 certificate encoding of type NONE." However, there was general 235 agreement to delete this and replace it with the text above.]]] 237 6.4 Responding with multiple certificates 239 Some requests might cause the responder to send multiple certificates 240 as a response. Note that such responses may exceed the size of a single 241 UDP packet. However, if the requestor needs (or the responder believes 242 that the requestor needs) multiple certificates, such a response is 243 probably worthwhile. 245 Under this profile, a request for certificate type 1 (PKCS #7) 246 indicates that the requestor wants the responder to send a chain of 247 certificates, while a request for certificate type 4 or 5 (X.509 248 certificates) indicates that the requestor only wants an end entity 249 cert. 251 If a Certificate Request payload specifies a certificate type of 1 252 (PKCS #7), and the responder has a certificate that is not directly 253 signed by the root named in the certificate request but is singed by CA 254 in a chain that ends in the named root, the responder SHOULD send back 255 a single Certificate payload of type 1 that contains multiple 256 certificates: one for the end entity certificate, and one for each 257 intermediate certificate in the chain (not including the certificate 258 for the root). 260 If a Certificate Request payload specifies a certificate type of 4 or 261 5, and the responder has a certificate that is not directly signed by 262 the root named in the certificate request but is singed by CA in a 263 chain that ends in the named root, the responder SHOULD send back the 264 single end entity certificate and SHOULD NOT send back intermediate 265 certificate in the chain. 267 If a Certificate Request payload specifies a certificate type of 7 268 (CRL), and in the same message there is a Certificate Request payload 269 that specifies a certificate type of 1 (PKCS #7), the responder MAY 270 include the CRL in the PKCS #7 it returns. 272 6.5 Requests without certificate authority fields 274 The meaning of Certificate Request payloads that do not include 275 certificate authority fields is not well specified in [RFC-2408]. For 276 this profile, the following interpretations are given: 278 - For certificate type 2, 4, and 5, this means "return a single 279 certificate that might chain to a root that you somehow believe I 280 trust" 282 - For certificate type 1, this means "return one or more certificates 283 that might chain to a root that you somehow believe I trust in a 284 single payload" 286 - For certificate type 7, if the same message included a Certificate 287 Request payload of type 1, 2, 4, or 5, this means "please also return 288 any CRLs you have for the certificates you are returning for the 289 other request". 291 - For certificate type 7, if the same message did not include a 292 Certificate Request payload of type 1, 2, 4, or 5, this has no 293 meaning. Such requests SHOULD NOT be made. 295 6.6 Indicating validation failure 297 If certificate validation fails for any reason, the responder SHOULD 298 return an unprotected notify payload. The notify message SHOULD include 299 a notify message type of 17, 18, 19, 20, 21, 22, 23, 24, or 25, as 300 described in section 3.14.1 of [RFC-2408]. 302 6.7 Matching ID payloads with certificate subjects 304 An IKE implementation that conforms to this profile MUST NOT use an end 305 entity certificate received from an IKE peer for purposes of completing 306 the IKE authentication process unless there is a match in both content 307 and format between the ID payload (IDii or IDir) offered by the peer in 308 the IKE negotiation and at least one of the name forms carried in 309 either the subject or subjectAltName fields in the certificate 310 received. 312 7. Obtaining a Certificate for a Device 314 This specification explicitly does not mandate the use of any 315 particular certificate enrollment mechanism for IKE systems. 317 The process of a device presenting a CA with a public key and 318 identification, and then receiving a certificate from that CA for the 319 combination of the public key and identification, is often called 320 "enrollment" and "fulfillment". Unfortunately, the PKI world has had 321 little agreement on enrollment protocols. 323 The PKIX Working Group has standardized one mechanism, CMP [RFC-2510], 324 and has recently asked that a second, incompatible mechanism, CMC 325 [CMC], be standardized as well. In addition to CMP and CMC, there are 326 at least two other non-IETF protocols that have been used by a number 327 of IPsec vendors and CAs. 329 The IPsec market has coalesced around one method of enrollment that is 330 not fully defined anywhere other than this document. That method can be 331 called "PKCS10 plus out of band" or "P10POUB", described below. All 332 IKE systems that need to obtain a certificate for the public key MAY 333 do P10POUB, and MAY do CMP and/or CMC in the near future. 335 After receiving the PKCS #10 request, the CA creates a certificate and 336 makes it available to the requestor either as a PKCS #7 response or 337 as a bare certificate. 339 7.1 Enrollment requests with PKCS10 plus out of band information 341 The steps an end-entity uses in P10POUB are: 343 1. Obtain a key pair. 345 2. Create a PKCS #10 [RFC-2314] object that includes the public key 346 portion of the key pair. This object MUST NOT use any PKCS #10 347 extensions. 349 3. Determine the subjectAltName information desired for the 350 certificate. 352 4. Transmit the PKCS #10 object, the desired subjectAltName, and 353 any desired extensions to the CA. 355 The last step may be performed in many ways. One common method is a web 356 form where the Base64 [RFC-2045] transformation of the PKCS #10 object 357 is pasted into a text-entry field and the subjectAltName and the fact 358 that the desired certificate is for IPsec is specified with a variety 359 of form controls. A second common method is email message that is 360 manually processed by the CA. 362 Note that the CA may ask the person enrolling for the SHA-1 hash 363 of the PKCS10. This check helps prevent a man-in-the-middle from 364 replacing the person's PKCS #10 request with a fake one and 365 tricking the CA into issuing a certificate. 367 Devices enrolling with P10POUB over email MUST include the 368 subjectAltName in the message. The public key SHOULD be included in the 369 message as the Base64 transformation of the PKCS #10 object. That 370 Base64 object SHOULD be preceded with either the line: 372 -----BEGIN CERTIFICATE----- 374 or the line: 376 -----BEGIN CERTIFICATE REQUEST----- 378 and should be followed by the line: 380 -----END CERTIFICATE----- 382 or the line: 384 -----END CERTIFICATE REQUEST----- 386 This latter mechanism is somewhat similar to the certificate request 387 mechanism from PEM [RFC-1421]. 389 The CA's response to a successful creation of a certificate using 390 P10POUB MAY be any of the following: 392 - A PKCS #7 object holding the certificate 393 - The Base64 encoding of a PKCS #7 object holding the certificate 394 - The bare certificate 395 - The Base64 encoding of the bare certificate 397 [[[ OK, folks, that really doesn't help on interoperability. Should 398 we pick one of those four as a SHOULD? ]]] 400 8. Acknowledgements 402 This document was based on discussions with various IPsec implementers 403 and PKI service providers, as well as other members of the IETF 404 community. It also benefits from the spirit of interoperability 405 exhibited by participants in the various IPsec bakeoff events. 407 9. Security Considerations 409 All security considerations from the PKIX certificate profile and 410 the PKIX roadmap are relevant here. 412 Identifiers in certificates such as IP addresses or FQDN's should be 413 checked for consistency with other information about the security 414 associations being formed. 416 IKE Main Mode attempts to preserve identity protection by only sending 417 ID payloads in messages 5 and 6, which are encrypted. Sending 418 certificates in unencrypted IKE Main Mode messages (1 through 4) will 419 reveal the identity of the sender. Note that sending certificates in 420 Main Mode for encryption-based authentication by its very nature will 421 expose the identity of the sender. 423 10. References 425 [CMC] Myers, M., et. al., "Certificate Management Messages over CMS", 426 draft-ietf-pkix-cmc-xx.txt. (Awaiting the RFC Editor) 428 [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: 429 Part I: Message Encryption and Authentication Procedures", February 430 1993. 432 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", March 1997. 435 [RFC-2045] Freed, N. and Borenstein, N., "Multipurpose Internet Mail 436 Extensions (MIME) Part One: Format of Internet Message Bodies", 437 November 1996. 439 [RFC-2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 440 1.5", March 1998. 442 [RFC-2408] Maughan, D., et. al., "Internet Security Association and 443 Key Management Protocol (ISAKMP)", November, 1998. 445 [RFC-2409] Harkins, D. and Carrel, D., "The Internet Key Exchange 446 (IKE)", November 1998. 448 [RFC-2459] Housley, R., et. al., "Internet X.509 Public Key 449 Infrastructure Certificate and CRL Profile", January 1999. 451 [RFC-2510] Adams, C. and Farrell, S., "Internet X.509 Public Key 452 Infrastructure Certificate Management Protocols", March 1999. 454 [ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap", 455 draft-ietf-pkix-roadmap-xx.txt. 457 A. Change History 459 Some of the requirements from this draft come from other related drafts 460 in the IPsec WG. Many people have contributed to those drafts 461 and this one. 463 The differences between the -04 and -05 drafts were: 465 1. Added second paragraph to make it clear that implementors need 466 to follow other documents as well. 468 2. Rearranged a bit to put validation before revocation, 469 and changed the title of the section. 471 3.1 Changed this significantly because no one was requiring 472 its use for interoperability. Relaxed all requirements 473 (and even eliminated some). 475 3.2 Added open question at the end. 477 4. Changed "time" to "date" to match the PKIX usage. 479 5. Clarified what the signatures were for, added the SHA1 part, and 480 added OIDs. Removed "or equivalent" for the key sizes, and added note 481 about longer lengths. 483 6. Changed this whole section based on comments from the list. Split 484 the information out into separate sub-parts. 486 7. Moved Appendix A to section 7. 488 7. (A.) Added "Note that P10POUB using PKCS7 responses is one mode of 489 CMC." Described the reply from the CA being either a PKCS7 or a bare 490 cert based on the results from the San Diego bakeoff. Removed the last 491 paragraph about CAs MUST NOT issue certs with different subject or 492 altNames. 494 7.1 (A.1) Changed step 4. Added the response stuff and the open 495 question at the end of the section. 497 B. Authors' Addresses 499 Rodney Thayer 500 rodney@tillerman.to 502 Charles A. Kunzinger 503 IBM 504 kunzinge@us.ibm.com 506 Paul Hoffman 507 VPN Consortium 508 paul.hoffman@vpnc.org