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

Dan,
 
SSL embodies two peer-entity authentication mechanisms todate, which exploit
the properties of the ciphers classes (RSA and DH) upon which they depend. Both require
that they are part of SSL's handshake. By design, **NO** SSL data is encrypted
or explicitly integrity protected prior to the completion of SSL handshake. One
cannot expect a trusted site to export sensitive data via an single level
(or multi level!) encryption device until the peer-entity authentication  has
completed. Peer entity authentication (w/ client auth and RSA) can establish the
complete access control policy for the channel (by exchanging each sides labels), and
therefore client authentication must occur proir to any user-data exchange.

Complete SSL public key authentication must occur within the handshake, or
SSL's flexiblity to support mandatory access control is weakened/eliminated.
The service seeks to implement I.3.2.2.1 of the TNI to TCSEC, while recognising
that  - with TCP transports - the connection has already been
established to some degree prioir to SSL being engaged, and is consuming
resources. So SSL implements TNI connection control, loosely.

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. 

Should TLS services (with more advanced handshaking) allow for selective "sub-stream"
encryption, to support various access control policies within the user-data stream.
I.E. the socket service will arrange shared access to data of type 1, not not control access to
type 2, by agreeing multiple MEKs and security contexts?

Im not so arrogant as to deny the general utility of such a sub-stream access control
enforcement policy. However, the architectural difference between this
and what SSL was designed to do is so large that I would not
introduce such facilities on the basis of enabling an additional authenticaiton
procedure which demand such capabilities of the data stream, because of its
vulnerabilities.

SSL protects the socket - or service access point. The SSL protodol should not
conventionally be knowing what sensitivity of various user data is present through the channel. It
is designed to simply agree the security services TSAP to TSAP, and then apply
the relevant mechanisms stupidly (but safely). The application is in control
of the security context, and its reasons for any change, for privacy reasons.

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.

Peter.




From Dan:

Similarly, public-key-based client authentication does not have to be in
SSL/TLS either, since it could easily be layered on top of it.  An
advantage of incorporating it into the protocol is, as Peter points out,
interoperability.  Exactly the same argument applies in the case of
shared-key-based authentication; a single, non-proprietary
shared-key-based authentication standard embedded in TLS (which is what
our proposal provides) allows independent client-builders and
server-builders to implement shared-key authentication interoperably. 

There is another justification for this incorporation in the case of
shared-key authentication that does not apply in the case of public-key
authentication:  if for any reason the channel used is not strongly
encrypted, and the shared key being used for authentication is guessable
(as is often the case for user-remembered passwords), then any fully
layered solution will be vulnerable to brute-force offline attacks.
Incorporating the authentication protocol into TLS allows a special
exception to be made for the authentication data, strongly protecting it
even if the normal traffic is not strongly encrypted.


				Daniel Simon
				Cryptographer, Microsoft Corp.
				dansimon@microsoft.com




>

Received on Tuesday, 1 October 1996 20:37:44 UTC