W3C home > Mailing lists > Public > ietf-tls@w3.org > October to December 1996

Re: Closing on shared-key authentication

From: Jeff Williams <jwkckid1@ix.netcom.com>
Date: Fri, 11 Oct 1996 20:55:35 -0500
Message-Id: <1.5.4.16.19961012015535.2a0f8ae2@popd.ix.netcom.com>
To: marcvh@aventail.com (Marc VanHeyningen)
Cc: ietf-tls@w3.org
At 03:50 PM 10/11/96 -0700, you wrote:
>Eric Murray sed:
>> Marc VanHeyningen writes:
>> > In other words, you're doing password authentication by just sending
>> > the password encrypted, which Tom and I (and I suspect most other
>> > people here) agree is not a very good way to do it.
>> 
>> Why not?
>
>Lots of reasons; I'll mention a few.  
>
>Because ciphers can be broken.  Because some people believe it's
>unhygenic to have the security of authentication be dependent upon
>the security of bulk encryption.

  Ok, but that is still not a really strong argument.  I do see your point
however.
>
>There are also simple usability concerns.  Users occasionally get
>mixed up and, while using service A, accidentally type their
>password for service B.  If you do things your way, you have just
>given service A your password for service B, which is not
>necessarily information you wanted him to have.  If you use a
>challenge-based method, you have given him one specific
>response to one specific challenge, which is of little if any
>value as a tool for impersonating you in the future.

  I would agree that this could be a problem.  But if you have the ability to 
change your password that negates most of the problem here.
>
>Persistent shared secrets shouldn't ever be sent in a reversibly
>encrypted form unless there's no alternative.
  
  Sorry, I don't believe in absolutes.  At present I would agree if possible
you are correct.
>
Reguards,
Jeffrey A. Williams
SR.Internet Network Eng. 
CEO., IEG., INC.,  Representing PDS .Ltd.
Web: http://www.pds-link.com 
Phone: 214-793-7445 (Direct Line)
Director of Network Eng. and Development IEG. INC.
Received on Friday, 11 October 1996 22:19:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:12 UTC