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

Re: Query on draft-ietf-ipsec-pki-req-03.txt



At 07:55 AM 10/19/99 -0700, Walker, Jesse wrote:

The draft includes the following text in Section 2:
        IKE systems conforming to this profile MUST check the
        revocation statusof any certificate on which they rely, using
        the algorithm described inthe PKIX certificate profile. Thus,
        every conforming IKE system MUSThave a method for
        receiving up-to-date revocation information for thecertificates
        it is validating.
What do you intend this to mean in the remote access case? One normal
operational scenario will have the CRL distribution point the remote IPSec
host needs to validate the security gateway's certificate behind the
security gateway.
I don't think putting a CRL source (such as an FTP or LDAP server) behind a security gateway is the normal case. The main reason to do that is to hide the identities of the certificates you have revoked (which might have a business purpose). Normally, these are wide open.

 In such a case, unless it has already obtained the CRL via
an alternate channel, the remote host will be unable to meet the above
requirement.
And, I think that "unless" is exactly right: you must use the information you have.

 Seemingly the best that it could be able to do is to establish
IKE and IPSec security associations, then attempt to obtain the CRL, and
then decide what to do on the basis of whether or not it could get the CRL
or the security gateway's cert gets validated. Maybe we need to require
implementations to send the latest CRL known to them during the IKE phase 1
negotiation?
I would be against that because some CRLs will be very large. In the case of a hidden CRL DP, I'd say "you must use what you already know". I think it is good to say "if the device knows that its CRL DP is not currently available to the other party behind a security gateway, that device SHOULD send its CRL".

-=-=-=-=-=

At 08:06 AM 10/19/99 -0700, Walker, Jesse wrote:

Section 3.2 says
        The subject field in IPsec certificates SHOULD be populated and
non-null
        (this is contrary to the PKIX certificate profile, which says
thatthe subject
        MUST NOT be populated if the identification is in thesubjectAltName
        field). The exact contents of this field are notstandardized. By
convention, a
        minimal subject field containscountryName and commonName.
Distinguished
        names SHOULD be no more thanfour attribute/value pairs, each of
which
        SHOULD be no more than 128 characters in length (these restrictions
do
        not appear in the PKIXcertificate profile). An IKE implementation
that
        conforms to thisprofile SHOULD NOT reject a certificate that does
not
        follow theserules.

Why? The rationale for this requirement is not immediately obvious.
Personally, I think it is completely lame. I would like to rip that wholerement out of the spec. Would anyone object to me doing so? That is, has anyone shipped an implementation that is so non-compliant that it *requires* a non-null subject even though there's a subjectAltName?

-=-=-=-=-=

At 12:28 PM 10/19/99 -0400, Greg Carter wrote:

>From 1. Introduction, first paragraph:

"Note that many IPsec implementers are not completely happy with the PKIX
documents and procedures, but have agreed to use the PKIX protocols because
they are supported in other contexts and have a significant market share."

and last paragraph

"(It is noted that the fact that the two documents differ does not give
great confidence to the IPsec community or other users of the PKIX
protocols.)"

Both of these, whether or not true, are opinions and don't really do
anything to help implementers beside adding confusion.  I would suggest they
be taken out for clarity.
Rodney and I put them in to indicate that the reader shouldn't assume that reading the PKIX documentation literally is a good idea.

>From section 3.1 The extendedKeyUsage field:

"In a certificate for an IPsec end entity, the extendedKeyUsage field
commonly called "EKU") MUST be present and MUST contain only the object
identifier iKEIntermediate
(iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or
1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT
accept end-entity certificates that do not follow this rule."

Why must the certificate only have the one extended key usage?  This is too
restrictive.  I like the idea of only having one IPSec extended key usage
bit though.  Could we stick with PKIX and say that if flagged critical then
it must only have one value.  Therefore you could remove the "and MUST
contain only the object identifier iKEIntermediate..." since that would be
covered by PKIX RFC 2459 section 4.2.1.13 for critical extended key usage
extensions.
I agree with this. I can see many reasons why a CA would create a single cert for an IKE system that might have multiple uses.

In Section 3.2 The subjectAltName field, last paragraph:
"The subject field in IPsec certificates SHOULD be populated and non-null
(this is contrary to the PKIX certificate profile, which says that the
subject MUST NOT be populated if the identification is in the subjectAltName
field)"

This is not true, PKIX states in section 4.2.1.7  Subject Alternative Name
that:

Further, if the only subject identity included in the certificate is an
alternative name form (e.g., an electronic mail address), then the subject
distinguished name MUST be empty (an empty sequence), and the subjectAltName
extension MUST be present. If the subject field contains an empty sequence,
the subjectAltName extension MUST be marked critical.

The important phase being "if the ONLY subject identity included in the
certificate is an alternate name form".  It does not say "If the alternate
name form is used then NO subject distinguished name may be present." which
is how I read section 3.2.  For clarity I would stick with the PKIX
definitions of how subject and alternate names are to be used and remove the
last paragraph.
I agree.

If ONLY the alternate name is to be used then the subject should be left
empty as PKIX states.  However in practice I do not know of any
implementations that only identify the 'device' by alternate name.  For
administration purposes they will always have a subject name, however there
may exist a situation where someone would like to restrict to only using the
alternate name for identification and the only way to do this is with an
empty subject.
And here we disagree. How are such CA's identifying an IKE system in the subject? If you mean "kludging the IP address or DNS name into a subject field", I have no problem saying that that MUST NOT be done in this profile. How do others feel about this?

Also in the last paragraph of section 3.2:
"Distinguished names SHOULD be no more than four attribute/value pairs, each
of which SHOULD be no more than 128 characters in length (these restrictions
do not appear in the PKIX certificate profile)."

Again these are too restrictive.  Names in the subject/issuer are dictated
by the customers directory setup (for those using one).  In practice I have
seen longer names than 4 attribute/value pairs.  Length... well I don't know
much about multi char character sets but I wouldn't want to limit anything
which would prevent IPSec certificates being used in foreign languages.
Agree.

>From Appendix A:

"Regardless of the protocol used, a CA who gets an IKE system's enrollment
request that includes the subject and subjectAltName desired for the device
MUST include exactly the same subject and  subjectAltName in the
certificate. If the CA does not want to issue a certificate with the same
subject and subjectAltName that was requested, the CA MUST NOT issue a
certificate with a different name and subjectAltName."

This places an unnecessary burden on the end entity to determine what
exactly its DN will be, PKIX-CMP and I think CMC both allow the CA to change
the DN that is in the request.  If the device must have the exact DN then it
means a user somewhere has to type it in, very prone to failure.
I agree. I think we should take out that restriction. If the IKE system doesn't like the cert it gets (for example, because the CA changed the subject or subjectAltName), the system doesn't have to use that cert.

  Also there
is no mention of how to verify the request at the CA.  The device should
generate a hash of the der encoded request and make it available to the
devices administrator for verification at the CA.  Otherwise the request is
accepted without verification.
This makes sense to me, and could be part (obviously) of the out-of-band info.

  Also mention of how to obtain the CAs keys
in a secure way, similarly usually done with a hash of the CAs der encoded
certificate.  May want to add this to the security section?...
This could be added. It's covered in PKIX, but yet another paragraph in the security section is always safe...



--Paul Hoffman, Director
--VPN Consortium