idnits 2.17.1 draft-ietf-ipsec-pki-req-01.txt: -(127): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(144): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(165): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(174): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(177): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(212): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(218): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(315): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(396): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(404): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(486): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 18 instances of lines with non-ascii characters in the document. == 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 17) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 277 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([CRMF], [PKIX-Part1], [Weinstein], [DNS-TEST], [PKCS-10], [RFC-1421], [DSA], [DOI], [BAL-EMS], [RFC-2314], [PKIX-1], [PKIX-part1], [IKE], [Arch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 102: '...X [PKIX-1, etc.] MUST be used in the f...' RFC 2119 keyword, line 237: '... PKI SHOULD provide for the u...' RFC 2119 keyword, line 239: '... SHOULD provide at least one ...' RFC 2119 keyword, line 245: '...at a root certificate. There MUST be a...' RFC 2119 keyword, line 248: '...rtificate and it MUST be used to confi...' (76 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...and its worki...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In either case the certificate generated by the PKI service provider MUST contain the subjectAltName specified and MAY NOT be changed. If for whatever reason (policy, CPS, technical reasons, etc.) the certificate request is not acceptable to the PKI service provider, it MUST NOT issue a certificate for this certificate request. In addition, the PKI service provider SHOULD use the same subjectName as was supplied in the request and SHOULD NOT change it. If the subjectName provided was not acceptable to the PKI service provider, or if a change-of-name PKI policy is not mutually acceptable, the certificate request SHOULD be rejected. In other words, the IPSec Usage Certificate that comes back should have a subjectName that is acceptable and expected. -- 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 (13 September 1998) is 9357 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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? 'Arch' on line 862 looks like a reference -- Missing reference section? 'PKIX-1' on line 903 looks like a reference -- Missing reference section? 'IKE' on line 866 looks like a reference -- Missing reference section? 'DSA' on line 864 looks like a reference -- Missing reference section? 'PKCS-10' on line 313 looks like a reference -- Missing reference section? 'CRMF' on line 328 looks like a reference -- Missing reference section? 'PKIX-part1' on line 423 looks like a reference -- Missing reference section? 'RFC-1421' on line 881 looks like a reference -- Missing reference section? 'RFC-2314' on line 887 looks like a reference -- Missing reference section? 'BAL-EMS' on line 870 looks like a reference -- Missing reference section? 'PKIX-Part1' on line 644 looks like a reference -- Missing reference section? 'DOI' on line 860 looks like a reference -- Missing reference section? 'DNS-TEST' on line 873 looks like a reference -- Missing reference section? 'Weinstein' on line 890 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Rodney Thayer 3 13 September 1998 EIS 4 Corporation 5 Expires: 18 March 1999 7 PKI Requirements for IP Security 8 draft-ietf-ipsec-pki-req-01.txt 9 Revision 01, 13 September 1998 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-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-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), 28 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 The IP Security (IPSec) protocol set now being defined in the 34 IETF uses public key cryptography for authentication in its key 35 management protocol. This document defines the requirements that 36 IPSec has for Public Key Infrastructure (PKI) protocols, formats, 37 and services. 39 IPSec PKI INTERNET-DRAFT 13 September 1998 41 Contents 42 Status of this Memo............................................1 43 Abstract.......................................................1 44 Contents.......................................................2 45 1. Introduction................................................3 46 1.1 Terminology..............................................3 47 2. Environment.................................................4 48 2.1 PKI Environment Requirements...............................5 49 2.2 Authentication Topology Requirements.......................5 50 3. Processes...................................................7 51 3.1 Fulfillment................................................7 52 3.1.1 Certificate Request Creation.............................7 53 3.1.2 Certificate Delivery.....................................8 54 3.2 Retrieval..................................................9 55 3.3 Validation.................................................9 56 3.4 Management................................................10 57 3.4.1 Certificate Issuance....................................10 58 3.4.2 Revocation of Certificate Validity......................11 59 3.4.3 IPSec validity checking.................................12 60 3.5 IKE Processing of Certificates............................12 61 4. Formats....................................................13 62 4.1 Certificate Format Component Details......................13 63 4.1.1 IPSec EKU Object Identifiers............................13 64 4.1.2 subjectAltName Name Format..............................13 65 4.1.3 Key Sizes...............................................14 66 4.1.4 Certificate Request and Certificate Formats.............14 67 4.1.5 Object Identifiers......................................14 68 4.2 Certificate Request.......................................14 69 4.3 IPSec Usage Certificate...................................15 70 4.4 Signing Certificates......................................15 71 4.4.1 Root Signing Certificate................................15 72 4.4.2 Intermediate Signing Certificate........................15 73 4.5 Certificate Revocation List...............................16 74 5. Samples....................................................17 75 5.1 Certificate Fulfilment Request............................17 76 5.2 IPSec Usage Certificate...................................17 77 5.3 Signing Certificate.......................................18 78 5.4 Certificate Revocation List...............................18 79 6. Acknowledgements...........................................18 80 7. Security Considerations....................................19 81 8. IANA Considerations........................................19 82 9. Colophon...................................................19 83 9.1 Authors' Address..........................................19 84 9.2 About this document.......................................19 85 9.3 Change History............................................20 86 10. References................................................20 87 Appendix......................................................22 88 A. Summary of Formats.........................................22 89 1. Names......................................................22 90 2. Object Identifiers for Signature Algorithms................22 91 3. Object Identifiers for Extended Key Usage..................22 92 IPSec PKI INTERNET-DRAFT 13 September 1998 94 B. Copyright Statement........................................23 96 1. Introduction 98 This document describes the Public Key Infrastructure facilities 99 required to support IPSec [Arch]. It is the intention of this 100 document to describe the mechanisms that are to be used today to 101 support certificate use in IPSec implementations, and to specify 102 how PKIX [PKIX-1, etc.] MUST be used in the future to support 103 IPSec. 105 The document discusses the (IPSec) environment in which 106 certificates will be used including the way certificates are 107 used, the processing involved, and the requirements for support 108 from a PKI. 110 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", 111 "RECOMMENDED", and "MAY" in this document are to be interpreted 112 as described in RFC 2119. 114 Please send comments on this document to the ipsec@tis.com 115 mailing list. 117 1.1 Terminology 119 CA - An organisation that issues certificates signed by some 120 hierarchy. 122 CA Engine - a machine or mechanism or software package used for 123 the process of signing certificates. This may be operated by an 124 organisation dedicated to this function (a "CA") or it may be 125 operated by a network management organisation within an Intranet. 127 commonName �- see [PKIX-1] for definition of this and other PKIX 128 data structure field names. 130 countryName --see [PKIX-1] for definition of this and other PKIX 131 data structure field names. 133 CRL - A Certificate Revocation List, in the PKIX sense of the 134 term. 136 Device Identification Certificate -- a certificate issued to an 137 IPSec-aware device such as a router, gateway, VPN device, or end 138 system. Note these devices are not necessarily associated with a 139 specific person and therefore naming schemes such as email 140 address are not appropriate. 142 IPSec PKI INTERNET-DRAFT 13 September 1998 144 EKU � "Extended Key Usage" fields in certificate requests and 145 certificates. 147 End system 149 IKE - IPSec Key Exchange protocol suite, a/k/a ISAKMP, Oakley, 150 and ISAKMP/Oakley resolution. 152 Intermediate system 154 Root Certificate �- A 'Root' Signing Certificate is also 155 sometimes referred to as a self-signed certificate. 157 Signing Certificate -- a certificate containing the public key 158 portion of a key pair, where the certificate was used to sign 159 another certificate. In an exactly two-layer hierarchy there is a 160 "root" signing certificate and there are subject certificates. 161 This term is used because if there are hierarchies (e.g. root1 -> 162 root2 -> root3 -> subject certificate) then calling anything but 163 the top certificate a root is a misnomer. 165 PKI service provider � the software that issues certificates by 166 signing the public key and other information delivered to it in a 167 certificate request. This might be operated by a public 168 ("retail") Certificate Authority or also might be a private 169 entity operating an appropriate computer system ("certificate 170 engine".) 172 Signing certificate 174 subjectAltName �- see [PKIX-1] for definition of this and other 175 PKIX data structure field names. 177 subjectName �- see [PKIX-1] for definition of this and other PKIX 178 data structure field names. 180 Usage certificate 182 2. Environment 184 IPSec runs in both an end-system and a gateway environment. These 185 systems may or may not be attended or associated with a person. 186 IPSec devices may well represent a site's only link to the 187 outside world. Since these devices are often initialised before 188 they are ever connected to the network, there is a requirement to 189 support systems that are isolated from real-time communications 190 with a PKI service provider. Devices which implement IPSec may 191 or may not be connected to the public Internet and cannot be 192 assumed to have local mass storage or removable media. 194 IPSec PKI INTERNET-DRAFT 13 September 1998 196 When IPSec uses a PKI it may be any combination of public and 197 private certifying authorities. This manifests itself as a 198 requirement to have available locally a copy of one or more root 199 certificate for signature verification. 201 The PKI environment used by IPSec may provide a variety of 202 authorisation topologies; these are discussed in section 2.2. 204 2.1 PKI Environment Requirements 206 The relationship between an IPSec device and the PKI it uses is 207 one of a client and a service provider. In this case the client 208 is the IPSec device, and the service provider is the PKI 209 provider. The IPSec device, by definition, is interacting with at 210 least one other IPSec device, and therefore there are a minimum 211 of two IPSec devices and a minimum of one PKI service provider. 212 At times, each IPSec device has it�s own PKI service provider and 213 therefore the abstract minimum configuration has four parties, 214 the two IPSec parties and the two PKI parties. Therefore there is 215 a minimum of three and possibly four certificates involved � the 216 two IPSec certificates and one or two PKI root certificates. 218 The IPSec device has it�s own certificate, based on it�s own 219 public and private key pair. The generation of the key pair (i.e. 220 was it generated inside or outside the IPSec device, is it backed 221 up, etc.) is outside of the scope of this document. In order to 222 establish this certificate, the PKI environment must support the 223 processes needed to support this. Sections 3.1 (PKI Fulfilment) 224 and 3.2 (PKI Retrieval) describe these processes. These processes 225 are used to get the IPSec the certificates it requires for 226 processing by the IKE [IKE] component. This means the IPSec 227 device requires this: 229 - A mechanism to request a certificate and it�s revocation 230 - It�s own certificate 231 - The root certificate that validates it�s peer IPSec 232 component 233 - Validity checking information (e.g. CRL) to confirm 234 validation of it�s peer�s certificate 236 In order to provide a cryptographically sound environment, the 237 PKI SHOULD provide for the use of at least two public key 238 algorithms. The PKI must provide DSA [DSA] public key support and 239 SHOULD provide at least one other mechanism. The size of the keys 240 involved is specific to the algorithm. 242 2.2 Authentication Topology Requirements 244 The PKI provides to the IPSec device a hierarchy of signing 245 certificates, terminated at a root certificate. There MUST be a 246 IPSec PKI INTERNET-DRAFT 13 September 1998 248 minimum of one signing certificate and it MUST be used to confirm 249 that a certificate received from an IPSec peer is valid. A given 250 IPSec device MUST have available to it some set of trustable 251 signing certificates, which are used to validate a certificate, 252 received from a peer IPSec device. This set of signing 253 certificates must be made available to the IPSec device in a 254 secure manner, e.g. manually loaded, because they are the basis 255 for the trust that is inherited by the incoming certificates. 257 IPSec devices MUST support a signing hierarchy containing at 258 least eight (8) signing certificates (i.e. an 8 layer root 259 topology.) 261 Each peer IPSec device MAY be associated with a different signing 262 hierarchy and therefore the IPSec device SHOULD support multiple 263 signing hierarchies. Also, each IPSec device MAY have multiple 264 identity certificates issued by different signing hierarchies. 266 It is outside the scope of this document to determine how an 267 IPSec device will determine which of its certificates to use or 268 which signing hierarchies to check to validate a peer's 269 certificate. 271 IPSec PKI INTERNET-DRAFT 13 September 1998 273 3. Processes 275 This section describes the processes that must be supported to 276 provide certificates and in general PKI support for IPSec 277 devices. Section 3.1 describes the processes to be supported to 278 request a certificate for an IPSec device, section 3.2 describes 279 the processes to be supported to retrieve certificates for use by 280 IPSec devices, section 3.3 describes the processes to be 281 supported to determine the validity of a given certificate, 282 section 3.4 describes the certificate management processes to be 283 supported. 285 3.1 Fulfillment 287 Note that some request formats may require manual processing by 288 the CA (i.e., PKCS#10 does not support all X509v3 extensions. Use 289 of those extensions may require the CA to manually enter 290 extension data into the certificate request. 292 Note that edge devices such as routers may use their network 293 management capabilities to facilitate this, e.g. the management 294 station may be the one to email the certificate fulfilment 295 request to the CA. 297 3.1.1 Certificate Request Creation 299 In order to initially establish a certificate for an IPSec device 300 there must be a certificate request generated by or on behalf of 301 the IPSec device and delivered to the some entity within the PKI 302 service provider. This involves these steps: 304 1. A public/private key pair is obtained 305 2. A certificate request data message is constructed 306 3. The certificate request is delivered to the PKI service 307 provider 309 The public private key pair is obtained through some mechanism 310 outside of this document. 312 The certificate request can be constructed in one of two formats. 313 These are PKCS #10 [PKCS-10] or PKIX (Part 3) [PKIX-3.] PKCS 314 #10, although not an IETF document, is a format that already has 315 effective �best current practice� status in the PKI community and 316 this format is available for implementers now and is known to 317 exist in current PKI service provider implementations. 319 IPSec PKI INTERNET-DRAFT 13 September 1998 321 The PKCS #10 certificate request format MUST be supported. When 322 this is used, the value to be placed in the subjectAltName and 323 the fact this certificate is to be used for IPSec must be 324 communicated to the PKI service provider in an out-of-band 325 manner. 327 The PKIX Part 3 Certificate Request format ('CertReqMsg' from 328 [CRMF]) SHOULD be used in the future to request a certificate for 329 IPSec usage. There MUST be an Extended Key Usage Extension 330 containing an iKEEnd or iKEIntermediate entry, and the 331 subjectAltName MUST be set to an appropriate value. See section 332 4.1.1 for a description of iKEEnd and iKEIntermediate. 334 In either case the certificate generated by the PKI service 335 provider MUST contain the subjectAltName specified and MAY NOT be 336 changed. If for whatever reason (policy, CPS, technical reasons, 337 etc.) the certificate request is not acceptable to the PKI 338 service provider, it MUST NOT issue a certificate for this 339 certificate request. In addition, the PKI service provider 340 SHOULD use the same subjectName as was supplied in the request 341 and SHOULD NOT change it. If the subjectName provided was not 342 acceptable to the PKI service provider, or if a change-of-name 343 PKI policy is not mutually acceptable, the certificate request 344 SHOULD be rejected. In other words, the IPSec Usage Certificate 345 that comes back should have a subjectName that is acceptable and 346 expected. 348 3.1.2 Certificate Delivery 350 In order to deliver this certificate request to the PKI service 351 provider, there are several possible mechanisms. At this time, 352 best current practice does not include any automated mechanisms. 353 Therefore we must specify what delivery schemes are expected to 354 be used for an IPSec device. 356 In the case of a PKCS #10 request, the request itself MUST be 357 encoded as either DER or PEM format. It MAY be made available to 358 the PKI service provider as one of: 360 - text file suitable for email delivery 361 - disk file suitable for removable media transmission (e.g. 362 overnight shipment with documented receipt) 363 - on-line delivery via ad hoc mechanism (e.g. web form, shared 364 disk directory, FTP, or email) 366 In the case of a PKIX request, the request itself is formatted 367 according to the rules of PKIX. A CertReqMsg is delivered through 368 one of the standard PKIX mechanisms, including offline and online 369 PKIX formats. 371 IPSec PKI INTERNET-DRAFT 13 September 1998 373 The offline (file based) PKCS #10 PEM formatted request mechanism 374 MUST be supported by the IPSec device and the PKI service 375 provider. It is outside the scope of this document to specify how 376 the IPSec device is to produce a file containing the request. 377 However it is assumed that IPSec devices will use their 378 associated network management facilities to produce such a file. 380 3.2 Retrieval 382 While a network is operating using IPSec the certificates 383 provided by the PKI are used for IKE identification purposes, and 384 thus are indirectly used for key exchange. The IPSec-aware 385 devices have a requirement to retrieve and to share device 386 identification certificates, signing certificates, and 387 certificate validity information. 389 IPSec devices MUST be able to retrieve their own fulfilled 390 certificates, signing certificates for other IPSec devices, and 391 identification certificates for other IPSec devices. An 392 identification certificate which identifies an IPSec device must 393 be loaded into that device in a secure manner. 395 A signing certificate which is used to validate other IPSec 396 devices� identification certificates must be loaded in a secure 397 manner. It should not be retrieved through an unsecured network 398 mechanism, for example, or accepted if received as an IKE 399 certificate payload. 401 Identification certificates received from IPSec devices through 402 IKE or through other means MUST be validated using signing 403 certificates and MAY be validated using other means to detect 404 revoked certificates, such as CRL�s or online directories. IPSec 405 devices MUST be able to accept identification certificates sent 406 through IKE and they also MUST be able to accept certificates 407 through some other mechanism, such as manual loading, or some 408 PKIX protocol. 410 These certificates which are received MAY be in PKCS #7 format, 411 DER or PEM encoded, unencrypted (see Section 4.3.1) or MAY be in 412 some standard PKIX format (see section 4.3.2). 414 3.3 Validation 416 Certificates as used for IPSec are validated using the signature 417 certificate of the issuer in the certification hierarchy and 418 through other means. 420 IPSec PKI INTERNET-DRAFT 13 September 1998 422 After checking to ensure the certificate is not malformed, the 423 signature should be checked. (See Section 6 of [PKIX-part1] for a 424 brief tutorial on certification path validation.) In order for a 425 Signature certificate to be used for verification, the 426 certificate(s) must be pre-loaded within the IPSec devices, or 427 retrieved in a secure manner. 429 After determining the signature is valid, the fields of the 430 certificate SHOULD be checked. If all these fields are not 431 checked, the IPSec implementation MUST document what checking is 432 done so that the level of security provided by the implementation 433 can be determined. 435 Certificate contents to be checked are: 437 1. Signature through chain as described above 438 2. Date. This SHOULD be year-2000 compliant by using 439 GeneralTime to provide four digit years. 440 3. ExtendedKeyUsage SHOULD be checked to ensure the certificate 441 is valid for the system in question, including the 442 criticality fields. This extension MUST be treated as 443 critical. 444 4. subjectAltName validation checking (see below) 446 The subjectAltName field MAY be checked for consistency. For 447 ipAddress, the address MAY be checked to confirm it is valid for 448 the IKE negotiation in progress. For dNSName the name MAY be 449 retrieved from the DNS to validate it is valid for the IP address 450 which was the source of the certificate, if known, and for the 451 IKE negotiation in progress. For rFC822Name, the email address 452 MAY be checked according to the style of SMTP to ensure email 453 name validity. 455 3.4 Management 457 The term "manangement" as used here means the processes used for 458 the creation, validity determination, and destruction of 459 certificates. 461 3.4.1 Certificate Issuance 463 Certificates SHOULD be issued only for certificate requests that 464 contain a valid Extended Key Usage extension in the certificate 465 request. The certificate that is issued SHOULD contain the same 466 Extended Key Usage object identifier as the request contained. 467 If the certificate request contains a subjectAltName extension 468 then the certificate MUST contain the same subjectAltName 469 extension. If the PKI service provider cannot meet these 470 requirements then it MUST NOT issue the certificate. 472 IPSec PKI INTERNET-DRAFT 13 September 1998 474 Certificate requests may be delivered to the PKI service provider 475 through either PKCS #10, CMC, or PKIX mechanisms and the 476 resultant certificate may be delivered through any of the 477 corresponding mechanisms. In all cases the certificate request 478 and resultant certificate SHOULD be delivered through an 479 appropriately secure mechanism. 481 3.4.2 Revocation of Certificate Validity 483 At any time the PKI service provider can revoke the validity 484 status of a certificate it has issued. The process of requesting 485 this revocation is outside of the scope of this document. Once 486 the certificate�s status has changed from valid to invalid, IPSec 487 devices that use these certificates MUST NOT use these 488 certificates if they are aware they are no longer valid. The 489 process of determining whether a given certificate is valid is 490 outside the scope of this document. An IPSec device SHOULD use 491 some mechanism to determine if a certificate has had it�s 492 validity revoked before it is used. The IPSec device may use 493 Certificate Revocation Lists, on-line directories, or other 494 mechanisms. These mechanism MUST be used in a secure manner, 495 i.e. some scheme MUST be used to secure the revocation 496 information such as signing certificate signatures on a CRL. 498 IPSec PKI INTERNET-DRAFT 13 September 1998 500 3.4.3 IPSec validity checking 502 IKE implementations must check the certificate for validity at 503 the time it is used, e.g. at Main Mode initiation time. The 504 certificate MUST be checked for field validity and for semantic 505 validity. The fields that MUST be checked are: 507 1. NotBefore and notAfter times must be valid 508 2. "subjectAltName" MAY contain a relevant and valid name 509 3. "subjectName" SHOULD be non-empty 510 4. if extendedKeyUsage is present it must contain either 511 iKEIntermediate or iKEEnd. If additional EKU object 512 identifiers are present then their use is a locally defined 513 matter. 514 5. keyUsage MAY be checked for locally defined valid 515 combinations 516 6. the signature of the certificate must be checked against 517 signing certificate hierarchy 519 IKE implementations MUST examine the not-after time in 520 conjunction with all relevant SA lifetimes (both IKE SA and IPSec 521 SA's) at the time the certificate is used to authenticate 522 creation of an SA. If the SA would definitely expire after the 523 end of the certificate lifetime then the SA MUST NOT be created. 524 If an IPSec device learns that a certificate used in association 525 with the creation of an IKE or an IPSec security association 526 becomes invalid for any reason the corresponding security 527 association MUST be deleted. 529 3.5 IKE Processing of Certificates 531 [something about cert requests] 533 [something about 'signature' vs. digital encipherment"] 534 IPSec PKI INTERNET-DRAFT 13 September 1998 536 4. Formats 538 This section describes the fields required in the various 539 certificate-related messages, as they are used for IPSec. 541 4.1 Certificate Format Component Details 543 4.1.1 IPSec EKU Object Identifiers 545 The OID "iKEEnd" 546 (iso.org.dod.internet.security.ipsec.certificate.2, or 547 1.3.6.1.5.5.8.2.2) declares this certificate will be used for an 548 end-node with IPSec and IKE. An "end node" is defined to be an 549 IPSec device that does not offer IPSec services on behalf of 550 other devices such as a server or desktop system. 552 The OID "iKEIntermediate" 553 (iso.org.dod.internet.security.ipsec.certificate.2, or 554 1.3.6.1.5.5.8.2.2) declares this certificate will be used for an 555 intermediate note with IPSec and IKE. An "intermediate node" is 556 defined to be an IPSec device that offers IPSec services on 557 behalf of other devices e.g. using tunnel mode and IP forwarding. 559 4.1.2 subjectAltName Name Format 561 For IPSec devices the actual name of the subject is stored in the 562 subjectAltName field. This field SHOULD contain exactly one of 563 these values: 565 - ipAddress 566 - dNSName 567 - rFC822Name 569 If the field contains an IP Address, this MUST be one single IPv4 570 address, expressed as four bytes in network order. Other uses of 571 this field such as Ipv6 or subnetwork address are not allowed. 572 Note the address must be checked for validity and not for 573 connectivity, that is, it is not necessary that there be a path 574 from the IPSec device to this address but rather it is necessary 575 that this IPSec device make an explicit decision that this is a 576 valid address. 578 If the field contains a DNS name it SHOULD be a valid DNS name 579 that corresponds to a valid IP address as seen by the IPSec 580 device processing the certificate. The name SHOULD resolve to a 581 single IPv4 address and the name MUST NOT end in a trailing dot. 583 IPSec PKI INTERNET-DRAFT 13 September 1998 585 If the field contains an RFC 822 name it must be a valid email 586 address which the IPSec device may assume is accessible. 588 4.1.3 Key Sizes 590 1024 bit keys or equivalent must be supported. 592 4.1.4 Certificate Request and Certificate Formats 594 Certificate requests and certificates MAY be exchanged in either 595 raw binary ("DER") format or in encapsulated Base-64 format in 596 the style of PEM [RFC-1421]. Encapsulated Base-64 format means: 598 - first line SHOULD contain "-----BEGIN CERTIFICATE-----" 599 or "-----BEGIN CERTIFICATE REQUEST-----" 600 - Certificate or certificate request, encoded as per [RFC- 601 1421] (64 characters per line) 602 - Last line SHOULD contain "-----END CERTIFICATE-----" or 603 "-----END CERTIFICATE REQUEST-----" 605 The use of the begin and end delimiters is in the style of PEM 606 but uses the pre- and post-encapsulating boundaries first 607 developed by Netscape and now in common use [Weinstein.] 609 4.1.5 Object Identifiers 611 The object identifier used to identify RSA encryption with SHA-1 612 Hashing SHOULD be 1.3.14.3.2.29, i.e. the ISO variant. 614 4.2 Certificate Request 616 A Certificate request is used to provide a public key and 617 associated naming information for an IPSec device to a PKI 618 service provider. The request itself MUST be a 619 'CertificationRequest' structure as defined in [RFC-2314]. This 620 MAY be encapsulated in a PKIX Enrolment Message [BAL-EMS] or 621 presented as a classic PKCS#10 Certificate Request. 623 The request SHOULD contain subjectAltName information, although 624 that may be provided out of band. If subjectAltName is provided 625 it is stored in the 'attributes' field of the 626 CertificationRequest structure. The attributes are defined using 627 the "Extensions" format defined in [PKIX-1.] Alternatively and 628 for backwards compatability, the TIPEM/BCERT style of 'T-61 629 string' encoding MAY be used although this format should be 630 avoided if possible. [more clear wording awaiting response from 631 RSA...] 632 IPSec PKI INTERNET-DRAFT 13 September 1998 634 The request MUST contain some information in the subjectName 635 field. The exact contents of this field are not standardized. 636 By convention, a minimal subjectName contains countryName and 637 commonName. 639 4.3 IPSec Usage Certificate 641 A certificate that contains the public key component of a key 642 pair used to identify an IPSec device is called an "IPSec Usage 643 Certificate". This certificate is in the format described in 644 [PKIX-Part1] as a 'Certificate' containing a 'TBSCertificate'. 645 The 'extensions' field of the TBSCertificate SHOULD be present. 646 One of the EKU attributes SHOULD be present as an extension. One 647 subjectAltName attribute SHOULD be present. There SHOULD NOT be 648 more than one subjectAltName attribute present. A key pair that 649 corresponds to a Signing Certificate MUST sign an IPSec Usage 650 Certificate and the Signing Certificate MUST be available for 651 other IPSec devices to validate this signature. 653 4.4 Signing Certificates 655 This is a certificate that contains the public key component of 656 the key pair used to sign IPSec Usage Certificates. The only 657 relevant fields are the subjectName and the public key. IKE 658 implementations MUST use the subjectName of Signing Certificates 659 to match the issuerName of any certificate that is being checked. 661 Signing certificates MAY have the CA bit set in their key usage 662 field and SHOULD have EKU attributes identifying them as capable 663 of signing IPSec certificates. The same two OID's are used for 664 signing certificates as for IPSec usage certificates. 666 Signing Certificates use the same format from [PKIX-1] as Usage 667 Certificates. 669 4.4.1 Root Signing Certificate 671 A 'Root' Signing Certificate is one in which the subjectName and 672 issuerName fields contain the same distinguished name. 674 4.4.2 Intermediate Signing Certificate 676 This is a certificate used to sign other certificates. At this 677 time the only relevant fields are the subjectName and the public 678 key. IKE implementations MUST use the subjectName of the signing 679 certificate to match the issuerName of any certificate that is 680 being checked. 682 IPSec PKI INTERNET-DRAFT 13 September 1998 684 4.5 Certificate Revocation List 686 A CRL for IPSec looks just like a CRL as defined in PKIX. 688 IPSec PKI INTERNET-DRAFT 13 September 1998 690 5. Samples 692 This section contains sample PKI objects for interoperability 693 testing. These are formatted in PEM or hex dumps of DER encoding. 695 5.1 Certificate Fulfilment Request 697 This is a request from commonName "10.0.0.1" with a 1024 bit key. 699 -----BEGIN CERTIFICATE REQUEST----- 700 MIIBmDCCAQECAQAwWDERMA8GA1UEAxMIMTAuMC4wLjExITAfBgNVBAoTGFZQTmV0 701 IFRlY2hub2xvZ2llcywgSW5jLjETMBEGA1UECBMKQ2FsaWZvcm5pYTELMAkGA1UE 702 BhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALYF9xDiUoZ/vIeDnhKF 703 7pX0cLSv4m3dLDiS9dhqi0zS1SWUPbN3vaeDUkcK+w0mPh4FJXTzum4cy1I0qIv3 704 j9a6cPjubWj3XLyGVaJrpTRpnhXdxvR+njGeZpMDTGKgE+5uWbnxs97FfQI+MPTE 705 AUC3HoW7I+0bqNihhb1HLIN3AgMBAAGgADANBgkqhkiG9w0BAQQFAAOBgQAagHsf 706 Nsc4u8RhEOo+FN5zfYOCdpXRZulNbU7Fn1qubHrWPDA0eUk6YP86MBzeNQa8wKqz 707 0wVCU448wd78NuszYoHeE/C2uAy/taefbShPDZ68dumK3L1j9BEaNv/+6yt31mV7 708 BTfAnw5xMLbD5V/RBQ2tWsrPxUdAXEWCJfj/cw== 709 -----END CERTIFICATE REQUEST----- 711 5.2 IPSec Usage Certificate 713 This is a certificate for commonName "10.0.8.1" signed by the 714 signing key in section 5.3. (to fit the lines in this document 715 '\' was inserted where lines were split.) 717 -----BEGIN CERTIFICATE----- 718 MIICQTCCAesCBQCYAvAMMA0GCSqGSIb3DQEBBAUAMIG2MQswCQYDVQQGEwJVUz\ 719 ELMAkGA1UE 720 CBMCTUExDzANBgNVBAcTBk5ld3RvbjElMCMGA1UEChMcU2FibGUgVGVjaG5vbG\ 721 9neSBDb3Jw 722 b3JhdGlvbjEsMCoGA1UECxMjU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgRGlyZW\ 723 N0b3JhdGUx 724 DzANBgNVBAMTBmRldi1jYTEjMCEGCSqGSIb3DQEJARYUcm9kbmV5QHNhYmxldG\ 725 VjaC5jb20w 726 HhcNOTgwMjAzMDUwMDAwWhcNOTkwMjAzMDQ1OTU5WjBYMREwDwYDVQQDEwgxMC\ 727 4wLjguMTEh 728 MB8GA1UEChMYVlBOZXQgVGVjaG5vbG9naWVzLCBJbmMuMRMwEQYDVQQIEwpDYW\ 729 xpZm9ybmlh 730 MQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsBktyH\ 731 noHqADQ4IP 732 E3exE/kbPGDXCw+36CSruHOIpMvf0o1YBezL2G+MrhEwDbk0n0Kaqpf9jOc4+i2u9 733 Qlt\ 734 4nck 735 sgoRdv7TiPp3EkJa3siwSjx+ikyo7oLUa6mWdLn0Wrnm9rVUf0yyQiYc3H6ul7\ 736 Pn9c7oNZ7G 737 IPSec PKI INTERNET-DRAFT 13 September 1998 739 KSZ1G4ILitkCAwEAATANBgkqhkiG9w0BAQQFAANBANveH7jw9U8yJPCcAmG7Lq\ 740 h7f03ALEF/ 741 SNfp5fHGo1UeeZiMFP7fNBS2oAlqNRDMCWJJnp+EXahaOjqDqTuqS9o= 742 -----END CERTIFICATE----- 744 5.3 Signing Certificate 746 -----BEGIN CERTIFICATE----- 747 MIICXDCCAgYCBQCYAvABMA0GCSqGSIb3DQEBBAUAMIG2MQswCQYDVQQGEwJVUz\ 748 ELMAkGA1UE 749 CBMCTUExDzANBgNVBAcTBk5ld3RvbjElMCMGA1UEChMcU2FibGUgVGVjaG5vbG\ 750 9neSBDb3Jw 751 b3JhdGlvbjEsMCoGA1UECxMjU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgRGlyZW\ 752 N0b3JhdGUx 753 DzANBgNVBAMTBmRldi1jYTEjMCEGCSqGSIb3DQEJARYUcm9kbmV5QHNhYmxldG\ 754 VjaC5jb20w 755 HhcNOTgwMjAxMDUwMDAwWhcNOTgwNjAyMDQ1OTU5WjCBtjELMAkGA1UEBhMCVV\ 756 MxCzAJBgNV 757 BAgTAk1BMQ8wDQYDVQQHEwZOZXd0b24xJTAjBgNVBAoTHFNhYmxlIFRlY2hub2\ 758 xvZ3kgQ29y 759 cG9yYXRpb24xLDAqBgNVBAsTI1NlY3VyaXR5IEluZnJhc3RydWN0dXJlIERpcm\ 760 VjdG9yYXRl 761 MQ8wDQYDVQQDEwZkZXYtY2ExIzAhBgkqhkiG9w0BCQEWFHJvZG5leUBzYWJsZX\ 762 RlY2guY29t 763 MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAOv2J79yGQG6nb+KCFzNseNpWeFMD7\ 764 d1NTeFtEqK 765 iYhiHbm3y/qoX5bMJDXp3c5EMhRF4akpl+51oAPzYoE4tZ0CAwEAATANBgkqhk\ 766 iG9w0BAQQF 767 AANBAG3g34T44uP3lK1H1ngyXPN79hu50wF9eiknaSzZ6RNEBeM2flgjQYseC/\ 768 WHlku01UFh 769 bg0WAvl/WWeesm4dHtc= 770 -----END CERTIFICATE----- 772 5.4 Certificate Revocation List 774 6. Acknowledgements 776 This document was based on discussions with various IPSec 777 implementers and PKI service providers, as well as other members 778 of the IETF community. It also benefits from the spirit of 779 interoperability exhibited by participants in the various IPSec 780 bakeoff events. 782 IPSec PKI INTERNET-DRAFT 13 September 1998 784 7. Security Considerations 786 Check the current literature for recent changes in the known 787 safety of the algorithms mentioned here, including MD5, SHA-1, 788 RSA, and DSA. 790 You have to store the private key(s) safely. If you use keys of 791 varying lengths, such as a 512-bit RSA root with 1024-bit usage 792 certificate, there may be implications as to the security of your 793 infrastructure. 795 Root or other Signing Certificates should be obtained in a secure 796 manner, probably NOT sent over the IKE exchange or from a 797 directory, in order to make sure you are not checking against a 798 spoofed root. The distinguished name in a signing certificate 799 cannot be assumed to be unique or correct. 801 Names in certificates, such as IP addresses or FQDN's should be 802 checked for consistency with other information about the security 803 associations being formed. 805 If you cross-sign signing certificates you run the risk of 806 leaking trust across hierarchies in unintended ways. 808 8. IANA Considerations 810 Two new object identifiers are added in this draft, which will be 811 submitted to IANA for inclusion in the SMI OID area, see 812 www.iana.org for more information. 814 9. Colophon 816 9.1 Authors' Address 818 Rodney Thayer 819 EIS Corporation 820 1520 Gulf Blvd #1507 821 Clearwater FL 33767 822 rodney@unitran.com 823 +1 727 560 1947 824 http://wg.unitran.com/ietf-ipsec 826 9.2 About this document 828 Document edited with Word '98, printed to 'generic text only 829 printer' on Windows NT, post-processed to fix Carriage 830 Return/Line Feed issues with custom code. Spell checker 831 configured for UK English. 833 IPSec PKI INTERNET-DRAFT 13 September 1998 835 9.3 Change History 837 This is revision 01 of draft-ietf-ipsec-pki-req-.txt. This 838 version was spell-checked and certain other typographical errors 839 were corrected. The reference to key lengths all being the same 840 was removed. The last two paragraphs of the abstract were moved 841 to the introduction. The dates in the headers, footers, and 842 first and last page were updated. The text was changed so the 843 validation requirements on subjectAltName fields are listed as 844 "SHOULD" and "MAY" and not "MUST" operations. Chapter 3 was 845 changed significantly to reflect the existance of RFC2314 (IETF 846 version of PKCS#10) and to clarify some points about the 847 processes. The Security Considerations section has been updated 848 to reflect these various changes. Added and updated terms 849 section. Changed two-algorithm requirement to a SHOULD and made 850 it more clear. 852 This document was originally distributed in April 1998 under a 853 different name. There was a second version, distributed at the 854 September 1998 IPSec Bakeoff in Redmond at Microsoft. 856 10. References 858 [PKCS #7] RSA PKCS specs 860 [DOI] 862 [Arch] IP Security Architecture draft 864 [DSA] dsa defn as specified in pkix, ietf doc or other? 866 [IKE] 868 Xxx 870 [BAL-EMS] LaMacchia, B. "Enrollment Message Syntax", unpublished 871 proposal discussed at IPSec Bake-off in Redmond, September 1998. 873 [DNS-TEST] Eastlake, D., "Reserved Top Level DNS Names", draft- 874 ietf-dnsind-test-tlds-11.txt, July 1998. 876 [PKIX-1] Housley, R. (SPYRUS), Ford, W. (VeriSign), Polk, W. 877 (NIST), Solo, D. (Citicorp), "Internet X.509 Public Key 878 Infrastructure, Certificate and CRL Profile", draft-ietf-pkix- 879 ipki-part1-09.txt, July 28, 1998. 881 [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic 882 Mail: Part I: Message Encryption and Authentication Procedures", 883 RFC-1421, February 1993. 885 IPSec PKI INTERNET-DRAFT 13 September 1998 887 [RFC-2314] Kaliski, B., "PKCS #10: Certification Request Syntax 888 Version 1.5" 890 [Weinstein] Weinstein, J., Private communication regarding "----- 891 BEGIN CERTIFICATE-----", September 1998. 893 IPSec PKI INTERNET-DRAFT 13 September 1998 895 Appendix 897 A. Summary of Formats 899 1. Names 901 Distinguished Names SHOULD be no more than four (4) 902 attribute/value pairs each of which SHOULD be no more than 128 903 characters in length, or the length specified in [PKIX-1], 904 whatever is shorter. 906 2. Object Identifiers for Signature Algorithms 908 SHA-1 with RSA Signature should use the ISO OID, 1.3.14.3.2.29. 910 3. Object Identifiers for Extended Key Usage 912 The OID "iKEEnd" 913 (iso.org.dod.internet.security.ipsec.certificate.2, or 914 1.3.6.1.5.5.8.2.2) identifies an IPSec Usage Certificate for an 915 end system. 917 The OID "iKEIntermediate" 918 (iso.org.dod.internet.security.ipsec.certificate.2, or 919 1.3.6.1.5.5.8.2.2) identifies an IPSec Usage Certificate for an 920 intermediate system. 922 IPSec PKI INTERNET-DRAFT 13 September 1998 924 B. Copyright Statement 926 Copyright (C) The Internet Society (date). All Rights Reserved. 928 This document and translations of it may be copied and furnished 929 to others, and derivative works that comment on or otherwise 930 explain it or assist in its implementation may be prepared, 931 copied, published and distributed, in whole or in part, without 932 restriction of any kind, provided that the above copyright notice 933 and this paragraph are included on all such copies and derivative 934 works. However, this document itself may not be modified in any 935 way, such as by removing the copyright notice or references to 936 the Internet Society or other Internet organizations, except as 937 needed for the purpose of developing Internet standards in which 938 case the procedures for copyrights defined in the Internet 939 Standards process shall be followed, or as required to translate 940 it into languages other than English. 942 The limited permissions granted above are perpetual and will not 943 be revoked by the Internet Society or its successors or assigns. 944 This document and the information contained herein is provided on 945 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 946 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 947 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 948 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 949 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 950 PURPOSE. 952 This draft expires 18 March 1999.