[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Latest ipsec-pki-req-04.txt illustrations considered harmful
this is obscene, no new developer would have caught this.
At 07:40 AM 12/16/99 +0200, Tero Kivinen wrote:
>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: