[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxx
Chief Scientist, Netscape Communications
(T) 415 937 2898, (F) 415 428 4054