INTERNET-DRAFT Rodney Thayer 26 May 1999 SSH Expires: 31 November 1999 Charles A. Kunzinger IBM PKI Requirements for IP Security draft-ietf-ipsec-pki-req-02.txt Revision 02, 26 May 1999 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The IP Security (IPsec) protocol set now being defined in the IETF uses public key cryptography for authentication in its key management protocol. This document defines the requirements that IPsec has for Public Key Infrastructure (PKI) protocols, formats, and services based on IETF PKIX (a/k/a X.509) certificate schemes. Thayer,Kunzinger Expires November 1999 [Page 1] IPsec PKI INTERNET-DRAFT May 1999 Contents Status of this Memo............................................1 Abstract.......................................................1 Contents.......................................................2 1. Introduction................................................4 1.1 Terminology................................................4 2. Environment.................................................6 2.1 PKI Environment Requirements...............................6 2.2 Authentication Topology Requirements.......................7 2.3 Certificate Usage Requirements.............................7 3. Processes...................................................8 3.1 Fulfillment................................................8 3.1.1 Certificate Request Creation.............................8 3.1.2 Certificate Delivery.....................................9 3.2 Retrieval.................................................10 3.3 Validation................................................11 3.4 Management................................................12 3.4.1 Certificate Issuance....................................12 3.4.2 Revocation of Certificate Validity......................12 3.4.3 IPsec validity checking.................................12 3.5 IKE Processing of Certificates............................13 4. Formats....................................................14 4.1 Certificate Format Component Details......................14 4.1.1 IPsec EKU Object Identifiers............................14 4.1.2 subjectAltName Name Format..............................14 4.1.3 Key Sizes...............................................15 4.1.4 Certificate Request and Certificate Formats.............15 4.1.5 Object Identifiers......................................15 4.2 Certificate Request.......................................15 4.3 IPsec Usage Certificate...................................16 4.4 Signing Certificates......................................16 4.4.1 Root Signing Certificate................................16 4.4.2 Intermediate Signing Certificate........................17 4.5 Certificate Revocation List...............................17 5. Samples....................................................18 5.1 Certificate Fulfilment Request............................18 5.2 IPsec Usage Certificate...................................18 5.3 Signing Certificate.......................................19 5.4 Certificate Revocation List...............................19 6. Acknowledgements...........................................19 7. Security Considerations....................................20 8. IANA Considerations........................................20 9.1 Authors' Addresses........................................21 9.2 About this document.......................................21 9.3 Change History............................................21 10. References................................................22 Appendix......................................................24 Thayer,Kunzinger Expires November 1999 [Page 2] IPsec PKI INTERNET-DRAFT May 1999 A. Summary of Formats.........................................24 1. Names......................................................24 2. Object Identifiers for Signature Algorithms................24 3. Object Identifiers for Extended Key Usage..................24 B. PKIX Issues................................................25 C. IKE Issues.................................................27 D. Copyright Statement........................................28 Thayer,Kunzinger Expires November 1999 [Page 3] IPsec PKI INTERNET-DRAFT May 1999 1. Introduction This document describes the Public Key Infrastructure facilities required to support IPsec [RFC-2401]. It is the intention of this document to describe the mechanisms that are to be used today to support certificate use in IPsec implementations, and to specify how PKIX [PKIX-1, etc.] SHOULD be used in the future to support IPsec. The document discusses the (IPsec) environment in which certificates will be used including the way certificates are used, the processing involved, and the requirements for support from a PKI. The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ipsec@tis.com mailing list. 1.1 Terminology CA -- An organization that issues certificates signed by some hierarchy. CA Engine -- a machine or mechanism or software package used for the process of signing certificates. This may be operated by an organisation dedicated to this function (a "CA") or it may be operated by a network management organisation within an Intranet. commonName -- see [PKIX-1] for definition of this and other PKIX data structure field names. countryName -- see [PKIX-1] for definition of this and other PKIX data structure field names. CRL -- A Certificate Revocation List, in the PKIX sense of the term. EKU -- "Extended Key Usage" fields in certificate requests and certificates. End system -- a system that processes IPsec packets for use within itself only. Thayer,Kunzinger Expires November 1999 [Page 4] IPsec PKI INTERNET-DRAFT May 1999 IKE -- IPsec Key Exchange protocol suite, a/k/a ISAKMP, Oakley, and ISAKMP/Oakley resolution. See [RFC-2409] Intermediate system -- a system that processes IPsec packets for use within it and for forwarding, with or without IPsec processing, to other systems. Root Certificate -- A signing certificate that is self-signed. A certificate representing a key pair used to sign Usage Certificates, that is not in turn signed by other signing certificates. PKI service provider -- the software that issues certificates by signing the public key and other information delivered to it in a certificate request. A public ("retail") Certificate Authority might operate this or also might be a private entity operating an appropriate computer system ("certificate engine") within a local Intranet. PKIX -- IETF Working Group handling PKI issues. Note this work references PKIX and NEVER references X.509, this is NOT based on X.509. X.509 is NEVER the definitive reference, the PKIX draft set is. Signing Certificate -- a certificate containing the public key portion of a key pair, where the certificate was used to sign another certificate. In an exactly two-layer hierarchy there is a ("root") signing certificate and there are usage certificates. This term is used because if there are hierarchies (e.g. root1 -> root2 -> root3 -> usage certificate) then calling anything but the top certificate a root is a misnomer. subject -- see [PKIX-1] for definition of this and other PKIX data structure field names. subjectAltName -- see [PKIX-1] for definition of this and other PKIX data structure field names. Usage certificate -- a certificate issued to an IPsec-aware device such as a router, gateway, VPN device, or end system. Note these devices are not necessarily associated with a specific person and therefore naming schemes such as email address are not appropriate. Validate -- to check a usage certificate in order to determine if it is valid. This checking consists of recalculating digital signatures from relevant signing certificates, checking Thayer,Kunzinger Expires November 1999 [Page 5] IPsec PKI INTERNET-DRAFT May 1999 certificate revocation and/or current status, and other field checking as MAY be performed. 2. Environment IPsec runs in both an End System and an Intermediate System (Gateway) environment. These systems may or may not be attended or associated with a person. IPsec devices may well represent a site's only link to the outside world. Since these devices are often initialised before they are ever connected to the network, there is a requirement to support systems that are isolated from real-time communications with a PKI service provider. Devices that implement IPsec may or may not be connected to the public Internet and cannot be assumed to have local mass storage or removable media. When IPsec uses a PKI it may be any combination of public and private PKI Service Providers. This manifests itself as a requirement to have available locally a copy of one or more Signing Certificates for signature verification. The PKI environment used by IPsec may provide a variety of authorisation topologies; these are discussed in section 2.2. 2.1 PKI Environment Requirements The relationship between an IPsec device and the PKI it uses is one of a client and a service provider. In this case the client is the IPsec device, and the service provider is the PKI Service Provider. The IPsec device, by definition, is interacting with at least one other IPsec device, and therefore there are a minimum of two IPsec devices and a minimum of one PKI service provider. At times, each IPsec device has it's own PKI service provider and therefore the abstract minimum configuration has four parties, the two IPsec parties and the two PKI parties. Therefore there is a minimum of three and possibly four certificates involved _ the two IPsec usage certificates and one or two signing certificates. The IPsec device has it's own usage certificate, based on it's own public and private key pair. The generation of the key pair (i.e. was it generated inside or outside the IPsec device, is it backed up, etc.) is outside of the scope of this document. In order to establish this certificate, the PKI environment must support the processes needed to support this. Sections 3.1 (PKI Fulfilment) and 3.2 (PKI Retrieval) describe these processes. These processes are used to get the IPsec the certificates it Thayer,Kunzinger Expires November 1999 [Page 6] IPsec PKI INTERNET-DRAFT May 1999 requires for processing by the IKE [RFC-2409] component. This means the IPsec device requires this: - A mechanism to request the issuance of a certificate and it's revocation - It's own certificate - The signing certificate(s) that validate it's peer IPsec component - Validity checking information (e.g. CRL) to confirm validation of it's peer's certificate In order to provide a cryptographically sound environment, the PKI SHOULD provide for the use of at least two public key algorithms. The PKI must provide DSA [DSA] public key support and SHOULD provide at least one other mechanism. The size of the keys involved is specific to the algorithm. 2.2 Authentication Topology Requirements The PKI Service Providers provide to the IPsec devices a hierarchy of signing certificates, terminated at a root certificate. There MUST be a minimum of one signing certificate. The signing certificate(s) MUST be used to confirm that a usage certificate designated for an IPsec peer is valid. A given IPsec device MUST have available to it some set of trusted signing certificates, which are used to validate usage certificates, received from a peer IPsec device. This set of signing certificates must be made available to the IPsec device in a secure manner, e.g. manually loaded, because they are the basis for the trust that is inherited by IPsec peers' usage certificates. IPsec devices MUST support a signing hierarchy containing at least eight (8) signing certificates (i.e. an 8-layer root topology.) Each peer IPsec device MAY be associated with a different signing hierarchy and therefore the IPsec device SHOULD support multiple signing hierarchies. Also, each IPsec device MAY have multiple usage certificates issued by different signing hierarchies. It is outside the scope of this document to determine how an IPsec device will determine which of its own usage certificates to use or which signing hierarchies to check to validate a peer's usage certificate. 2.3 Certificate Usage Requirements Thayer,Kunzinger Expires November 1999 [Page 7] IPsec PKI INTERNET-DRAFT May 1999 Determination of whether a given usage certificate will be for an end system or an intermediate system, or both, or something else, is outside the scope of this document. It is the responsibility of the parties that produce the certificate request and the resultant certificate to ensure that the key usage fields properly represent the actual usage. 3. Processes This section describes the processes that must be supported to provide certificates and in general PKI support for IPsec devices. Section 3.1 describes the processes to be supported to request a certificate for an IPsec device, section 3.2 describes the processes to be supported to retrieve certificates for use by IPsec devices, section 3.3 describes the processes to be supported to determine the validity of a given certificate, section 3.4 describes the certificate management processes to be supported. 3.1 Fulfillment Note that some request formats may require external processing by the CA (i.e., PKCS#10 does not support all PKIX/X509v3 extensions.) Use of those extensions may require the CA to externally enter extension data into the certificate request. Note that edge devices such as routers may use their network management capabilities to facilitate this, e.g. the management station may be the one to email the certificate fulfilment request to the CA. 3.1.1 Certificate Request Creation In order to initially establish a certificate for an IPsec device there must be a certificate request generated by or on behalf of the IPsec device and delivered to the some entity within the PKI service provider. This involves these steps: 1. A public/private key pair is obtained 2. A certificate request data message is constructed 3. The certificate request is delivered to the PKI service provider The public private key pair is obtained through some mechanism outside of this document. Thayer,Kunzinger Expires November 1999 [Page 8] IPsec PKI INTERNET-DRAFT May 1999 The certificate request can be constructed in one of two formats. These are PKCS #10 [PKCS-10] or PKIX (Part 3) [PKIX-3.] PKCS #10, although not an IETF document, is a format that already has effective 'best current practice' status in the PKI community and this format is available for implementers now and is known to exist in current PKI service provider implementations. The PKCS #10 certificate request format MUST be supported. When this is used, the value to be placed in the subjectAltName and the fact this certificate is to be used for IPsec must be communicated to the PKI service provider in an out-of-band manner. The PKIX Part 3 Certificate Request format ('CertReqMsg' from [CRMF]) SHOULD be used in the future to request a certificate for IPsec usage. There MUST be an Extended Key Usage Extension containing an iKEEnd or iKEIntermediate entry, and the subjectAltName MUST be set to an appropriate value. See section 4.1.1 for a description of iKEEnd and iKEIntermediate. 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 subject as was supplied in the request and SHOULD NOT change it. If the subject 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 subject that is acceptable and expected. 3.1.2 Certificate Delivery In order to deliver this certificate request to the PKI service provider, there are several possible mechanisms. At this time, best current practice does not include any automated mechanisms. Therefore we must specify what delivery schemes are expected to be used for an IPsec device. In the case of a PKCS #10 request, the request itself MUST be encoded as either DER or PEM format. It MAY be made available to the PKI service provider as one of: - text file suitable for email delivery - disk file suitable for removable media transmission (e.g. overnight shipment with documented receipt) Thayer,Kunzinger Expires November 1999 [Page 9] IPsec PKI INTERNET-DRAFT May 1999 - on-line delivery via ad hoc mechanism (e.g. web form, shared disk directory, FTP, or email) In the case of a PKIX request, the request itself is formatted according to the rules of PKIX. A CertReqMsg is delivered through one of the standard PKIX mechanisms, including offline and online PKIX formats. The offline (file based) PKCS #10 PEM formatted request mechanism MUST be supported by the IPsec device and the PKI service provider. It is outside the scope of this document to specify how the IPsec device is to produce a file containing the request. However it is assumed that IPsec devices will use their associated network management facilities to produce such a file. 3.2 Retrieval While a network is operating using IPsec the certificates provided by the PKI are used for IKE identification purposes, and thus are indirectly used for key exchange. The IPsec-aware devices have a requirement to retrieve and to share device identification certificates, signing certificates, and certificate validity information. IPsec devices MUST be able to retrieve their own fulfilled certificates, signing certificates for other IPsec devices, and identification certificates for other IPsec devices. An identification certificate which identifies an IPsec device must be loaded into that device in a secure manner. A signing certificate which is used to validate other IPsec devices' identification certificates must be loaded in a secure manner. It should not be retrieved through an unsecured network mechanism, for example, or accepted if received as an IKE certificate payload. If a chain of certificates, i.e. a usage certificate and associated signing certificates, must be delivered over IKE certificate payloads, then the signing certificate at the other end of the chain SHOULD NOT be delivered over IKE, it should be loaded through some other (secure) manner. It is necessary for at least one of the signing certificates in a chain to be securely loaded, or else the entire chain can't be trusted. Implementations MUST NOT allow loading of all signing certificates for a usage certificate to be received in an insecure manner (i.e. from the peer IPsec entity, for example.) Thayer,Kunzinger Expires November 1999 [Page 10] IPsec PKI INTERNET-DRAFT May 1999 Identification certificates received from IPsec devices through IKE or through other means MUST be validated using signing certificates and MAY be validated using other means to detect revoked certificates, such as CRL's or online directories. IPsec devices MUST be able to accept usage certificates sent through IKE and they also MUST be able to accept certificates through other mechanisms, such as manual loading, or some PKIX protocol. These certificates which are received MAY be in PKCS #7 format, DER or PEM encoded, unencrypted (see Section 4.3.1) or MAY be in some standard PKIX format (see section 4.3.2). 3.3 Validation Certificates as used for IPsec are validated using the signing certificate(s) of the issuer in the certification hierarchy and through other means. After checking to ensure the certificate is not malformed, the signature should be checked. (See Section 6 of [PKIX-part1] for a brief tutorial on certification path validation.) In order for signing certificate(s) to be used for verification, the certificate(s) must be pre-loaded within the IPsec devices, or retrieved in a secure manner. After determining the signature is valid, the fields of the certificate SHOULD be checked. If all these fields are not checked, the IPsec implementation MUST document what checking is done so that the level of security provided by the implementation can be determined. Certificate contents to be checked are: 1. Signature through chain as described above 2. Date. This SHOULD be year-2000 compliant by using GeneralTime to provide four digit years. 3. ExtendedKeyUsage SHOULD be checked to ensure the certificate is valid for the system in question, including the criticality fields. This extension MUST be treated as critical. 4. subjectAltName validation checking (see below) The subjectAltName field MAY be checked for consistency. For ipAddress, the address MAY be checked to confirm it is valid for the IKE negotiation in progress. For dNSName the name MAY be retrieved from the DNS to validate it is valid for the IP address which was the source of the certificate, if known, and for the IKE negotiation in progress. For rFC822Name, the email address Thayer,Kunzinger Expires November 1999 [Page 11] IPsec PKI INTERNET-DRAFT May 1999 MAY be checked according to the style of SMTP to ensure email name validity. 3.4 Management The term "management" as used here means the processes used for the creation, validity determination, and destruction of certificates. 3.4.1 Certificate Issuance Certificates SHOULD be issued only for certificate requests that contain a valid Extended Key Usage extension in the certificate request. The certificate that is issued SHOULD contain the same Extended Key Usage object identifier as the request contained. If the certificate request contains a subjectAltName extension then the certificate MUST contain the same subjectAltName extension. If the PKI service provider cannot meet these requirements then it MUST NOT issue the certificate. Certificate requests may be delivered to the PKI service provider through either PKCS #7/10, CMC, or PKIX mechanisms and the resultant certificate may be delivered through any of the corresponding mechanisms. In all cases the certificate request and resultant certificate SHOULD be delivered through an appropriately secure mechanism. 3.4.2 Revocation of Certificate Validity At any time the PKI service provider can revoke a usage or signing certificate it has issued. The process of requesting this revocation is outside of the scope of this document. Once the certificate's status has changed from valid to invalid, IPsec devices that use these certificates MUST NOT use these certificates if they are aware they are no longer valid. The process of determining whether a given certificate is valid is outside the scope of this document. An IPsec device SHOULD use some mechanism to determine if a certificate has had been revoked before it is used. The IPsec device may use Certificate Revocation Lists, on-line directory schemes, or other mechanisms. These mechanism MUST be used in a secure manner, i.e. some scheme MUST be used to secure the revocation information such as signing certificate signatures on a CRL. 3.4.3 IPsec validity checking Thayer,Kunzinger Expires November 1999 [Page 12] IPsec PKI INTERNET-DRAFT May 1999 IKE implementations must check the certificate for validity at the time it is used, e.g. at Main Mode initiation time. The certificate MUST be checked for field validity and for semantic validity. The fields that MUST be checked are: 1. NotBefore and notAfter times must be valid 2. "subjectAltName" MAY contain a relevant and valid value 3. "subject" SHOULD be non-empty 4. if extendedKeyUsage is present it must contain either iKEIntermediate or iKEEnd. If additional EKU object identifiers are present then their use is a locally defined matter. 5. keyUsage MAY be checked for locally defined valid combinations 6. the signature of the certificate must be checked against signing certificate hierarchy IKE implementations MUST examine the not-after time in conjunction with all relevant SA lifetimes (both IKE SA and IPsec SA's) at the time the certificate is used to authenticate creation of an SA. If the SA would definitely expire after the end of the certificate lifetime then the one of two choices SHOULD be selected: (1) the SA SHOULD NOT be created at all, or (2) create an SA but reduce the lifetime to match the certificate lifetime. If an IPsec device learns that a certificate used in association with the creation of an IKE or an IPsec security association becomes invalid for any reason the corresponding security association MUST be deleted. In addition, if a Certificate Revocation List or other PKIX- defined mechanism is available to check the validity of the certificate, it MUST be used. 3.5 IKE Processing of Certificates [something about cert requests] [something about 'signature' vs. digital encipherment"] Thayer,Kunzinger Expires November 1999 [Page 13] IPsec PKI INTERNET-DRAFT May 1999 4. Formats This section describes the fields required in the various certificate-related messages, as they are used for IPsec. 4.1 Certificate Format Component Details 4.1.1 IPsec EKU Object Identifiers Two object identifiers are defined for declaring that a certificate is used for IPsec. The OID "iKEIntermediate" SHOULD be used if the distinction between end system and intermediate system is not necessary. The OID "iKEEnd" (iso.org.dod.internet.security.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.1) declares this certificate will be used for an end-node with IPsec and IKE. An "end node" is defined to be an IPsec device that does not offer IPsec services on behalf of other devices such as a server or desktop system. The OID "iKEIntermediate" (iso.org.dod.internet.security.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.2) declares this certificate will be used for an intermediate node with IPsec and IKE. An "intermediate node" is defined to be an IPsec device that offers IPsec services on behalf of other devices e.g. using tunnel mode and IP forwarding. 4.1.2 subjectAltName Name Format For IPsec devices the actual name of the subject is stored in the subjectAltName field. This field SHOULD contain at most one of each of these values: - ipAddress - dNSName - rFC822Name If the field contains an IP Address, this MUST be one single IPv4 address, expressed as four bytes in network order. Other uses of this field such as Ipv6 or subnetwork address are not allowed. Note the address SHOULD be checked for validity and not for connectivity, that is, it is not necessary that there be a path from the IPsec device to this address but rather that this IPsec device make an explicit decision that this is a valid address. Thayer,Kunzinger Expires November 1999 [Page 14] IPsec PKI INTERNET-DRAFT May 1999 If the field contains a DNS name it SHOULD be a valid DNS name that corresponds to a valid IP address as seen by the IPsec device processing the certificate. The name SHOULD resolve to a single IPv4 address and the name MUST NOT end in a trailing dot. If the field contains an RFC 822 name it SHOULD be a valid email address which the IPsec device may assume is accessible. 4.1.3 Key Sizes 1024 bit keys or equivalent MUST be supported. 4.1.4 Certificate Request and Certificate Formats Certificate requests and certificates MAY be exchanged in either raw binary ("DER") format or in encapsulated Base-64 format in the style of PEM [RFC-1421]. Encapsulated Base-64 format means: - first line SHOULD contain "-----BEGIN CERTIFICATE-----" or "-----BEGIN CERTIFICATE REQUEST-----" - Certificate or certificate request, encoded as per [RFC-1421] (64 characters per line) - Last line SHOULD contain "-----END CERTIFICATE-----" or "-----END CERTIFICATE REQUEST-----" The use of the begin and end delimiters is in the style of PEM but uses the pre- and post-encapsulating boundaries first developed by Netscape and now in common use [Weinstein.] 4.1.5 Object Identifiers The object identifier used to identify RSA encryption with SHA-1 Hashing SHOULD be sha1WithRSAEncryption from [PKIX-1], i.e. the (broken PKIX) RSA variant. 4.2 Certificate Request A Certificate request is used to provide a public key and associated naming information for an IPsec device to a PKI service provider. The request itself MUST be a 'CertificationRequest' structure as defined in [RFC-2314]. This MAY be encapsulated in a PKIX Enrolment Message [BAL-EMS] or presented as a classic PKCS#10 Certificate Request. The request SHOULD contain subjectAltName information, although that may be provided out of band. If subjectAltName is provided it is stored in the 'attributes' field of the Thayer,Kunzinger Expires November 1999 [Page 15] IPsec PKI INTERNET-DRAFT May 1999 CertificationRequest structure. The attributes are defined using the "Extensions" format defined in [PKIX-1.] Alternatively and for backward compatibility, the TIPEM/BCERT style of 'T-61 string' encoding MAY be used although this format should be avoided if possible. [more clear wording awaiting response from RSA...] The request MUST contain some information in the subject field. The exact contents of this field are not standardized. By convention, a minimal subject contains countryName and commonName. 4.3 IPsec Usage Certificate A certificate that contains the public key component of a key pair used to identify an IPsec device is called an "IPsec Usage Certificate". This certificate is in the format described in [PKIX-Part1] as a 'Certificate' containing a 'TBSCertificate'. The 'extensions' field of the TBSCertificate SHOULD be present. One of the EKU attributes MAY be present as an extension. One subjectAltName attribute MAY be present. There SHOULD NOT be more than one subjectAltName attribute present. A key pair that corresponds to a Signing Certificate MUST sign an IPsec Usage Certificate or another Signing Certificate and the Signing Certificate MUST be available for other IPsec devices to validate this signature. 4.4 Signing Certificates This is a certificate that contains the public key component of the key pair used to sign IPsec Usage Certificates. The only relevant fields are the subject and the public key. IKE implementations MUST use the subject of Signing Certificates to match the issuerName of any certificate that is being checked. Signing certificates MAY have EKU attributes identifying them for use in signing IPsec certificates. The same two OID's are used for signing certificates as for IPsec usage certificates. Signing Certificates use the same format from [PKIX-1] as Usage Certificates. 4.4.1 Root Signing Certificate A 'Root' Signing Certificate is one in which the subject and issuerName fields contain the same distinguished name. Thayer,Kunzinger Expires November 1999 [Page 16] IPsec PKI INTERNET-DRAFT May 1999 4.4.2 Intermediate Signing Certificate This is a certificate used to sign other certificates. At this time the only relevant fields are the subject and the public key. IKE implementations MUST use the subject of the signing certificate to match the issuerName of any certificate that is being checked. 4.5 Certificate Revocation List A CRL for IPsec looks just like a CRL as defined in PKIX. Thayer,Kunzinger Expires November 1999 [Page 17] IPsec PKI INTERNET-DRAFT May 1999 5. Samples This section contains sample PKI objects for interoperability testing. These are formatted in PEM or hex dumps of DER encoding. 5.1 Certificate Fulfilment Request This is a request from commonName "10.0.0.1" with a 1024 bit key. -----BEGIN CERTIFICATE REQUEST----- MIIBmDCCAQECAQAwWDERMA8GA1UEAxMIMTAuMC4wLjExITAfBgNVBAoTGFZQTmV0 IFRlY2hub2xvZ2llcywgSW5jLjETMBEGA1UECBMKQ2FsaWZvcm5pYTELMAkGA1UE BhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALYF9xDiUoZ/vIeDnhKF 7pX0cLSv4m3dLDiS9dhqi0zS1SWUPbN3vaeDUkcK+w0mPh4FJXTzum4cy1I0qIv3 j9a6cPjubWj3XLyGVaJrpTRpnhXdxvR+njGeZpMDTGKgE+5uWbnxs97FfQI+MPTE AUC3HoW7I+0bqNihhb1HLIN3AgMBAAGgADANBgkqhkiG9w0BAQQFAAOBgQAagHsf Nsc4u8RhEOo+FN5zfYOCdpXRZulNbU7Fn1qubHrWPDA0eUk6YP86MBzeNQa8wKqz 0wVCU448wd78NuszYoHeE/C2uAy/taefbShPDZ68dumK3L1j9BEaNv/+6yt31mV7 BTfAnw5xMLbD5V/RBQ2tWsrPxUdAXEWCJfj/cw== -----END CERTIFICATE REQUEST----- 5.2 IPsec Usage Certificate This is a certificate for commonName "10.0.8.1" signed by the signing key in section 5.3. (to fit the lines in this document '\' was inserted where lines were split.) -----BEGIN CERTIFICATE----- MIICQTCCAesCBQCYAvAMMA0GCSqGSIb3DQEBBAUAMIG2MQswCQYDVQQGEwJVUz\ ELMAkGA1UE CBMCTUExDzANBgNVBAcTBk5ld3RvbjElMCMGA1UEChMcU2FibGUgVGVjaG5vbG\ 9neSBDb3Jw b3JhdGlvbjEsMCoGA1UECxMjU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgRGlyZW\ N0b3JhdGUx DzANBgNVBAMTBmRldi1jYTEjMCEGCSqGSIb3DQEJARYUcm9kbmV5QHNhYmxldG\ VjaC5jb20w HhcNOTgwMjAzMDUwMDAwWhcNOTkwMjAzMDQ1OTU5WjBYMREwDwYDVQQDEwgxMC\ 4wLjguMTEh MB8GA1UEChMYVlBOZXQgVGVjaG5vbG9naWVzLCBJbmMuMRMwEQYDVQQIEwpDYW\ xpZm9ybmlh MQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsBktyH\ noHqADQ4IP E3exE/kbPGDXCw+36CSruHOIpMvf0o1YBezL2G+MrhEwDbk0n0Kaqpf9jOc4+i2u9 Qlt\ 4nck sgoRdv7TiPp3EkJa3siwSjx+ikyo7oLUa6mWdLn0Wrnm9rVUf0yyQiYc3H6ul7\ Thayer,Kunzinger Expires November 1999 [Page 18] IPsec PKI INTERNET-DRAFT May 1999 Pn9c7oNZ7G KSZ1G4ILitkCAwEAATANBgkqhkiG9w0BAQQFAANBANveH7jw9U8yJPCcAmG7Lq\ h7f03ALEF/ SNfp5fHGo1UeeZiMFP7fNBS2oAlqNRDMCWJJnp+EXahaOjqDqTuqS9o= -----END CERTIFICATE----- 5.3 Signing Certificate -----BEGIN CERTIFICATE----- MIICXDCCAgYCBQCYAvABMA0GCSqGSIb3DQEBBAUAMIG2MQswCQYDVQQGEwJVUz\ ELMAkGA1UE CBMCTUExDzANBgNVBAcTBk5ld3RvbjElMCMGA1UEChMcU2FibGUgVGVjaG5vbG\ 9neSBDb3Jw b3JhdGlvbjEsMCoGA1UECxMjU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgRGlyZW\ N0b3JhdGUx DzANBgNVBAMTBmRldi1jYTEjMCEGCSqGSIb3DQEJARYUcm9kbmV5QHNhYmxldG\ VjaC5jb20w HhcNOTgwMjAxMDUwMDAwWhcNOTgwNjAyMDQ1OTU5WjCBtjELMAkGA1UEBhMCVV\ MxCzAJBgNV BAgTAk1BMQ8wDQYDVQQHEwZOZXd0b24xJTAjBgNVBAoTHFNhYmxlIFRlY2hub2\ xvZ3kgQ29y cG9yYXRpb24xLDAqBgNVBAsTI1NlY3VyaXR5IEluZnJhc3RydWN0dXJlIERpcm\ VjdG9yYXRl MQ8wDQYDVQQDEwZkZXYtY2ExIzAhBgkqhkiG9w0BCQEWFHJvZG5leUBzYWJsZX\ RlY2guY29t MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAOv2J79yGQG6nb+KCFzNseNpWeFMD7\ d1NTeFtEqK iYhiHbm3y/qoX5bMJDXp3c5EMhRF4akpl+51oAPzYoE4tZ0CAwEAATANBgkqhk\ iG9w0BAQQF AANBAG3g34T44uP3lK1H1ngyXPN79hu50wF9eiknaSzZ6RNEBeM2flgjQYseC/\ WHlku01UFh bg0WAvl/WWeesm4dHtc= -----END CERTIFICATE----- 5.4 Certificate Revocation List t.b.d. 6. Acknowledgements This document was based on discussions with various IPsec implementers and PKI service providers, as well as other members of the IETF community. It also benefits from the spirit of Thayer,Kunzinger Expires November 1999 [Page 19] IPsec PKI INTERNET-DRAFT May 1999 interoperability exhibited by participants in the various IPsec bakeoff events. 7. Security Considerations Check the current literature for recent changes in the known safety of the algorithms mentioned here, including MD5, SHA-1, RSA, and DSA. You have to store the private key(s) safely. If you use keys of varying lengths, such as a 512-bit RSA root with 1024-bit usage certificate, there may be implications as to the security of your infrastructure. Root or other Signing Certificates should be obtained in a secure manner, probably NOT sent over the IKE exchange or from a directory, in order to make sure you are not checking against a spoofed root. The distinguished name in a signing certificate cannot be assumed to be unique or correct. Names in certificates, such as IP addresses or FQDN's should be checked for consistency with other information about the security associations being formed. If you cross-sign signing certificates you run the risk of leaking trust across hierarchies in unintended ways. 8. IANA Considerations Two new object identifiers are added in this draft, which will be submitted to IANA for inclusion in the SMI OID area, see www.iana.org for more information. Thayer,Kunzinger Expires November 1999 [Page 20] IPsec PKI INTERNET-DRAFT May 1999 9. Colophon 9.1 Authors' Addresses Rodney Thayer SSH Communications Security, Inc. 4320 Stevens Creek Blvd, Suite 220 San Jose, CA 95129 Rodney@ipsec.com Charles A. Kunzinger IBM kunzinge@us.ibm.com 9.2 About this document Document edited with Word '98, printed to 'generic text only printer' on Windows 95, post-processed to fix Carriage Return/Line Feed issues with custom code. Spell checker configured for UK English. 9.3 Change History This is revision 02 of draft-ietf-ipsec-pki-req-.txt. The section on chain delivery (3.2) was clarified. The object identifiers iKEEnd and iKEIntermediate's values were corrected. Text was altered per comments from the ANX group. This is revision 01 of draft-ietf-ipsec-pki-req-.txt. This version was spell-checked and certain other typographical errors were corrected. The reference to key lengths all being the same was removed. The last two paragraphs of the abstract were moved to the introduction. The dates in the headers, footers, and first and last page were updated. The text was changed so the validation requirements on subjectAltName fields are listed as "SHOULD" and "MAY" and not "MUST" operations. Chapter 3 was changed significantly to reflect the existence of RFC2314 (IETF version of PKCS#10) and to clarify some points about the processes. The Security Considerations section has been updated to reflect these various changes. Added and updated terms section. Changed two-algorithm requirement to a SHOULD and made it more clear. This document was originally distributed in April 1998 under a different name. There was a second version, distributed at the September 1998 IPsec Bakeoff in Redmond at Microsoft. Thayer,Kunzinger Expires November 1999 [Page 21] IPsec PKI INTERNET-DRAFT May 1999 10. References [PKCS #7] RSA PKCS specs [DOI] [DSA] dsa defn as specified in pkix, ietf doc or other? Xxx [BAL-EMS] LaMacchia, B. "Enrollment Message Syntax", unpublished proposal discussed at IPsec Bake-off in Redmond, September 1998. [DNS-TEST] Eastlake, D., "Reserved Top Level DNS Names", draft- ietf-dnsind-test-tlds-11.txt, July 1998. [PKIX-1] Housley, R. (SPYRUS), Ford, W. (VeriSign), Polk, W. (NIST), Solo, D. (Citicorp), "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", draft-ietf-pkix- ipki-part1-11.txt. [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC-1421, February 1993. [RFC-2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5" [RFC-2401] Atkinson, R. and Kent, S., "Security Architecture for the Internet Protocol", November 1998. [RFC-2409] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", November 1998. Thayer,Kunzinger Expires November 1999 [Page 22] IPsec PKI INTERNET-DRAFT May 1999 [Weinstein] Weinstein, J., Private communication regarding "----- BEGIN CERTIFICATE-----", September 1998. Thayer,Kunzinger Expires November 1999 [Page 23] IPsec PKI INTERNET-DRAFT May 1999 Appendix A. Summary of Formats 1. Names Distinguished Names SHOULD be no more than four (4) attribute/value pairs each of which SHOULD be no more than 128 characters in length, or the length specified in [PKIX-1], whatever is shorter. 2. Object Identifiers for Signature Algorithms SHA-1 with RSA Signature should use the PKCS OID, 1.2.840.113549.1.1.5 [PKCS-1v1.5]. 3. Object Identifiers for Extended Key Usage The OID "iKEEnd" (iso.org.dod.internet.security.ipsec.certificate.1, or 1.3.6.1.5.5.8.2.1) identifies an IPsec Usage Certificate for an end system. The OID "iKEIntermediate" (iso.org.dod.internet.security.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.2) identifies an IPsec Usage Certificate for an intermediate system. Thayer,Kunzinger Expires November 1999 [Page 24] IPsec PKI INTERNET-DRAFT May 1999 B. PKIX Issues This appendix describes differences between this document and existing PKIX standards. It also lists items we need to alter here to clarify the information presented. 1. Our document actually has no definition of a "certificate". For completeness, we should probably include one. Even the PKIX documents didn't have an explicit definition. The best I found was in "draft-ietf-pkix-ipki-part4-03.txt" , section 1.1, from which I extracted the following abbreviated : "A public-key certificate binds a public-key value to a set of information that identifies the entity (such as a person, organization, account, or site) associated with the use of the corresponding private key (this entity is known as the "subject" of the certificate). The degree to which a certificate user can trust the binding embodied in a certificate depends on several factors [including] the practices followed by the certification authority (CA) in authenticating the subject." 2. I'd like to use the definition of "Certification Authority" from "draft-ietf-pkix-roadmap-00.txt", section 2, which is more complete than the one in our document: "An authority trusted by one or more users to create and assign certificates. Optionally the certification authority may create the user's [public/private] keys." 3. The PKIX Roadmap also has a concise definition of a "root CA": "A certification authority whose certificate is self-signed: that is, the issuer [of the certificate} and the subject [of the certificate] are the same entity." And then we could also add Root certificate: "A self-signed certificate whose associated private key is used by a certification authority to sign the certificates that it issues." (Also, although this isn't a direct definitoin in the PKIX documents, we might also want to add that a rrot CA certificate will contain the BasicCOnstraints extension with the cA value set to TRUE.) 4. I found the definition of "Signing Certificate" a little hard to follow. At first, I was thinking about the certificates that IKE peers would use in creating the RSA signatures, for example. But the text actually is talking about the CAs' certificates, not the IKE peers' certificates. At least for me, it might be clearer if we first defined the concept of a certificate chain. I found some text in "draft-ietf-pkix- part1-09.txt", section 3.2, that might be a good start. I created the following definition by selectively using parts of the first paragraph in that section: "Certification Paths -- If the user does already hold an assured copy of the public Thayer,Kunzinger Expires November 1999 [Page 25] IPsec PKI INTERNET-DRAFT May 1999 key of the CA that signed the certificate, then it might need an additional certificate to obtain that public key. In general, a chain of multiple certificates may be needed, comprising a certificate of the public key owner signed by one CA, and zero or more additional certificates of CAs signed by other CAs. Such chains, called certification paths, are required because a public key user is only initialized with a limited number of assured public CA keys." 5. Given this definition, we could then define "CA Certificate" as follows: A certificate that carries the public key associated with a certification authority. A CA Signing Certificate will contain the basic constraints extension with the "cA" value set to TRUE. The certification authority uses the associated private key to sign the certificates that it issues. In a certification chain, there will be only one root CA: that is there will be only one self-signed signing certificate. All other signing certificates in the chain will have different values in the issuer and subject fields." 6. The definition of usage certificates also seems somewhat roundabout to me. Elsewhere in the draft, you refer to "identification certificates", which are probably the same thing. In the context of IPSec, could we use the term "IPSec Identification Certificate". In PKIX terms, I think this is probably what they call an "end entity certificate". A possible definition could then be: " A certificate issued by a certification authority to an IPSec-aware device that binds the device's public key to a set of information that identifies the device. IPSec Identification certificates are not self-signed and do not include the BasicConstraints extension. The public key contained in a given device's IPSec Identification Certificate will be used by an IKE peer during the Phase 1 IKE exchange in the process of authenticating the given device. 7. Having made use of the BasicConstraints extension in item 5, we should probably also include a definition in our list for clarity: "BasicConstraints Extension: a extension in a certificate that identiifes whether the subject of the certificate is a CA and how deep a certification path may exist through that CA." (taken from section 4.2.1.10 of "draft-ietf-pkix-ipki-part1-11.txt"). Thayer,Kunzinger Expires November 1999 [Page 26] IPsec PKI INTERNET-DRAFT May 1999 C. IKE Issues 1. Formats of payload contents_ 2. Cert Request is optional instead of mandatory 3. Other... Thayer,Kunzinger Expires November 1999 [Page 27] IPsec PKI INTERNET-DRAFT May 1999 D. Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This draft expires 31 November 1999. Thayer,Kunzinger Expires November 1999 [Page 28]