Re: Closing on shared-key authentication -Reply

> From: John Gardiner Myers <jgm@CMU.EDU>
> 
> But, as has been pointed out, the issue of separating application
> layer and transport layer issues is irrelevant to the proposal.  If it
> is in fact an issue of separating out authentication as being an
> application layer issue, then the public-key authentication facilities
> of TLS should be removed on the grounds that they are also in the
> wrong layer.
> 
> Shared-key authentication is not fundamentally different from a
> layering standpoint than any other authentication technology.  Any
> layer in which it is appropriate to put in a public-key authentication
> system it is also technically appropriate to put in a shared-key
> authentication system.  


Perhaps on some other planet.

But in the real world, public-key authentication scales to a global
level whereas shared-secrets are limited to specific communities of
interest.  The first round of S/WAN (IPsec) testing used shared-secret
authentication (i.e. manual keying).  The next round will use both
proposed forms of automated key management (SKIP and ISAKMP, both of
which are public-key based).  Most people would agree that for universal
deployment, automatic is better than manual.

It is also true that everybody and his brother is trying to get into
the Public Key Infrastructure (PKI) business, whereas I haven't heard
of any companies trying to be the first to set up a global-scale
symmetric KDC business.

So what does all that have to do with TLS?  It means that if you
confine yourself to the Transport Layer, authentication can be done
automatically, because the manual labor has already been done by the
Verisigns/GTEs/Nortels/etc of the world.  When you make a connection to
www.nytimes.com, you know you're there because somebody has taken the
effort to bind that name with their key.  If you wanted to do the same
with symmetric-key authentication, you'd have to do manual distribution
of the key because, in general (for an arbitrary entity anywhere in the
world), no one is in the business of providing symmetric key
management services.

Sure, BOTH symmetric and public key authentication can be done at the
application layer, but public key is the ONLY method that can be done
automatically at the transport layer.  The shared-key authentication
proposal currently on the table recognizes that fact - it uses the
public-key authenticated channel established by TLS, and provides a
special-purpose path through that channel for shared-key authentication
that cannot be used to encrypt general user data.  The proposal already
requires application-layer support - in fact if the API is not called
(from an application, of course), the extra handshake messages are
never generated.

A dummy application (one that is completely security-unaware) can open
a socket, send some data, and close it.  TLS provides security to that
connection using public-key authentication with *no* help from the
application.  TLS (either following the specific proposal, or using any
conceivable alternative) could NOT perform the same function using symmetric
key authentication.

It is not clear to me why the identical shared-secret authentication API,
with identical semantics, could not be layered on top of the TLS protocol
without any modifications to the protocol itself.  If I were in the
business of developing products for customers, that's how I'd do it,
and skip the holy wars.  After all, the customer need (as expressed by
Compuserve et al) is for *application* access to authentication information.
That information could be a client cert, which is available for free
as a byproduct of the TLS channel establishment, or it could be a secret,
which would have to be sent from an application at the client end to
an application at the server end.  I haven't heard any customers saying
they needed shared-key authentication provided automatically, by the
transport layer, for security-unaware apps.


> jgm: Authentication is authentication.

"In theory, there's no difference between theory and practice.
 In practice, there is."

Received on Thursday, 10 October 1996 12:45:08 UTC