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

Re: CRACK

  Hi Valery,

On Fri, 22 Oct 1999 16:51:58 +0400 you wrote
> On 21 Oct 99, at 9:19, Dan Harkins wrote:
> 
> Dan,
> 
> some comments/questions regarding the draft.
> 
> 1. If client doesn't have server's public key, it includes CERTREQ 
> payload in its first message. RFC2408 allows to return several 
> certificates (certificates chain). In this case ID payload usually 
> helps client to quickly decide which certificate of the chain is end 
> entity (server) certificate and to start path construction from it. 
> CRACK exchange doesn't contain ID payloads (as far as I understand). 
> So, does it imply that CRACK disallow server to return several 
> certificates? Or, otherwise, how client will solve this problem? Why 
> not include ID payload in case server sends its certificate(s)?

I was assuming that the "right" certificiate in the chain would be 
gleaned from the process of parsing the chain but I've not given it much 
thought. Perhaps an ID payload is needed.

> 2. CHRE payload may simultaneously contain both "generic 
> challenge/response blob" and attributes. How its body should be 
> parsed in this case? In other words, assuming that attributes follow 
> the "blob", how one can determine the "blob" length? Or have I missed 
> something?

The blob is the attributes but different LAM types have different attributes
so we just called the generic set of attributes a blob.

> 3. In paragraph 5.4 some it is mentioned that client passes its 
> identity in IDi payload, however, this payload is not present in the 
> following diagrams and is not mentioned anywhere else. Where is the 
> error (if it really is)?

That's an error. Thanks for finding it. The identity is the CRACK_USERNAME
and it's part of the blob of the first CHRE payload. This'll get fixed.

> 4. About VendorID payload. As far as I understand it is present in 
> CRACK exchange itself. So responder needs to parse unknown (private) 
> exchange message to find it (and, thus, to get knowledge of how to 
> parse that message). It seems not to be the problem for CRACK (and 
> for any exchange that uses only generic ISAKMP payload headers in its 
> message payloads) but, in general, it scares a bit. Please, correct 
> me if I'm wrong.

Yes, that is backwards but that's the protocol we have to work with. 
You have to parse the first message in the exchange to get a DOI value
too. So you're already parsing payloads before you know how to really
parse all payloads. This is a regrettable part of the ISAKMP/IKE/DOI
mix. If this draft is advanced IANA will assign it valid exchange
numbers from the approprate place and the requirement to use the
vendor ID payload will go away.

The alternative would be to do what ISAKMP-Config did and just grab a
number from a numberspace that it does not manage. I could've made the
CRACK exchange 6 since it has not been assigned by IANA yet. That
would'be caused protests since that's the number that ISAKMP-Config
used. ISAKMP-Config did not follow the process. That's another problem
altogether. I didn't want this draft to contribute to this mess and the 
right way to do it (with vendor ID payloads) is, as you point out, 
problematic.

> 5. There are 3 identical paragraphs in the draft (starting with  
> "CRACK_MESSAGE is optionally sent...") and all three contain the same 
> typo - "MAY by used by" (I guess you mean "MAY be used by").

OK, thanks for this too.

  Dan.
References: