Comments/Observations on IPSec/PKI Requirements
kunzinge@us.ibm.com Tue, 23 February 1999 16:09 UTC
Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01746; Tue, 23 Feb 1999 08:09:35 -0800 (PST)
Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18255 for ipsec-outgoing; Tue, 23 Feb 1999 08:14:29 -0500 (EST)
From: kunzinge@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: ipsec@tis.com
Message-ID: <85256721.0047E589.00@d54mta05.raleigh.ibm.com>
Date: Tue, 23 Feb 1999 08:06:06 -0500
Subject: Comments/Observations on IPSec/PKI Requirements
Mime-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-Disposition: inline
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
This is the first of 2 notes that I thought I mailed a few days ago, but it does not appear to me that it was ever sent. I apologize in advance if this is a duplicate. ******************************************* In reviewing the "draft-ietf-ipsec-pki-req-02e.txt" (denoted "IPSec-PKI"), we found several areas of confusion or imprecision which we offer to the working group for their comment and feedback. They all center around terminology differences between the multiple IPSec documents and multiple PKIX documents. The PKIX documents that we looked at while developing these comments are: a) RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", b) draft-ietf-pkix-roadmap-00.txt, "Internet X.509 Public Key Infrastructure PKIX Roadmap" (denoted as "Roadmap", and c) draft-ietf-pkix-ipki3cmp-09.txt, "Internet X.509 Public Key Infrastructure Certificate Management Protocols" (denoted as "CMP"). Our comments are as follows: 1. Recent discussions on the PKIX mailing list have discussed the definition of a "root CA". It appears that both "Roadmap" and "CMP" will not use a definition that a "root CA" is one whose certificate is self-signed. Instead the CMP group is converging on a trust-based definition rather than one based on a CA's relative position in the certification chain. The "CMP" definition is: "We use the term "root CA" to indicate a CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s). This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly." (See CMP, section 1.2.2). In RFC 2459, there is a rudimentary concept of a "most trusted CA" (see RFC 2459, section 3.2) which seems to map into the CMP definition of "root CA": "As a result, this document supports a more flexible architecture, including:(a) Certification paths may start with a public key of a CA in a user's own domain, or with the public key of the top of a hierarchy. Starting with the public key of a CA in a user's own domain has certain advantages. In some environments, the local domain is the most trusted." RFC 2459 also goes on to say in section 6 that "The 'most-trusted CA' is a matter of policy: it could be a root CA in a hierarchical PKI; the CA that issued the verifier's own certificate(s); or any other CA in a network PKI. The path validation procedure is the same regardless of the choice of 'most-trusted CA'." I may have misunderstood things, but when I read through our IPSec-PKI document the first time, I had assumed that the "root CA" and the "trusted CA" were one and the same, which apparently is not the case. And I got the impression that a certification chain always had to be traced back to its "root CA". Having reviewed the PKI documents, I now believe that the key concept for our work is the "most trusted CA", regardless of its relative position within a certification chain"--for example, if I were tracing through a certification chain, I would stop when I locate a "most trusted CA", even if that CA was not at the very top of the certification heirarchy. It also appears that the definition of a root CA as one with a self-signed certificate is largely irrelevant. In summary, then, can we amend the IPSec-PKI document to clarify "root CA" and "most trusted CA", and explicitly note whether or not the terms are synonymous? My preference would be to use the trust-based definition of "root CA" as in the PKI documents, and to drop the "self-signed" definition entirely as it appears to be largely irrelevant. 2. "IPsec-PKI" implies that an IPSec Identification Certificate should contain a non-empty "subject" field and also a "subjectAltName" field carrying an IP Address, a DNS Name, or an RFC822 Name. Our products will declare a match between the ID Payload field of the IKE messages whenever there is a match with either the certificate's "subject" field or with its "subjectAltName" field. Hence, we feel that the subjectAltName field must be marked as "non-critical" whenever the "subject" field is non-empty. However, we did not find a statement in IPSec-PKI to corroborate this approach. 3. A related issue is the matter of matching certificate subjects and IKE ID Payloads. When one uses the public-key based IKE authentication methods, the contents of the ID Payload from IKE MUST match with at least one of named subjects of the IPSec Identification certificate. However, I couldn't find an explicit statement of this fact in "IPSec-PKI", nor does it define any explicit rules for determining a mathc (or mismatch). We will try to offer some draft text for "IPSec-PKI" section 3.5 in a separate posting to address this and other issues within the next few days. 4. Since an entity can associate the same public key with several different identities, RFC 2459 allows "subjectAltName" field to name multiple identities within a given certificate (see RFC 2459, section 4.3.1.7 for example). Note also that the "Roadmap" in section 5.1.1.2 expressly permits the "subjectAltName" field to carry multiple name forms, and also allows multiple instances of any given name form. Section 4.1.2 if IPSec-PKI appears to permit multiple name forms within the subjectAltName field, but appears to denigrate the appearance of multiple instances of a given name form ("This field SHOULD contain at most one of each of these values..."). Why the strong recommendation against using multiple instances of the same name form? For example, a given person may have multiple e-mail addresses, and it would be convenient to be able to include all of them within the "subjectAltName" field of a given certificate. 4. We do not see value in the ExtendedKeyUsage extension outlined in IPSec-PKI. Imposing a granularity at the level of a end node or an intermediate node is not realistic. A given Security Gateway, for example, may play the role of intermediate node when it is acting as proxy for systems located behind it, but may also play the role of end node when it is exchanging information on a peer basis with another Gateway box. We do not wish to have to obtain multiple certificates to accommodate this situation. If the IPSec working group elects to retain this extension in IPSec Identification certificates, then as a minimum it should be marked as "non-critical". 5. "IPSec-PKI" does not discuss the use of "wildcard" name forms in the subjectAltName field of the certificate (section 4.1.2 discusses only non-wildcard name forms), but the "Roadmap" states that after due deliberation, the PKIX WG will permit the use of wildcards in name forms (see "Roadmap" section 5.1.5). We are uncertain about the value of allowing wildcard name forms in IPSec Identification certificates, and would appreciate feedback from working group members on this topic. 6. RFC2459 describes a critical extension for CA certificates("basicConstraints", section 4.2.1.10). This field indicates if the subject is (or is not) a CA, and it also places a limit on the number of subordinate CA that can be in a certification chain between itself and the IPSec device. Should "IPSec-PKI" require that this field be checked during certificate validation--that is, should we reject a peer's IPSec Identification certificate if its certification path is too long? ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) Network Security Product Development, Dept JEUA,, RTP Phone: Tie 8-444-4142 , External 1-919-254-4142 Fax: Tie 8-444-6243, External 1-919-254-6243