- From: David P. Kemp <dpkemp@missi.ncsc.mil>
- Date: Thu, 10 Oct 1996 12:38:43 -0400
- To: ietf-tls@w3.org
> 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