Re: Closing on shared-key authentication


  Please read below your comments,

At 11:06 AM 10/11/96 -0700, you wrote:
>Jeff Williams wrote:
>> At 12:30 PM 10/10/96 -0700, you wrote:
>>> You are quite correct.  However, short term customer requirements for
>>> password authentication can be met by using existing authentication
>>> mechanisms in existing protocols.  There is no need to add a
>>> mechanism to TLS when all existing protocols already have a password
>>> mechanims.
>>   I realize that.  But my concern is not just that we may need to
>> consider adding it to TLS for those customers whom believe in that
>> mechanism, all be it not necessary, possibly.  Again I still believe
>> that a "Common" Protocol interface well featured would go a long ways
>> in solving or addressing some short term problems at teh very least. 
>> Extensions to that interface for enhancments to existiing or possably
>> new protocols, would also project a method of achieving long term
>> desires here.  Don't you think this makes some sense?
>There is already an existing mechanism that allows compatibility between
>versions.  Rather than providing an extension mechanism that will just
>encourage fragmentation of the protocol, I'd rather see us achieve
>consensus on useful features and include them in future revisions.

  Ok, I would agree with this in principal.  This could be fairly easly done
as part of the TLS protocol and still provide for other interfaces that may
be developed in the future.  If that is how you invision feature revisions,
than I would totaly agree.  It really becomes a matter of technique as a
part of development here I think however.
>>> Even if you think we'll be limited to 40-bit for export forever, do
>>> you really believe that any password scheme is going to provide
>>> better than 40 bits worth of security for authentication?  If you can
>>> remember a password with 40 bits of entropy then you have a better
>>> memory than I do.
>>   No of course not.  I couldn't remember much more than 10! ;)  But is
>> it really necessary to remember.  I can be pluged into the login
>> procedure.
>The main distinction I've heard between password authentication and
>public key crypto authentication is that a password can be carried
>in your head.  If you're using a floppy or other hardware token to
>transport your password, why not just use it to transport your private

  Yes this is definatly a acceptable approach.  I would think this could
also be done by pulling it from the CA as well without the need of any
hardware token as well.  Had you thought about that possibility?
>>> As to the lifting of export restrictions, the White House is already
>>> talking about raising the limit to 56 bits, and there is legislation
>>> pending that would lift export restrictions altogether.  I feel very
>>> strongly that an international standard should not be burdened with
>>> major features with such substantial security implications for
>>> reasons of local governmental policy.
>>   56 bits is a total waste of time in my opinion.  It wouldn't take
>> much more than 3 seconds to break that!  Without at least 128 bits
>> being approved for export international companies will not support
>> commerce for long on the net.  In addition, even 128 bit in my humble
>> opinion is a bit short of what I would like to see.
>I agree with you that 56 bits is a very small step, and provides only
>slightly more security than 40.  However, it does indicate that times
>may be changing and we should not view current US export policy as set
>in stone.

  This is still not acceptable in my mind.  I do understand the problems with
US export policy and the concerns with security associated with it.  I have
to believe that we in the industry or private sector need to lead here 
however, not follow.  Without at least 128 bit, we are not really providing
for our own protection in an adaquate manner.
>>   With reguard to what you say reguarding local gov. policy, I am not
>> quite clear as to what you mean here?  Explain please, ok?
>The IETF is an international standards organization.  Should we design
>our protocols to conform to US policy?  French policy?  Japanese policy?
>I think not.  We should design TLS to be as secure as possible.

  Exactly!  I think that we need to get input from all nations and ask for and
include their input as a intragle part of design.  That is however where it
a bit tricky.  I think that possibly a "Joint Lab" for just such a process needs
some thought here.  What do you think?  That way providing for all nations
concerns will be addressed and TLS would evolve into being as secure as 


>You should only break rules of style if you can    | Tom Weinstein
>coherently explain what you gain by so doing.      |
Jeffrey A. Williams
SR.Internet Network Eng. 
CEO., IEG., INC.,  Representing PDS .Ltd.
Phone: 214-793-7445 (Direct Line)
Director of Network Eng. and Development IEG. INC.

Received on Friday, 11 October 1996 16:51:48 UTC