W3C home > Mailing lists > Public > ietf-tls@w3.org > July to September 1996

RE: Repost of CompuServe Position on Passphrases

From: Dan Simon <dansimon@microsoft.com>
Date: Wed, 31 Jul 1996 19:05:15 -0700
Message-ID: <c=US%a=_%p=msft%l=RED-92-MSG-960801020515Z-7373@tide21.microsoft.com>
To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'Keith Ball'" <Keith_Ball@novell.com>
>
>From: 	Keith Ball[SMTP:Keith_Ball@novell.com]
>
>I dont see a resolution coming out of this discussion, at least not in the
>form of
>general consensus.  The issues for password seem to be based on technical
>strength versus business need.  I dont see how these two can be resolved.
>
>Issues:
>Against:
>1) scalability: the user's ability to remember a different password for every
>service
>and that that simply doesn't scale because a person has a finite number of
>things
>that he can remember.
>2) symmetric: both sides must know the secret.
>3) dictionary attack possible if use human-simple passphrase (even though can
>reduce this if require multiple words and non-alpha characters, e.g.
>1toad$frog2,
>and the same format is not required on all passphrases)

An important technical point:  this is *not* the case if
passphrase-based authentication is integrated properly into TLS, with
the authentication response properly protected by strong encryption.  
>
>For:
>1) simple to understand, use, and manage
>2) portable
>3) legacy
>
>How is the working group going to select if cant get consensus?  Will the
>chair
>force closure? 
>
>Has anyone tried a compromise?  How about making it so additional
>authentication methods could be added to the handshake protocol.  If the
>protocol
>was further modularized so completely different authentication mechanisms
>that
>did not follow the SSL 3.0 style key exchange could be plugged in, then the
>password scheme could be added later in another RFC or as an appendix to the
>basic TLS RFC.
>
>The idea is to further structure the handshake protocol in SSL 3 so a clear
>box is
>drawn around authentication.  The input parameters to the box and the output
>parameters from the box need to be clearly defined.  The output parameters
>would
>allow the protocol as defined after the key exchange to continue on, such as
>the
>Finished message.  Within the box, depending on the authentication method
>selected in the negotiation, the sequence of packet exchanges could be
>different:
>specific to the authentication mechanism.  A class of authentication
>mechanisms
>that use the same packet exchange sequence are already defined in SSL (rsa,
>diffie_hellman, fortezza_dms).  Another case would be the passphrase
>authentication method, or methods of the same class that would use the same
>set
>of packet exchanges.
>
>I am also interested in being able to add other existing authenication
>mechanisms
>to this, such as Novell's NetWare 4 authentication.  The ability to have a
>broader
>collection of authentication mechanisms, the certificate/key exchanges, the
>pass
>phrase mechanisms, and the existing NetWare 4 mechanism what meet our
>business needs more 
>
>The alternate authentication methods all do not need to be defined up front,
>but a
>method for adding them in without breaking existing implementations would be
>necessary. Perhaps the only way to ensure this is by allowing the algorithms
>to
>be negotiated separately rather than negotiating a "crypto suite."   This
>would
>allow more flexibility in adding new protocols as they are developed.  Are
>there any
>plans to do this?

There is an implicit trade-off here between two goals:  the need to
establish a single standard and avoid interoperability problems, and the
need to accommodate alternate authentication methods, particularly in
the shared-key case, where adaptations of legacy systems might be
desirable.  (I suspect that a single public-key authentication standard
should be sufficient, since public-key-based client authentication
hasn't been widespread enough to engender numerous incompatible
variations.)  I don't think it would be a good idea to create a fancy
negotiation of shared-key authentication protocols, because the possible
variations are virtually endless, even if only protocols in current use
are taken into account.

On the other hand, shared-key authentication protocols have the common
characteristic of requiring previous agreement on a key before the
authentication can take place.  Assuming, then, that this agreement also
involves agreement on an authentication protocol, the choice of protocol
can be implicitly negotiated through the "certifier" negotiation that
already takes place in SSL (and presumably TLS as well).  In the shared
key case, the "certifier" would simply be the identity (distinguished
name) of the other possessor of the client's shared key.    

What I proposed in a brief after-meeting presentation at the Montreal
IETF meeting was that shared-key authentication come in two flavors,
"standard" and "private".  The "standard" variety would follow a
particular protocol specified by TLS, while the "private" variety would
be unconstrained, and assumed to be previously agreed upon by client and
certifier.  The choice of certifier/authentication service would be
negotiated just as the CA is currently negotiated in SSL public-key
client authentication.  

I believe that this design is an optimal compromise between the goals of
interoperability and flexibility, and moreover dispenses with the need
for yet another official list, this time of registered valid
authentication protocols.  


				Daniel Simon
				Cryptographer, Microsoft Corp.
				dansimon@microsoft.com


>
>
Received on Wednesday, 31 July 1996 22:05:31 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:50 EDT