idnits 2.17.1 draft-miers-tls-sas-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 147, but not defined -- Looks like a reference, but probably isn't: '64' on line 168 ** Obsolete normative reference: RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Miers 3 Internet-Draft M. Green 4 Intended status: Standards Track Johns Hopkins University 5 Expires: August 18, 2014 E. Rescorla 6 Mozilla 7 February 14, 2014 9 Short Authentication Strings for TLS 10 draft-miers-tls-sas-00 12 Abstract 14 TLS and DTLS connections generally rely on a PKI, a shared secret, or 15 endpoint fingerprints for endpoint authentication. This document 16 describes an authentication mechanism which instead generates a 17 "short authentication string" (SAS) as an emergent property of the 18 connection. The SAS can then be verified via an external channel in 19 order to authenticate the connection. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 18, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Background: Coin-Flipping Protocols . . . . . . . . . . . . . . 3 70 4. Protocol Definition . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Coin Flipping . . . . . . . . . . . . . . . . . . . . . . . 4 72 4.2. Computing the raw SAS bits . . . . . . . . . . . . . . . . 5 73 4.3. Computing the SAS String . . . . . . . . . . . . . . . . . 5 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 75 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 TLS [TLS12] and DTLS connections generally rely on a PKI, a shared 81 secret, or endpoint fingerprints for endpoint authentication. This 82 document describes an authentication mechanism which instead 83 generates a "short authentication string" (SAS) as an emergent 84 property of the connection. The SAS can then be verified via an 85 external channel in order to authenticate the connection. 87 While a fingerprint can be used for authentication (and is used in 88 SSH), it is too long to be conveniently read and compared by two 89 users. If a predictable subset of the fingerprint is compared (e.g., 90 the first or last bits) an attacker can create a fingerprint which 91 just matches that subset. The mechanism described by this document 92 is based on fingerprints but compares a small number of bits derived 93 from the fingerprint and randomness generated by both endpoints, thus 94 requiring an attacker to match the entire fingerprint (which is too 95 long to be feasible) in order to produce a low probability of 96 detection. In order to compute the SAS, the endpoints run a "coin 97 flip" protocol to generate a short shared bitstring which is not 98 under the control of either endpoint. The bitstring is then used, 99 along with the TLS fingerprint, to derive a set of bits that are 100 mapped to a SAS. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 3. Background: Coin-Flipping Protocols 110 The general pattern of a coin-flipping protocol is shown below: 112 Alice Bob 114 H(R_a) -------------> 115 <---------------- R_b 116 R_a ----------------> 118 Alice and Bob each generate a large random number R_a and R_b. Alice 119 (who speaks first) computes a commitment to R_a by hashing R_a and 120 sends it to Bob. Bob then sends R_b to Alice and finally then Alice 121 reveals R_a to Bob. Bob then verifies that R_a matches the hash Alice 122 sent in the first message and then each side computes the shared 123 value S = R_a XOR R_b. 125 4. Protocol Definition 127 4.1. Coin Flipping 129 We map the coin flipping messages to TLS using a TLS extension and a 130 new handshake message, as shown below. 132 Client Server 134 ClientHello + SASXtn --------> 136 ServerHello + SASXtn 137 Certificate* 138 ServerKeyExchange* 139 CertificateRequest* 140 <-------- ServerHelloDone 141 Certificate* 142 ClientKeyExchange 143 CertificateVerify* 144 SASShare 145 [ChangeCipherSpec] 146 Finished --------> SASShare 147 [ChangeCipherSpec] 148 <-------- Finished 149 Application Data <-------> Application Data 151 Each side generates a 512-bit cryptographically random value R_client 152 and R_server. 154 The SASXtn is defined as follows: 156 struct { 157 opaque digest<255>; 158 } SASExtension; 160 The client's SASXtn is a zero-length value indicating the client's 161 desire to do the SAS handshake. The server's SASXtn is a digest of 162 R_server using the Hash defined for the Finished message in Section 163 7.4.9 of [TLS12]. 165 The SASShare structure is defined as follows: 167 struct { 168 opaque share[64]; 169 } SASShare; 171 "share" is the raw byte value of R_client or R_server, as 172 appropriate. 174 4.2. Computing the raw SAS bits 176 The SAS bits are computed as follows: 177 1. If you are the client, verify that the server's R_server matches 178 their SASExtension value. If not, abort the handshake with error 179 handshake_failure 180 2. Compute R_shared = R_client ^ R_server 181 3. If both endpoints have certificate fingerprints compute 182 fingerprints=fingerprint_server | fingerprint_client. If only 183 the server has a fingerprint, compute 184 fingerprints=fingerprint_server. 185 4. Compute SAS_bits as HASH(fingerprints||R_shared) using the Hash 186 defined for the Finished message in Section 7.4.9 of [TLS12] 188 4.3. Computing the SAS String 190 The application should map the first 15