Re: Closing on shared-key authentication -Reply

David,

  I think that automation across the board will soon be a requirnment.
Maybe not
now in all cases but soon.  Again I think that a standard interface would be 
a much better approach here.

Reguards,


At 12:38 PM 10/10/96 -0400, you wrote:
>> 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."
>
>
>
Jeffrey A. Williams
SR.Internet Network Eng. 
CEO., IEG., INC.,  Representing PDS .Ltd.
Web: http://www.pds-link.com 
Phone: 214-793-7445 (Direct Line)
Director of Network Eng. and Development IEG. INC.

Received on Thursday, 10 October 1996 14:09:25 UTC