Re: Netscape and Passwords?

Christopher Allen wrote:
> 
> 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/>..


Actually all it means is that we need to support password authentication
whether or not SSL is used for that application -- folks all
applications need to use passwords at some point and will need to do
something irrespective of whether SSL is used or not.

Taher



-- 
Taher Elgamal	    elgamal@netscape.com
Chief Scientist, Netscape Communications
(T) 415 937 2898, (F) 415 428 4054

Received on Tuesday, 26 November 1996 16:17:43 UTC