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

Dan Simon wrote:
> 
> >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
> >
> >
> >
> >
> >
unsubscribe

Received on Thursday, 3 October 1996 17:02:36 UTC