RE: Repost of CompuServe Position on Passphrases

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)

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?

thanks
Keith
-----------------------------------------
Keith Ball                   Internet mail:  Keith_Ball@novell.com
Building 1                  GroupWise mail:  Keith Ball
2180 Fortune Drive
San Jose Fortune  (sjf.novell.com)
Mailstop: F1-42-2D
voice: (408) 577 8428
Fax:   (408) 577 5855

Novell, Inc.

-- sent via the Novell GroupWise

Received on Friday, 26 July 1996 18:50:02 UTC