Re: Netscape and Passwords?

At 1:29 PM -0800 11/25/96, John Macko wrote:
>I happened across the following quote from the Technology Preview of
>Constellation  - Netscape's new netcasting and desktop-customization
>technology.
>
>"Constellation will allow you to access your HomePort from any location
>or any computer. You no longer need to be tied to your desktop to be
>productive. For example, when traveling between home and work or between
>multiple offices, you can enter your ***user name and password*** for
>your HomePort and work with all of your information, just as you left
>it, regardless of where you are or what type of computer you are
>running. "
>
>Given the reluctance of Netscape to support Passwords in the TLS
>protocol, I am a bit curious as to the underlying technology Netscape
>will be using for  password based authentication to your "HomePort."
>
>Does anyone have any insight into this?

I don't think that Netscape has objections to supporting passwords --
instead I think the various point of views on password authentication have
more to do with different ideas on the appropriate layer in the networking
model to add authentication.

Ultimately the problem resides in the fact that the technology that we are
using to secure the integrity of a connection (i.e. the rsa or
diffie-helman key exchange to derive a shared master secret for encryption)
is closely related to the technology that we use to authenticate each end
of the connection (i.e. RSA or DSS certificates.)

I believe that Microsoft's position is that since SSL offers authentication
(through the use of certificates) that other forms of authentication should
be done at that layer as well.

In contrast, Netscape's position appears to be that certificate-based
authentication is fundementally different (and believed to be more secure)
than password based authentication, thus it doesn't deserve to be at the
same level.

Others have objections to SSL for architectural reasons -- they say that
SSL should not be doing authentication at all, and/or that it should rely
on other protocols or layers for key exchange and authentication.

I'm not sure how this will all pan out. There is a legitimate user need for
standardizing non-certificate based authentication (whether secret-key for
legacy purposes, kerberos, or some other authentication mechanism) yet it
there is also a legitimate concern regarding both architecture issues
(layering) and the differing levels of security offered by different
authentication schemes.

So far there are two internet drafts relating to alternative authentication
methods for TLS:
<ftp://ds.internic.net/internet-drafts/draft-ietf-tls-passauth-00.txt>
<ftp://ds.internic.net/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
>

I have heard that there may even be two more internet-drafts submitted on
this issue by tomorrow's deadline!

Obviously this will be an important issue to resolve for the future of TLS,
however, I do hope that this issue doesn't get in the way of moving SSL 3.0
under IETF change control. That goal is my personal objective.

------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<ChristopherA@consensus.com>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..

Received on Monday, 25 November 1996 18:02:45 UTC