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

>Peter:  you seem to be conflating two different distinctions--the distinction
>between socket-level and application level access control, on the one hand,
>and the distinction between public-key-based and shared-key-based
>authentication on the other.  I agree one hundred percent that incorporating
>client authentication into SSL/TLS makes system-level access control
>possible, and that that is a good thing.  I simply don't agree with your
>apparent claim that such access control must necessarily be based on
>public-key authentication; on the contrary, I expect it that when it occurs,
>it will often be shared-key-based, for any number of reasons.  Hence the
>necessity for TLS to have a shared-key authentication feature.  
>
>Regarding some of the other points you raised:
>
>From: 	Peter Williams[SMTP:peter@verisign.com]
>
>Any alternative *SSL* authentication service must be performable within the
>handshake, and
>not require encryption.The only real reason to invest in a new mechanism
>is because a some new interesting class of cipher exists which needs some
>help
>in the handshake messages so as to expoit its authentication properties. (SSL
>multicast authentication I believe will be a case in point, one day)
>
>For example, if I used a TYPE I algoirhtm which matched RSA properties,
>I would not expect to change SSL except to introduce a new cipherSuite.
>If I used Type II KEA which is related to DH, I would not expect to change
>SSL;
>rather, Id just introduce a new cipherSuite. If we use Elliptic,
>Curves, again there is nothing new in any of these algoirhtms which changes
>SSL.
>
>I dont believe TLS should allow any encryption, other than via public key
>exchange,
>during the handshake. 
>
>In fact, under the proposed shared-key authentication extension, it does not.
> The strong protection of the shared-key authentication response is effected
>using a keyed cryptographic hash, not encryption.
>
>Why cannot we merely register a cipherSuite whose semantics are: do strong
>encrytion
>for the first n bytes of user data; having performed a handshake. The server
>must then authenticate
>the n bytes of shared-secret authentication from the user-stream, and perform
>a new handshake if
>it accepts the access control policy.  The server may choose to require
>client authentication,
>and mandatory access control estbalishment upon completeion of the first
>handshake, if
>thats its policy.
>
>Exactly the same argument could apply to public-key client authentication as
>well; however, we (hopefully) all agree that a single public-key client
>authentication standard embedded into TLS vastly improves its
>interoperability and allows application-independent security decisions to be
>made about clients.  Similarly, your proposal does not address the
>interoperability problem with respect to shared-key authentication, nor the
>application-independent control of sockets.  Moreover, under this proposal,
>any socket-level implementation of TLS would likely run into export problems,
>since it would have to ship some amount of uncontrolled data across the
>channel using strong encryption. 
>
>
>				Daniel Simon
>				Cryptographer, Microsoft Corp.
>				dansimon@microsoft.com
>
>
>
>
>

Received on Thursday, 3 October 1996 01:28:48 UTC