[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.