- From: Tom Stephens <tomste@microsoft.com>
- Date: Mon, 30 Sep 1996 22:40:58 -0700
- To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
- Cc: Barb Fox <bfox@microsoft.com>
In the Introduction section of Barb Fox's 9/30/96 posting, there is a
reference to the original Shared Key Authentication for the TLS Protocol
document. For the those of you who may not seen this document before, I
have included it below along with Barb's 9/30/96 posting.
Shared Key Authentication for the TLS Protocol - Original
1. Introduction: Why Shared Key Authentication?
Recent transport-layer security protocols for the Internet, such as SSL
versions 2.0 and 3.0 [1, 2] and PCT version 1 [3], have effected
challenge-response authentication using strictly public-key (asymmetric)
cryptographic methods, with no use of out-of-band shared secrets. This
choice has both benefits and drawbacks. The primary benefit is improved
security: an asymmetric private key used for authentication is only
stored in one location, and the out-of-band identification necessary for
public key certification need only be reliable, not secret (as an out-
of-band shared key exchange must be). In addition, the difficult task
of out-of-band shared-key exchange in shared-key authentication systems
often leads implementers to resort to human-friendly shared keys
(manually typed passwords, for instance), which may be vulnerable to
discovery by brute force search or "social engineering".
However, shared-key authentication has certain advantages as well.
These are, chiefly:
- Portability: Precisely because shared keys are often human-remembered
passwords or passphrases, they can be transported from (trusted) machine
to (trusted) machine with ease--unlike asymmetric private keys, which
must be transported using some physical medium, such as a diskette or
"smart card", to be available for use on any machine.
- Backward Compatibility: Shared-key authentication is in very wide use
today, and the cost of conversion to its public-key counterpart may not
be worth the extra security, to some installations.
- Established Practice: Shared-key authentication has been in use for
quite a while, and a valuable body of tools, techniques and expertise
has grown up around it. In contrast, public-key authentication is very
new, its associated tools and methods are either untested or non-
existent, and experience with possible implementation or operation
pitfalls simply doesn't exist.
These reasons are particularly relevant when individual human users of a
service are being authenticated over the Internet, and as a result,
virtually all authentication of (human) clients of such services is
currently performed using shared passwords. Typically, servers
implementing one of the aforementioned transport-layer security
protocols, and needing client authentication, simply accept secure
(i.e., encrypted and server-authenticated) connections from each client,
who then provides a password (or engages in a challenge-response
authentication protocol based on a password) over the secure connection
to authenticate to the server.
Unfortunately, such "secure" connections are often not secure enough to
protect passwords, because of the various international legal
restrictions that have been placed on the use of encryption. Obviously,
secret keys such as passwords should not be sent over weakly encrypted
connections. In fact, even a challenge-response protocol which never
reveals the password is vulnerable, if a poorly chosen, guessable
password is used; an attacker can obtain the (weakly protected)
transcript of the challenge-response protocol, then attempt to guess the
password, verifying each guess against the transcript.
However, it is possible to protect even badly-chosen passwords against
such attacks by incorporating shared-key authentication into the
transport-layer security protocol itself. These protocols already
involve the exchange of long keys for message authentication, and those
same keys can be used (without the legal restraints associated with
encryption) to provide very strong protection for shared-key-based
challenge-response authentications, provided that the mechanism used
cannot be diverted for use as a strong encryption method. This latter
requirement makes it essential that the shared-key-based authentication
occur at the protocol level, rather than above it (as is normally the
case today), so that the implementation can carefully control use of the
long authentication key.
2. Objections
The primary objection raised against the inclusion of shared-key
authentication in transport-layer security protocols is the resulting
degradation in security. However, it is not the place of the protocol
to force such decisions on its users. In practice, if shared-key
authentication is not included in the protocol, then users intent on
using it (for any of the reasons described above) will simply continue
to use it as they do today--that is, less securely than if it were
incorporated into the protocol.
Nor does the presence of shared-key authentication in the protocol have
the slightest effect on those who do not wish to use it. Shared-key
authentication requires the prior agreement of both parties; any client
or server who does not trust it has the option of refusing to take part
in the necessary out-of-band exchange of a shared key. There is then no
danger of any such party being "fooled" into engaging in a shared-key
authentication protocol, since no shared key will be available.
Finally, it has been suggested that the inclusion of shared-key
authentication in the TLS protocol will discourage migration to public-
key authentication methods. This concern is unrealistic; in fact, by
providing a smoother upgrade path, shared-key authentication in TLS will
likely expedite the transition to public-key authentication in many
cases. Without it, servers that are unready for public-key client
authentication will have to keep their client authentication mechanism
one layer above the transport layer, as they typically do now. However,
once they have been lured (by the promise of improved security) into the
less traumatic step of placing their shared-key authentication at the
transport layer, the transition to public-key authentication will be
that much easier.
3. Proposed Protocol Additions
Starting from SSL version 3.0 notation and formats, the following new
ClientCertificateType values (in the certificate request message) would
be added:
shared_key_standard(40), shared_key_private(41)
The certificate_authorities list in the certificate request message
would be permitted to include, in addition to certificate authority
distinguished names, distinguished names of shared-key authentication
services by which the client can authenticate. (For example, the client
may share several keys with the server, associated with identities on
different systems residing on the same server.)
A new HandshakeType would also be defined, and included in the Handshake
message definition:
shared_key_verify(17)
The shared_key_verify message would have the following structure:
struct {
DistinguishedName authentication_service;
opaque identity<1..65535>;
opaque shared_key_response<1..255>;
} SharedKeyVerify;
The value of authentication_service would be required to be selected
from those included in certificate_request.certificate_authorities. The
format of the identity field would be left to the implementation, and
should be inferable from the accompanying value of
authentication_service. In the case of ClientCertificateType
shared_key_private, this would also be true of the format of
shared_key_response. In the case of ClientCertificateType
shared_key_standard, the value of shared_key_response would be defined
as
SharedKeyVerify.shared_key_response
hash (auth_write_secret + pad_2 +
hash (handshake_messages + MAC_write_secret +
SharedKeyVerify.identity + pad1) )
xor hash (client_hello.random + identity + shared_key +
server_hello.random)
Here "+" denotes concatenation and "xor" denotes bitwise exclusive-or.
The hash function used (hash) would be taken from the pending cipher
spec. The client_auth_write_secret and server_auth_write_secret values
would be obtained by extending the key_block by twice
CipherSpec.hash_size bytes beyond the server_write_key (or the
server_write_IV, if it is derived from key_block as well), and using the
first and second halves of this extended portion as the
client_auth_write_secret and server_auth_write_secret values,
respectively. The value of handshake_messages would be the
concatenation of all handshake messages from the first one sent up to
(but not including) the shared_key_verify message. The two "random"
values would be taken from the client hello and server hello handshake
messages. The pad1 and pad2 values correspond to the ones used for MAC
computation in the application_data message.
4. Normal Authentication
A shared-key-based client authentication would proceed as follows: the
server sends a certificate request handshake message, just as it would
in the case of public-key-based client authentication; however, the
specified ClientCertificateType is either shared_key_standard or
shared_key_private. The accompanying list of certificate authorities
includes the Distinguished Name of one or more authentication services;
the client selects one of these and constructs the appropriate
authentication response, sending it back, along with its identity and
choice of authentication service, in a shared key verify handshake
message. If the certificate request message specified
ClientCertificateType shared_key_standard, then the authentication
response in the certificate verify message would be constructed as
described above; otherwise, the response's construction would be
dictated by the choice of authentication service.
The server would also itself construct the correct authentication
response using the known shared key, and check it against the one
provided by the client. The authentication would be successful if the
two matched exactly. Note that if the shared key is password-based,
then it would typically be derived from the password using a one-way
cryptographic hash function, rather than being the password itself, so
that the original password need not be remembered by anyone but the
client.
5. Pass-through Authentication
In some circumstances, it is preferable for shared keys to be stored in
one place (a central, well-protected site, for instance) while servers
that actually communicate with clients are elsewhere (possibly widely
distributed, but maintaining secure connections to the central shared-
key server). One of the advantages of the shared-key authentication
method proposed here is that it allows "pass-through" authentication by
a third party, if the server accepting the public-key key exchange and
the server sharing the key with the client happen to be different. (The
somewhat odd-looking exclusive-or of two hashes in the response
computation makes this possible.)
Pass-through authentication might work as follows: the client's hello
message would be accompanied by a list of one or more shared-key
authentication services with which it shares a key. (The TLS working
group is already considering giving the client the capability of
specifying its preferred certificate types and authorities, matching the
server's ability to do so in the SSL v3.0 certificate request message;
Distinguished Names of authentication services could then be included in
the client's list of CAs.) The service could then choose one of the
client's preferred authentication services and request a random
challenge from it, using that challenge as (or incorporating it into)
the random value in the server's hello message. The server's
certificate request message would then specify that authentication
service in its list of certificate authorities, thus indicating the
appropriate authentication method (in the case of ClientCertificateType
shared_key_private). The client would then compute the correct
authentication response, using the above proposed method (in the case of
ClientCertificateType shared_key_standard) or a method specific to the
authentication service (in the case of ClientCertificateType
shared_key_private). This response would be sent in the shared key
verify message, replacing the certificate verify message sent when a
public-key client authentication response is called for.
Note that the authentication response is the form of a bitwise
exclusive-or of two "pieces", and therefore that given one piece plus
the entire (correct) response, one can recover the other piece. Thus
the server, on receiving a response from a client, can compute the first
piece of the correct response (the piece that doesn't depend on the
shared key), and exclusive-or it with the client's actual response to
obtain the client's version of the response's second piece. This second
piece (hashed once more, for good measure), together with the client's
random challenge and identity and server's random challenge, can be sent
on to the authentication service for verification.
References
[1] K. Hickman and T. Elgamal, "The SSL Protocol", Internet Draft
<draft-hickman-netscape-ssl-01.txt> (deleted), February 1995.
[2] A. Freier, P. Karlton and P. Kocher, "The SSL Protocol Version
3.0", Internet Draft <draft-freier-ssl-version3-01.txt>, March 1996.
[3] J. Benaloh, B. Lampson, D. Simon, T. Spies and B. Yee, The PCT
Protocol", Internet Draft <draft-benaloh-pct-00.txt>, November 1995.
>----------
>From: Barb Fox
>Sent: Monday, September 30, 1996 7:19 PM
>To: 'ietf-tls@w3.org'
>Subject: Shared Key Authentication for the TLS Protocol-- an Alternative
>
>Shared Key Authentication for the TLS Protocol--an Alternative
>
>1. Introduction
>
>This document presents an alternative to the shared-key authentication
>mechanism proposed for the TLS protocol on the IETF TLS mailing list in
>late July 1996. This alternative mechanism accomplishes the same goals
>(including enabling three-party "pass-through" authentication) in a
>slightly more straightforward manner. A discussion of the arguments for
>and against the inclusion of shared-key authentication in the TLS
>protocol can be found in that original shared-key authentication
>document.
>
>
>2. Summary of Changes From the Previous Proposal
>
>In the previous proposal, a key derived from the master key and several
>other inputs was used in a stream-cipher-like manner to protect a
>shared-key authentication response from eavesdroppers. In this
>proposal, a separate secret, called an authentication secret, is derived
>directly from the master secret and incorporated into the authentication
>response. Thus in the case of pass-through authentication, the server
>must pass not only the authentication response but also this
>authentication secret to the authentication service verifying the
>response.
>
>The previous proposal also reused the CertificateRequest handshake
>message for shared-key authentication requests. In the new proposal,
>all shared-key-related data is contained in new handshake messages
>(implementations that support the proposed changes can thus be made to
>interoperate with implementations that do not, but ignore invalid
>handshake messages). Also, a "private" shared-key authentication
>response format, originally proposed to allow arbitrary authentication
>response formats between co-operating clients and servers, has been
>removed from this proposal. Since the response field is in any event
>opaque, implementations of an alternative shared-key authentication
>format for a particular authentication service can simply have clients
>detect the specific authentication service, and construct their
>authentication responses accordingly.
>
>Finally, extra challenge and display string fields have been associated
>with each authentication service name provided by the server, the former
>to facilitate pass-through authentication with service-supplied
>challenges, and the latter to help the implementation to identify the
>authentication service to the user.
>
>
>2. Proposed Protocol Additions
>
>Starting from SSL version 3.0 notation and formats, the following two
>new HandshakeTypes would would be added, and included in the Handshake
>message definition:
>
>shared_key_request(31), shared_key_verify(32)
>
>The SharedKeyRequest message would have the following structure:
>
>struct { DistinguishedName auth_service_name;
> opaque display_string<0..65535>;
> opaque challenge<0..255>;
>} AuthService;
>
>struct {
> AuthService auth_services_server<1..65535>;
>} SharedKeyRequest;
>
>This optional message would be sent immediately following the server's
>first set of consecutive messsages, which includes the ServerHello and
>(possibly) the Certificate, CertificateRequest and ServerKeyExchange
>messages. The auth_services_server field would contain a list of
>distinguished names of shared-key authentication services by which the
>client can authenticate. The challenge field accompanying each
>authentication service name would contain an optional extra
>authentication challenge, in case the server needs to obtain one from an
>authentication service for pass-through authentication. If none is
>required, then it would simply be an empty (zero-length) field.
>Similarly, the display_string field could contain an extra field to be
>displayed to the user during authentication, if needed.
>
>The SharedKeyVerify message would be sent in response to a
>SharedKeyRequest message from the server, and would have the following
>structure:
>
>struct {
> AuthService auth_service;
> opaque identity<1..65535>;
> opaque shared_key_response<1..255>;
>} SharedKeyVerify;
>
>The value of auth_service would be required to be selected from the list
>in SharedKeyRequest.auth_services_server. The format of the identity
>field would be left to the implementation, and should be inferable from
>the accompanying value of auth_service. The value of
>shared_key_response would be defined as
>
>SharedKeyVerify.shared_key_response
> hash (auth_write_secret + pad_2 +
> hash (auth_write_secret + pad_1 + hash (handshake_messages)
>
> + SharedKeyVerify.auth_service.auth_service_name
> + SharedKeyVerify.auth_service.display_string
> + SharedKeyVerify.auth_service.challenge
> + SharedKeyVerify.identity + shared_key) )
>
>Here "+" denotes concatenation. The hash function used (hash) would be
>taken from the pending cipher spec. The client_auth_write_secret and
>server_auth_write_secret values would be obtained by extending the
>key_block by CipherSpec.hash_size bytes beyond the server_write_key (or
>the server_write_IV, if it is derived from key_block as well), and using
>this extended portion as the client_auth_write_secret value. The value
>of handshake_messages would be the concatenation of all handshake
>messages from the first one sent up to (but not including) the
>shared_key_verify message. The pad1 and pad2 values correspond to the
>ones used for MAC computation in the application_data message. The
>fields from the SharedKeyVerify message would be input with their length
>prefixes included.
>
>
>3. Normal Authentication
>
>A shared-key-based client authentication would proceed as follows: the
>server would send a SharedKeyRequest handshake message containing a list
>of names of one or more authentication services. The client, on
>receiving the SharedKeyRequest message, would select an authentication
>service from the server's list and construct the appropriate
>authentication response as described above, sending it back, along with
>its identity and choice of authentication service, in a SharedKeyVerify
>handshake message. The server would also itself construct the correct
>authentication response using the known shared key, and check it against
>the one provided by the client. The authentication would be successful
>if the two matched exactly. Note that if the shared key is password-
>based, then it would typically be derived from the password using a one-
>way cryptographic hash function, rather than being the password itself,
>so that the original password need not be remembered by anyone but the
>client.
>
>
>4. Pass-through Authentication
>
>In some circumstances, it is preferable for shared keys to be stored in
>one place (a central, well-protected site, for instance) while servers
>that actually communicate with clients are elsewhere (possibly widely
>distributed, but maintaining secure connections to the central shared-
>key server). One of the advantages of the shared-key authentication
>method proposed here is that it allows "pass-through" authentication by
>a third party, if the server accepting the public-key key exchange and
>the server sharing the key with the client happen to be different. (The
>use of a separately derived authentication key in the response
>computation makes this possible.)
>
>Pass-through authentication might work as follows: The server would
>either collect random challenges in advance from its authentication
>services, or request them as needed. The server would then send a list
>of authentication services and associated challenges in a
>SharedKeyRequest message. The client would then select an
>authentication service (if more than one is offered), compute the
>correct authentication response using the above proposed formula, and
>send it to the server in a SharedKeyVerify message.
>
>The server, on receiving a response from a client, would pass it through
>to the authentication service, along with the values necessary to
>recalculate it: the client_auth_write_key, the hash of all the
>handshake messages and the identity field from the certificate verify
>message. The authentication service would then use the values provided,
>along with the secret key it shares with the client and the challenge it
>supplied, to reconstruct the correct value of the response. If this
>value exactly matches the one provided by the server, then the
>authentication would succeed; otherwise it would fail.
>
>
>5. Addendum--The SharedKeys Message
>
>In cases where pass-through authentication is used, it would be useful
>for clients to be able to notify servers in advance of one or more
>authentication services sharing a key with the client, so that the
>server need only fetch (or use up) a challenge from a single service for
>that client. An additional optional message accompanying the
>ClientHello would accomplish that purpose. It is proposed here for
>consideration, with the following HandshakeType:
>
>shared_keys(30)
>
>The SharedKeys message would have the following structure:
>
>struct {
> DistinguishedName auth_services_client<1..65535>;
>} SharedKeys;
>
>This optional message would be sent immediately following the
>ClientHello message, and would contain a list of distinguished names of
>authentication services to which the client is willing to authenticate.
>This message could also be useful in non-pass-through situations; for
>example, the client may share several keys with the server, associated
>with identities on different systems (corresponding to different
>``authentication services'' residing on the same server). If a server
>receives a SharedKeys message, then any subsequent SharedKeyRequest
>message could contain a single authentication service selected from the
>client's list.
>
>Note that sending a SharedKeys message does not in itself normally
>reveal significant information about the client's as-yet-unspecified
>identity or identities. However, if information about the set of
>authentication services supported by a particular client is at all
>sensitive, then the client should not send this message.
>
>Barbara Fox
>bfox@microsoft.com
>
Received on Tuesday, 1 October 1996 01:41:11 UTC