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

Re: Latest ipsec-pki-req-04.txt - where do certs go in IKE



At 06:28 AM 12/16/99 +0200, Tero Kivinen wrote:
>Paul Hoffman writes:
>> >6.1 Signature-based authentication
>> >Main Mode - Certificate Request
>> >I would much prefer that we specify only which parts of the exchange where
>> >it does not make sense to send these payloads rather than trying to
restrict
>> >where they are sent.  To me it makes perfect sense to send a cert
request in
>> >2(responder), 3(initiator), 4(responder) or 5(initiator).  Since after the
>> >SA is agree you will know if you want a cert.
>> 
>> 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 
>
>The pictures in the IKE documents are ONLY EXAMPLES. They are not
>supposed to be complete and they are much of other legal ways to put
>the payloads together (Examples of this is the payload ordering and
>the optional payloads (certificate, certificate request, notify etc).
>
>> 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.
>
>IKE does not say that you can only have certificate payloads in
>messages 5 and 6. In the examples it only shows those payloads in
>those messages, because they normally appear there, but it does not
>mean that it is not allowed to send them any other messages.
>
>The only restriction IKE makes is that it does NOT allow you to send
>certificate request payload in a way which would extended the
>exchange, i.e. in the 6th message of main mode or in the 3rd message
>of the aggressive mode. 
The verbal rule for cert requests and certs in IKE was "anything
can arrive from deep space at any random time and you have to
just cope". This was, of course, stunningly bad protocol design.
If we want to quantify this, let's update (some appropriate)
document, let's not tell people to read obscure footnotes in 
random irrelevant sections.

If we want this thing to be a usable protocol, let's document
when and where you are supposed to send what.





References: