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

Re: Latest ipsec-pki-req-04.txt

Paul Hoffman writes:
> At 06:28 AM 12/16/99 +0200, Tero Kivinen wrote:
> >The pictures in the IKE documents are ONLY EXAMPLES.
> They are? I didn't see anywhere in the document that says that or even 
> hints that. Sorry if I'm being dense, but maybe this should be clearer in 
> the new RFC.

There is some text about that in the 5.5, where it describes the hash
calculation:
----------------------------------------------------------------------
...
   With the exception of the HASH, SA, and the optional ID payloads,
   there are no payload ordering restrictions on Quick Mode. HASH(1) and
   HASH(2) may differ from the illustration above if the order of
   payloads in the message differs from the illustrative example or if
   any optional payloads, for example a notify payload, have been
   chained to the message.
...
----------------------------------------------------------------------

I agree that it should say that more clearly in the beginning of the
document. 


> Because this could turn into an message that is >50K bytes. Very long UDP 
> messages are inherently dangerous, yes?

So the client has 50-80 different end user certificates, but no idea
which of those to use for that party? I don't really think clients
will have that many certificates. 

> >There is also INVALID-CERT-AUTHORITY and CERTIFICATE-UNAVAILABLE
> >notifications that can be used.
> But you use those when you cannot set up an SA. What if a party sent three 
> cert requests with three different roots, of which you only have one 
> matching. I don't think you should send back two CERTIFICATE-UNAVAILABLE 
> failure notices and a cert; I think you send two NONE cert payloads and a 
> real cert.

What value the NONE certs have? They don't tell the other end
anything. Note there is no restriction that you should answer in the
same order than the certificate requests came in. Also one certificate
request can result in multiple certificate to be sent.

> The other option is to only send certs that do match, and if there
> are none, you obviously would want to send an error notification.

I think most of the implementations out there will reply to those
certificate requests they know something about, and silently ignore
all of the others. If they don't know how to answer at all there is
three choices:

	1) Send all end user certificates you have and see if the
	   other end can use them.
	2) Send nothing, and hope the other end will dig out your
	   certificates somewhere.
	3) Send error notification back and fail.

I think the order above is the preferred and also currently most
implemented order. I don't think I have ever seen
INVALID-CERT-AUTHORITY or CERTIFICATE-UNAVAILABLE notifications.

Checking the isakmp-test.ssh.fi site logs, I seem to have received 22
INVALID-CERT-AUTHORITY notifications out of 1337 notifications other
implementations have sent to our site, and zero
CERTIFICATE-UNAVAILABLE notifications. All of those
INVALID-CERT-AUTHORITY notifications came from the single
implementation. In total there has been 9652 negotiations from 434
different ip-numbers to the site.

The site will always send certificate request payload when using
certificates. There is an option to disable sending it though.

BTW, I couldn't find a single certificate payloads with none encoding.
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
Follow-Ups: References: