Short Authentication String Extension for DTLS

Public key cryptography can provide the basis for establishing secure TLS connections, but it requires that each endpoint know the public key of the other endpoint in advance. In some situations, it is not possible to provide authenticated public keys, e.g. due to the lack of a supporting Public Key Infrastructure (PKI) with a root key trusted by both users, but there is an opportunity to use an interaction between human users to provide some authentication of public keys. For example, a user on one end of a connection can read an authentication string displayed to a user on the other end of the connection, who can confirm that it matches the authentication string displayed at the other end of the connection. Another example is as a side channel to authenticate a wireless connection (cf. Because it is awkward for human users to read and verify long sequences of characters, it is important that such a system uses a short authentication string (SAS), for instance, a sequence of four characters, a four-digit identification number, or a keyword selected from a list of 2^16 words. Because the SAS is short, any protocol that relies on SAS authentication must protect against attacks in which an active adversary manipulates the SAS value on one connection so that it matches the SAS value on another connection. This potential attack can be defeated by a commitment scheme; this scheme prevents a would- be attacker from manipulating the SAS value. In this document, we define an extension to the Transport Layer Security (TLS) protocol that provides a way to use an SAS to authenticate a connection. Our method works with the existing X.509 certificate-based authentication in TLS, and it can deliver better security for the case in which one or more self-signed certifcates are used. Additionally, it can be used with normal certificates. These certificates can be cached after a successful SAS verification; thus the SAS mechanism can be used to bootstrap a certificate-based infrastructure. While the security of SAS is less than that of a full PKI, the use of cached SAS-validated certificates supplies better security than self-signed certificates, and the caching of these certificates relieves the human user of the burden of repeatedly performing the manual SAS validation steps. The goals for the SAS method are: To provide a high a level of security as possible; e.g., to detect an active attacker with a failure rate that is not much higher than 1/2^b, where b is the number of bits in the SAS. To work with both x.509 certificate authentication and anonymous Diffie-Hellman. To maintain security even when a certificate or public key is predictable to an adversary; this property enables the use of long-term certificates and long-term public keys without any loss of security. To require only minimal changes to the TLS protocol, and to have minimal impact to TLS implementations. [[NOTE: This mechanism is a strawman. It has seen very minimal review and therefore is likely to change over time.]]

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The SAS is computed as a product of the handshake operations. The basic idea is to have the SAS be unpredictable to the client (before it receives the server's Finished message) and unpredictable to the server (before it receives the message containing the Finished from the client). This prevents either side from forcing the SAS in a particular exchange to a given value. In order to do this, we need to have each side commit to a secret value which is only revealed after the other side has revealed all of the variable material under its control.

The following figure shows the protocol flow with the SAS scheme.

ServerHello + commitment Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* CommitmentReveal [ChangeCipherSpec] Finished --------> CommitmentReveal [ChangeCipherSpec] <-------- Finished Figure 1: Commitment Protocol Flow ]]> Each side generates a random secret value and commits to it in their Hello message. They then reveal it after the other side has transmitted all of their variable data. The SAS computation includes the secret values, thus preventing either side from forcing the SAS to a given value. If we assume that the voice channel over which the SAS is transmitted is secure then the entire handshake can be authenticated.

The SAS mechanism consists of two parts. In the first, the TLS handshake is performed using the new commitment mechanism. In the second, each side computes their SAS value and exchanges it via some unspecified mechanism, though the paradigmatic example is via voice over the negotiated channel as in ZRTP . This section describes the details of these parts.

In the commitment mechanism, each side generates a fresh pseudorandom value X and then transmits a commitment for X, C(X) to the other side. At the end of the handshake, once all variable material from the other side has been received, each side reveals their commitment. The sides then verify that each side has correctly fulfilled their commitment as an additional check on the handshake.

The client requests support for the commitment feature by sending the "commitment" extension in its ClientHello. The "extension_data" field contains a CommitmentValues structure;

; } CommitmentValues; struct { HashType hash_type; opaque hash_value<255>; } CommitmentValue; ]]> In order to generate the CommitmentValue structure the client generates a fresh random opaque value X of length 1..255 (it is RECOMMENDED that this value be at least 80 bits). For each hash function it is willing to support it generates a commitment by computing H(X). For each CommitmentValue, the "hash_type" value contains the identity of the hash and the "hash_value" contains H(X) using that hash. At least SHA-256 MUST be included. If the server is willing to use the commitment feature, it MUST respond with its own "commitment" extension. Otherwise it MUST ignore the extension. It MUST select one of the hashes offered by the client and send only that hash.

The second stage of the commitment mechanism is to reveal the value X which was previously committed to. This is done with a CommitmentReveal handshake message. The CommitmentReveal message is sent right before the Finished message, as shown in Figure 1.

; } CommitmentValue; ]]> The CommitmentReveal contains the value X which was committed to in the "commitment" extension. Recipients MUST verify that the hash value sent in the "commitment" extension sent by the other side, using the hash algorithm selected by the server. If the commitment does not match, a fatal "decrypt_error" MUST be generated and the handshake terminated. The CommitmentReveal message MUST be included in the Finished computation. Thus, the client's Finished does not include the server's CommitmentReveal but the servers includes both.

The SAS computation is computed using the following algorithm.

A k-bit long SAS is computed by taking the leading k bits of the HandshakeSignature value. Therefore an m-bit SAS is a prefix of an n-bit SAS where n>m. A 20-bit SAS is recommended.

SAS values SHOULD be represented using the base32 representation described at: http://en.wikipedia.org/wiki/Base32. [[ TODO: Exactly how to do this is an open issue, but probably we want some sort of base32/base256 encoding, but this is really orthogonal to the crypto issue, which is what this is fundamentally about ]]

The first question to ask is whether this mechanism weakens TLS per se. Fundamentally, it allows one side to inject controlled inputs into the TLS handshake, thus allowing either side to perturb the Finished messages. However, TLS already allowed a substantial amount of variable content (certificates, key exchange messages, etc.,) so this does not appear to introduce new security issues.

The purpose of the commitment mechanism is to ensure that neither side can control the value of the SAS. Because the SAS is based on the entire handshake (via the Finished messages), and this includes a secret value from the server's CommitmentReveal message, the client clearly cannot control the SAS (assuming that the server is using a strong PRNG and that the hash function used is first preimage resistant.) Because the server contributes the final variable value, the server could potentially influence the SAS. However, the required server CommitmentValue depends on the rest of the handshake, including the client's CommitmentValue, which the server does not have at the time when the server generates his own commitment in the "commitment" extension. In order to attack this mechanism, the server would need to be able to generate multiple potential CommitmentValue preimages that matches its commitment. This could be done by generating a number of preimages which all generate the same hash image. Thus, the chosen hash function MUST be collision resistant and 1st and 2nd preimage resistant in order that a recipient cannot infer the commit value from the commitment. See for the design and analysis of a related scheme for proving authentication of a string. This design is informed by similar principles.

An attacker mounting an MITM attack will have the same SAS to both sides with probability 1/(2^k). This will allow him to mount a successful MITM with probability 1/(2^k).

The mechanism described here requires that the SAS be transported in a secure fashion. In at least one application (ZRTP) it has been suggested that the SAS be carried in a voice channel protected by the key exchange. It is not clear that this is in fact a secure mechanism, because voice channels are subject to manipulation of various kinds. This includes "bucket-brigade" style attacks as well as simple voice spoofing. However, this is somewhat out of scope for this extension. SAS should not be used for tying into external automated key management systems. Fingerprints or full-domain MACs should be used. Importantly, the sole motivation for the new protocol machinery defined in this draft is the desire to allow users to read a short authentication string, e.g. one that represents a 25-bit value instead of a 128-bit value.

SAS mechanisms put a significant burden on users, and lack of care on the part of users can significantly raise the chance of success for an attacker.

Thanks.