[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Latest ipsec-pki-req-04.txt
Instead of a lot of quoted text I'll restate a few things.
First I agree with all of Tero's comments.
Next to your comments Paul:
- Certificate Request Payload
As Tero stated the IKE diagrams are guides. ISAKMP states that payloads can
come in any order in the packet, optional payloads any time (rfc 2408 4.1
ISAKMP Exchange Types). I think the only restriction to this is that the SA
payload must be first.
The above is my "But it says this here" argument. Now my "but we have been
doing it this way" argument.
As an implementer I have taken advantage of this to get the cert requests
out of the way as soon as I know that I am doing a signature mode
authentication. I have been doing this for over 2 years at many bakeoffs
without harm to anyone.
I'll also note that IKE doesn't even show cert request payloads in the
packet diagrams, so to say that sending them before 4 or 5 is 'changing IKE'
isn't really true. Perhaps you were confused with Certificate payloads?
- 6.3 Content of Certificate payloads
You state that you disagree that this is new behavior. I haven't found
where it states in IKE or ISAKMP that you are to respond with a cert type of
NONE when you can not build a chain to the requested CA? ISAKMP states that
a notify with value CERTIFICATE-UNAVAILABLE MAY be sent. However I would
like to think that an optimistic approach of continuing the negotiation is
practical.
Please re-read my example. I am not at all proposing that an entity respond
with a list of certs that MAY chain to some root. I said 1 cert, that being
the entities cert. The other end having access to the certificate
repository can build a correct chain and provide it to the peer. And having
access to the repository can determine trust in the peers certificate.
I could give other examples for hierarchy but I will leave that as an
exercise to the reader :) I used cross certification because it was a clear
example of the problem that is solved leaving IKE as it is. I really don't
see the logic in defining new behavior that limit's the usefulness of IKE.
A.1 Enrollment requests with PKCS10 plus out of band information
- Re hash of DER encoded request for verification
You state - "This seems to me to be an operational issue, not a protocol
issue."
A PKCS10 blob needs to be authenticated, simply verifying the signature on
it does nothing to verify the authenticity of the request. It means that
whomever created the request has access to the private key. Since this
document is defining the format and suggests methods of transporting the
request, I think it is wise that it also state a baseline cryptographic
means of authenticating the requests. I have seen some products that
provide no way of authenticating the P10 messages they generate, so it would
be nice to include this here.
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: Wednesday, December 15, 1999 6:50 PM
To: ipsec@lists.tislabs.com
Subject: Re: Latest ipsec-pki-req-04.txt
At 02:15 PM 12/15/99 -0500, Greg Carter wrote:
>6.1 Signature-based authentication
>Main Mode - Certificate Request
But doing so in messages 2, 3, and 4 are not described in the message
formats in the IKE document. The ISAKMP document says it's OK to put them
there (and in step 1, for that matter), but IKE only has slots for them in
5 and 6. What you're proposing is that we change IKE. I think that's fine,
but we have to do it somewhere other than the PKI document.