[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "PKIX Profile for IKE"--Is it really a profile?
-----Original Message-----
From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
Sent: Monday, October 25, 1999 8:06 PM
To: ipsec@lists.tislabs.com
Subject: Re: "PKIX Profile for IKE"--Is it really a profile?
I agree with Paul on all the topics which are already covered in PKIX,
duplication will only lead to confusion.
>· EKU MUST contain only object identifier iKEIntermedate
This is pretty clear.
Clear but wrong? Why must it only have one value????? Are you trying to say
that we mustn't use the old values, or are you trying to say that we must
not have any other EKU values if iKEIntermedate is used?
>Note also that some of the important details about the operation of
IKE
>are not addressed in this profile, even though in many cases the
existing
>IKE specs leave the details open to interpretation. For example,
>there is no normative text to outline a profile-specific
>method for handling IKE?s CERTIFICATE and CERTIFICATE REQUEST
>payloads,
Quite correct and this is one of the areas that we *must* address.
It could be clearer but I think it is all there already.
> there is no normative text to describe certificate
>validation in IKE (e.g., what if an evaluating system does not
trust
>its peer's root CA,
Then no validation happens, period. That's fully covered in PKIX.
Agreed (with Paul).
> what are the normative rules for matching a
>certificate?s subject to IKE?s ID Payload fields,
That's a good question. Many companies have told me that they never
intend
to match the subject to the IKE initiator. I find that scary, but
it's what
many people want. I would prefer statements in this profile that say
you
SHOULD (maybe MUST) match the subject, but that's open for debate.
Then they don't understand the security implications and this is something
that should be explained in the doc. The DOI mentions that if the ID
payload is used for policy decisions then the ID SHOULD be contained in the
certificate. If they use the ID in the ID payload for policy lookups but
don't verify that ID than they have serious security problems. Perhaps one
of the reasons this isn't pointed out is it was thought to be obvious. I
can substitute any ID I want, my signature will still verify because I have
sent you my cert. If they do not use the ID in the ID payload to look up
policy and instead use the ID contained in the certificate then there is not
a problem.
> can a given IKE
>implementation recognize more than one root CA,
Of course; why not?
Again the trap of over specifying.
We shouldn't get into the situation where someone writes a certificate
validation routine based on this spec. They should write it to PKIX and
then apply it to IPSec using this spec, there are really only a few minor
things to do once you get past PKIX. Which are in the current draft, verify
ID payload to certificate identities, SA life time vs Certificate life time,
etc...
Bye.
Greg Carter
Entrust Technologies - http://www.entrust.com
http://www.ford-trucks.com/articles/buildup/dana60.html