[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments/Observations on IPSec/PKI Requirements

kunzinge@us.ibm.com wrote:
> 
> 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.

Agreed.  


> 
> 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.

Whether SubjectAltName is marked critical or not is irrelevant to IPsec/IKE.
The criticality bit says "if you don't understand this field, you cannot use
this certificate."  Therefore, since it is mandatory for all IPsec/IKE
implementations must at least "understand" this field (whether or not
they actually use the contents), this particular bit is irrelevant in
the context of IPsec/IKE.

That said, PKIX states:

   If subject naming information is present only in the subjectAltName
   extension ..., then the subject name MUST be an empty sequence and
   the subjectAltName extension MUST be critical.

So, if SubjectName is empty, SubjectAltName MUST be critical.  If
SubjectName is not empty, it doesn't matter if SubjectAltName is
critical or not.  I guess it wouldn't hurt to state this in the draft....


> 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.

Or more importantly, a device may have multiple interfaces.   I agree.
This restriction in section 4.1.2 is probably not correct.


> 
> 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?

If this extension is critical (and RFC2459 says it MUST be), then 
implementations MUST reject certificate chains that violate
this extension.  Such chains represent a security violation.
References: