[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSec cert OID usage status ?
The three values with PKIX labels were from the appendix in 2459. I did
a quick check on draft PKIX documents and found that the PKIX group
intends on defining usage of certificates for IPSec:
>From draft-ietf-pkix-roadmap-06.txt
"It is one goal of PKIX to specify a profile for Internet, electronic
mail, and IPSec applications, etc."
>From draft-ietf-pkix-ac509prof-06.txt
"The profile places emphasis on attribute certificate support for
Internet electronic mail, IPSec, and WWW security applications."
I agree we need an IPsec profile for certificate usage (see interop
comments below though). I don't think it matters which group does it.
But it would appear to me this is an addendum to IKE itself, rather than
a generic, keying-protocol-independent, "IPSec certificate" usage
statement. IKE already specifies handling of certain certificate
contents, such as SubjectName and SubjectAltName values with respect to
the ID payload, how to do CRPs, etc.
If the next base PKIX standard will omit IPSec OIDs that 2459 previously
defined, does that mean those OIDs in 2459 are deprecated ?
My comment in mail below was based on the last bakeoff, during
discussion of the PKI interop results, we suggested these minimums for
cert usage and asked the audience for consensus - no hands went up to
support "requirements". Maybe the vendor reps hadn't had enough of a
chance to think about it, or maybe they didn't see cert usage
requirements as necessary to enable interop.
When using IKE RSA-signature mode, when the CERT payload is sent, the
end-entity certificate MUST have:
- key type: RSA, obvious since the private key has to sign the hash for
RSA-sig mode
- key usage: digital signature is one of the usages
SHOULD have:
- 1024bit or greater key size
Are there other minimums ?
Is there a PKIX requirement that says an OID specifies that a cert
identifies a user or machine or role, such as an intermediate point ?
Prior discussion at bakeoffs was that we thought we needed just one OID
to identify the certificate for use with IPSec. Since we had heard that
the PKIX OIDs were going away, we settled just on the new one,
intermediate OID, but I don't recall how that was chosen.
While, these minimums seem perfectly reasonable to me, standardizing
them in hopes of achieving interop is a different issue. The receiver
determines the certificate that the initiator must send, as it's the
receiver which ultimately must accept the certificate. Since there are
many checks on a certificate for authorization, beyond proper PKIX chain
validation for authentication, I don't think interop is actually
accomplished by having such a minimal set of requirements as standard.
It would seem to me that VPN remote access client to VPN server may be
one profile. IPSec GW to IPSec GW doing IPSec tunneling is another
profile. IPSec transport between machines another.
Wm
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Thursday, May 24, 2001 11:37 AM
To: William Dixon
Cc: ipsec@lists.tislabs.com
Subject: Re: IPSec cert OID usage status ?
At 10:39 AM -0700 5/24/01, William Dixon wrote:
>What do people think a PKI vendor should support as the Extended Key
>Usage OIDs for certificates issued for use with IPSec ?
>
>>From prior bakeoffs, I recall that everyone agreed there would be only
>>1
>IPSec usage OID, the intermediate one as below, not the 3 that PKIX had
>previously defined. Rodney's old ipsec certificate profile draft
>suggested that the PKIX OIDs be deprecated. But that draft is expired.
>Consensus from the last bakeoff was also that people didn't want to
>agree on a particular set of requirements for cert usage in IPSec.
>
>IPSEC_KP_IKE_INTERMEDIATE "1.3.6.1.5.5.8.2.2"
>
>OID_PKIX_KP_IPSEC_END_SYSTEM "1.3.6.1.5.5.7.3.5"
>
>OID_PKIX_KP_IPSEC_TUNNEL "1.3.6.1.5.5.7.3.6"
>
>OID_PKIX_KP_IPSEC_USER "1.3.6.1.5.5.7.3.7"
>
Bill,
The next PKIX base standard (successor to 2459) will not contain any
Extended Key usage IDs. IPsec and other PKI-enabled protocols should
create documents to specify these values, and related profiles for
certs. In your list above, I can understand the first and second
examples, and maybe the fourth, but not the third, i.e., why would a
tunnel have a cert?
As for a consensus re NOT agreeing on a cert profile for IPsec, I
think this is a big mistake and would like to understand the
motivation behind such a statement.
Steve
Follow-Ups: