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

Comments/Observations on IPSec/PKI Requirements



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
Follow-Ups: