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

CRLs

ISAKMP has a certificate request payload, with various types, including CRL
and ARL.

If your implementation determines it can not retrieve CRLs via its regular
method (LDAP etc.) then include a Certificate Request payload with type set
to CRL (you should also include one for ARL so that when a chain is sent you
get the various ARLs needed to verify the CA certificates).  When you
receive a Certificate Request payload with type CRL you MUST reply with the
DER encoded CRL that your certificate would be listed on if it were to be
revoked.  This requires that at least one side has access to the CRL
repository.


So don't send it unless asked, if asked the above covers how. If they ask
then they can process, so there shouldn't be interop problems.  If they ask
and you can't produce then you have a problem, if you can't produce because
you don't support CRLs than that is your problem. If you only support OCSP
as a gateway and the OCSP server is behind your gateway your SOL.  If you
only support OCSP and you expect to intero with clients that don't and the
CRL repository is behind your gateway then you are SOL.  

So I think gateways should be prepared to respond with a CRL.  Its a very
convenient method of transporting CRLs.  

Putting the LDAP server behind the gateway is common.
Bye.

Greg Carter
Entrust Technologies - http://www.entrust.com
http://www.ford-trucks.com/articles/buildup/dana60.html


-----Original Message-----
From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
Sent: Monday, October 25, 1999 8:45 PM
To: ipsec@lists.tislabs.com
Subject: 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
Follow-Ups: