Re: CRACK

[Dan Harkins <dharkins@xxxxxxxxxxxxxxxxxxx>]

  Hi Dan,

  They are just profiles of the exchange. Looking over XAUTH it didn't
seem clear to me that two implementations would necessarily interoperate.
So we wanted to give explicit examples of how you'd tweak CRACK to satisfy 
your legacy authentication method. The attribute technique was lifted
directly from XAUTH but we just wanted to spell out what to do. My 
experience with IKE ("but it isn't explicitly stated in the document!!!")
makes me wary of just assuming things.

  Some text can be added to emphasize this. It is a -00.txt draft and will 
be revved based upon implementation experience and comments from readers.

  thanks,

    Dan.

On Thu, 21 Oct 1999 15:01:44 EDT you wrote
> 
> Dan,
> 
>     This question is a bit involved, and I would bring it up at the WG,
> except that I will be unable to attend.
> 
>     Overall, I applaud your effort to come up with a scheme that supports
> legacy authentication while maintaining a level of security that we have
> come to expect from IPSec protocols.
> 
>     I did a quick scan of this draft.  One comment I would make is that
> you classify RADIUS as using the Password-based profile, yet RADIUS also
> allows for a Challenge/Response "dialogue".  Furthermore, it seems to me
> that the SecurID "Next Code" mode is really the same as a
> Challenge/Response with one challenge.
> 
>     So could you comment on why you chose to "break out" the different
> authentication techniques as separate exchange profiles rather than the
> generic Challenge/Response "dialogue" that XAUTH uses?  And if this makes
> sense, then would you agree that RADIUS (and I suspect DIAMETER as well)
> should be included as in the Challenge/Response list as well?  Or is this
> list just a "helpful example"?  If it is, then the draft should make it
> clear.
> 
>     Also, very minor nits, last sentence of the next-to-last paragraph of
> section 3.1 says
> 
> "When the gateway returns a SIG payload, the client MUST conclude the
>                                             ^^^
> protocol in his next response by return his correesponding SIG payload."
> 
> ^^^^^                              ^^^
> 
> I suppose you want to say "SIG2", "returning", and "SIG3", respectively
> here.
> 
> -Dan
> 
> Dan Harkins wrote:
> 
> >   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.
> 
> --------------691F503B140B0774D3B37E21
> Content-Type: text/x-vcard; charset=us-ascii;
>  name="dfox.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Daniel Fox
> Content-Disposition: attachment;
>  filename="dfox.vcf"
> 
> begin:vcard 
> n:Fox;Daniel
> tel;fax:978-263-1099
> tel;work:978-795-5405
> x-mozilla-html:FALSE
> url:http://www.ennovatenetworks.com
> org:Ennovate Networks
> adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA
> version:2.1
> email;internet:dfox@xxxxxxxxxxxxxxxxxxxx
> title:Senior Software Engineer
> fn:Daniel Fox
> end:vcard
> 
> --------------691F503B140B0774D3B37E21--
>