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


On 21 Oct 99, at 9:19, Dan Harkins wrote:


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)?

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 

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)?

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.

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").


>   A few weeks ago I was alluding to a draft which would address the
> desire to do token card authentication in IKE (and do it securely).
> The draft is out but is an individual I-D submission due to the fact
> that remote access is going to be the responsibility of IPSRA which
> does not yet formally exist. Please check it out and comment. It's
> called draft-harkins-ipsec-ike-crack-00.txt and can be found with the
> others at http://www.ietf.cnri.reston.va.us/internet-drafts.
>   Dan.