RE: [Fwd: Shared Key Authentication for the TLS Protocol-- an Alternative]

Phil,

I dont see any underlying formal problem with introducing additional authentication protocols
into an SSL application's framework of security protocols. When DH was introduced into
std SSL mechanisms, it prevented ISO NR, as does any other method of arranging a shared secret,
such as passwords or code books. There mere fact that an authentication service does
not provide ISO NR is not sufficient to deny its use in, or in support of, SSL goals.

Not everyone wants ISO NR; sometimes, they definitely don't want it, eg PFS service. Authenticated
DH and KEA, and other shared secret approaches, when used in a secure manner,  precludes use of a
court to resolve dispute about the contents of an encrypted/integral channel, without particpation
of both parties. One parties decides to hold out, the court is powerless; if the parties
do agree, they must compromise their long term keys to the court. This is no good for Internet countries
where courts are weak, and politically controlled. The weak get trodden on, usually, this means, as they
have no automatic means of recourse to an independent arbitrator. This makes DH and similar schemes
useless for cost-effective and fair commerce.

But, SSL's modern role is not restircted to commerce applications! However, Netsacpe and
Microsoft seemed already to have thought that through, surely!

I would disgaree that its necessary to modify SSL standard (in TLS) to accomplish the
goal which Barb has established. I see SSL's integrity channel as something which
should simply always be there on any TCP frame henceforth. A server
side RSA key is simple to manage, and key management costs are marginal. The
wonder of RSA math means only one side needs keying and substantial improvement
in default end-end channel integrity is provided, always.

To now add authentication exchanges to implement authentication services which
are not standarized by SSL (exploiting whichever cipherSuite) should not require a change
to SSL per se. Any numer of intermediate layers of protocol exchnage can be layered within
the SSL-integrity-protected frames, to implement whatever the parties agree. They
can use the default scalable authentication service provided by SSL which is application
and stack and netweork and vendor and platform indepedent, else use their own proprietary
design, as per NT's proprietary challenge-response mechanism on the web. Exploiting SSL basic
integrity channel is simply a matter of organizing winsock hooks, not fighting over standards to
win market share wars or level playing fields in infrastructure deployment battles.The means
of agreeing the capabilities can be certs, or ISAKMP, or port assignment.

Netscape & Microsoft jointly provided the world with a configurable comms stack via winsock which is
network, and protocol independent. The number of "subnetwork convergence protocols"
which can be layered behing the service access point is arbitary. SSL integrity can come by default atached
to any TCP provider; between the application and SSL can come Microsofts secret key scheme which
can deny application the rights to use SSL native authentication and/or encryption, should the vendor wish.
 
I can no reason to change the standard; rather, such innovations should be encouraged, though
architected to minise thier introduction on the deploying infastructure, and use the flexiblities
of the configurable stack technology. That is, after all why Microsoft introduced its winsock
service-based, highly configurable, comms stack technology with SSL support!

So, yes I agree with the right (and need) to introduce additional authnetication services into the Internet
stack at layer 4 and 5. No I dont agree every (valid) service  option should be lumbered in with SSL, as neither
should it be lumbered in with IPSEC or ISAKMP.

Monolithic systems fail, as do monolithic standards. If there exists an archictectural manner
of providing the feature, then the standard offering has no reason to change, might be the rule.

This very much looks like case of forcing a change to the deployed standard to simply
ensure a different incompatible standard exists. The usual reason is marketing,
and market share wars. 

Peter.
 


----------
From: 	Phil Karlton
Sent: 	Tuesday, October 01, 1996 10:58 AM
To: 	ssl-talk@netscape.com
Subject: 	[Fwd: Shared Key Authentication for the TLS Protocol-- an Alternative]

<<Message: Shared Key Authentication for ...>><<Message: RE: Shared Key Authentication for th...>>
Here are two recent messages to the IETF Transport Layer Security
Working Group. I expect that many on this list may be interested in that
discussion (which should take place on that list, <ietf-tls@w3.org>).
That group is considering using SSL 3.0 as the basis for the TLS effort.

Note that shared secret authentication would have very different
security implications, including any possible ISO non-repudiation
characteristics of an established connection.

PK
--
Philip L. Karlton		karlton@netscape.com
Principal Curmudgeon		http://home.netscape.com/people/karlton
Netscape Communications

    Everything should be made as simple as possible, but not simpler.
	-- Albert Einstein

Received on Tuesday, 1 October 1996 17:20:50 UTC