idnits 2.17.1 draft-scott-mpin-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 3, 2015) is 3067 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Scott, B. Spector 3 Intended Status: Informational MIRACL Ltd. 4 Expires: June 3, 2016 G. Yamamoto 5 NTT Innovation Institute Inc. 6 December 3, 2015 8 M-PIN: Zero-Knowledge two-factor authentication for digital identity 9 draft-scott-mpin-00 11 Abstract 13 In this document, the M-PIN protocol for authentication of digital 14 identity is described. This protocol identifies a Client to a Server. 15 M-PIN requires an external Trusted Authority to issue secrets to 16 participating Clients and Servers. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 3rd, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 54 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.0 The M-PIN protocol . . . . . . . . . . . . . . . . . . . . . 4 58 3.1 System setup and Client registration . . . . . . . . . . . . 4 59 3.2 Client Identification . . . . . . . . . . . . . . . . . . . 5 60 3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 65 6.2 Informative References . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Client Identification is a cryptographic protocol whereby a Client 71 securely identifies itself to a Server. Traditionally this has been 72 achieved using a Username/Password combination, with the passwords 73 stored in encrypted form on the Server. Typically the Server is 74 itself responsible for enrollment and registration of Clients. 76 This widespread method of identification has serious shortcomings. 77 Often in the event of a security breach at the Server, the encrypted 78 password file might be captured and from this, using standard 79 techniques, the majority of passwords can be recovered. Since even 80 well supported Servers appear to be incapable of protecting such 81 password files, the only defense seems to be the use of increasingly 82 complex passwords by Clients, which are difficult to remember. 84 It is generally agreed that a form of multi-factor authentication 85 provides superior protection. One manifestation is where the Client 86 experience becomes very similar to that of extracting money from an 87 Automated Teller Machine (ATM). This is a familiar experience in the 88 context of a high value transaction for many people. Here the two 89 factors required for authentication are some form of Token, and an 90 easily memorized PIN number, typically just 4 decimal digits in 91 length. 93 It is also important in the event of a Server breach that the 94 negative consequences for the Clients should be minimized. For this 95 reason our solution proposes the introduction of a Trusted Authority 96 to handle enrollment and registration of Clients, and to relieve the 97 Server of this burden and responsibility. The Server itself is only 98 in possession of a single small secret issued to it by the Trusted 99 Authority. 101 Previously there was no known protocol which allowed for this type of 102 two-factor authentication which was not open to so-called insider 103 attacks, or off-line dictionary attacks. This has necessitated the 104 issuance of the Token in the potentially expensive form-factor of an 105 autonomous hardware device. 107 The protocol proposed here can be implemented entirely in software. 108 The token is typically just 512 bits of data. 110 2. Requirements Notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2.1 Definitions 118 Two-Factor Authentication: Two-factor Authentication is a technology 119 which allows a Client to authenticate itself via an identity string 120 to a Server using two independent sources of data. These MUST be such 121 that knowledge of one factor does not reveal the other factor. Any 122 third party who obtains by whatever means one factor for a certain 123 identity MUST NOT be able to authenticate themselves to the Server in 124 that identity. 126 Digital Identity: Digital Identity is the data that uniquely 127 describes a person or a thing, and typically contains some 128 information about that entity's relationships. 130 2.2 Abbreviations 132 AES Advanced Encryption Standard 134 TA Trusted Authority 136 2.3 Conventions 137 o E is an ordinary pairing-friendly elliptic curve over a finite 138 field F, defined by a fixed prime modulus p. 140 o e: G1 X G2 -> GT is a computable bi-linear map on E. G1 is defined 141 as a group of points on E. G2 is defined as a group of points on a 142 twist of E. Both groups are of prime order q. GT is a finite 143 extension field of F, also of order q. 145 o s is a large positive integer less than q, the master secret 146 belonging to the TA and associated with a particular Server. 148 o H is a well known hash function that converts its input into a 149 positive integer less than q. 151 o H1 is a well known hash function that takes the data associated 152 with Alice's digital identity and assigns it to a point in G1, e.g. 153 H1("Alice@example.com") = A, a point on E in G1. 155 o D=sA is the private key computed by the TA for Alice, and delivered 156 only to Alice. In a similar fashion private keys are issued to all 157 other Clients of the same Server. 159 o S=sQ is the private key computed by the TA for this Server, where Q 160 is a fixed public point on G2. 162 o TOKID is the Token belonging to identity ID, and PINID is the PIN 163 chosen by identity ID. 165 3.0 The M-PIN protocol 167 3.1 System setup and Client registration 169 The TA chooses a suitable elliptic curve and defines the groups G1, 170 G2 and GT. To be concrete the TA chooses a standard BN curve [BN] 171 with parameter x=-0x4080000000000001. This generates a curve with 172 overall security equivalent to AES at the 128-bit level [AES], and 173 which is quite efficient for computation. 175 The TA generates a master secret s, which is reserved for use with a 176 particular Server. The Server is issued with the secret S=sQ. This is 177 calculated by a point multiplication in the group G2. Note that 178 knowledge of S and Q does not reveal s, as it is protected by a known 179 hard problem, the discrete logarithm problem. 181 Clients such as Alice approach the TA and are issued with a secret 182 D=sA, where A is Alice's digital identity hashed to a point in G1. 183 Alice then chooses a PIN number PINA and calculates her token as 184 TOKA=D-PINA.A. In effect her PIN number is subtracted from her 185 secret. Alice is now ready to identify herself to the Server. 187 3.2 Client Identification 189 We assume that the Server is authenticated to the Client using some 190 existing technology such as SSL [RFC6101]. This has the added benefit 191 of encrypting the protocol exchanges, which prevents an eavesdropper 192 from learning even the identity of the authenticating individual. 193 The actual identification protocol is based on the work of Kurosawa 194 and Heng [KH]. Their protocol is a single-factor zero-knowledge proof 195 of identity. 197 Initially the Client hashes her digital identity "Alice@example.com" 198 to a point A using the hash function H1, and selects a random 199 positive integer x less than q. The Client MUST use a fresh, random 200 value of x for each run of the protocol. The Server selects a random 201 positive integer y less than q. The Server MUST use a fresh value of 202 y for each run of the protocol. 204 Client --------> Server 206 "Alice@example.com", U=xA 208 Server ---------> Client 210 y 212 Client ---------> Server 214 V=-(x+y)(TOKA+PINA.A) 216 The Server itself calculates A by applying the hash function H1 to 217 the claimed digital identity. Finally the Server SHALL check that 218 e(V,Q).e(U+yA,sQ) = 1. If it is, the Client is authenticated, 219 otherwise she is not. 221 As described this is a 3-pass protocol. However if the Client itself 222 derives the challenge y as y=H(U|T) (where T is a time-stamp 223 transmitted by the Client along her claimed identity, U and V) the 224 protocol can be reduced in an obvious way to a secure 1-pass protocol 225 assuming that the Server checks the accuracy of the time-stamp before 226 completing the protocol. We point out that this 1-pass variant is 227 probably a better choice if M-PIN is to replace an existing 228 Username/Password implementation. 230 3.3 Discussion 232 o The TA with its knowledge of the master secret s represents a 233 potential single-point-of-failure for the scheme. However, without 234 going into further detail, we point out here that the TA function 235 can be distributed in a multiplicity of ways using a standard 236 secret sharing scheme. In its simplest manifestation there might 237 be 2 TAs, each one of which generates a part-secret (so s=s1+s2), 238 and both of which would have to be compromised to determine the 239 master secret. 241 o In a similar way the Server function and server secret can also 242 be split across multiple Servers. 244 o Implementation considerations: An implementation of M-PIN is 245 particularly lightweight on the Client side. Only two point 246 multiplications in G1 are required. Indeed there is no requirement 247 for any support for G2 or GT arithmetic. This will be fast even if 248 carried out within a browser. On the Server side the product of 249 two pairings can be calculated much more efficiently than two 250 single pairings. 252 o An implementation of M-PIN MAY use a biometric measurement 253 either in place of a PIN number, or in conjunction with a PIN 254 number, in which case it supports 3-factor authentication. 256 o It is assumed that the Server will be implementing some kind of 257 mechanism to prevent someone who does not know the PIN from 258 attempting to guess it by making a multiplicity of authentication 259 attempts. Such a mechanism and its implementation are outside of 260 the scope of this draft. 262 4. Security Considerations 264 Two-Factor authentication methods can be vulnerable to off-line 265 dictionary attacks. Here an attacker might capture one authentication 266 factor from their victim, typically the token, and then try to use 267 this along with other information, perhaps gleaned from previously 268 recorded protocol runs or other stolen client secrets, to determine 269 their PIN. One manifestation of such an attack might be an "insider" 270 attack whereby another Client Bob with his own secret might capture 271 the token of Alice and by some efficient computation arrive at her 272 PIN number. 274 Another powerful attacker might be an entity which successfully 275 breaches the security of the Server and comes away with its secret 276 sQ. It should not be possible for such an entity to determine a 277 Client's secret, or to authenticate to the Server in the name of a 278 Client. 280 However the server secret sQ is in the group G2, and therefore cannot 281 be used to authenticate to the genuine server, as it expects to 282 receive from a Client only elements of G1. 284 So we get immunity from such attacks by the expedient of implementing 285 the Kurosawa and Heng protocol on an ordinary pairing friendly 286 elliptic curve, such that G1 and G2 are distinct groups, albeit of 287 the same order. This idea was first suggested in [Scott]. 289 The XDH assumption [Scott], [BGMM] is that in the context of a 290 pairing, that the Decisional Diffie-Hellman problem is hard in the 291 group G1. 293 The basic Kurosawa and Heng protocol was proven to be secure, under 294 standard assumptions, by Bellare et al. [BNN]. Furthermore we assert 295 that any attacker able to determine the PIN from transmitted values, 296 a captured token and optionally other full client secrets, breaks an 297 instance of the XDH assumption, under the additional assumption that 298 the function used to hash digital identities acts as a Random Oracle. 300 5. IANA Considerations 302 At this time there are no IANA considerations 304 6. References 306 6.1 Normative References 308 [RFC6101] Freier A., Karlton P., Kocher P., "The Secure Sockets Layer 309 (SSL) Protocol Version 3.0", RFC 6101, August 2011 311 [RFC2119] Bradner S., "Key words for use in RFCs to Indicate 312 Requirement Levels", RFC 2119, March 1997 314 6.2 Informative References 316 [AES] National Institute of Standards and Technology, "Specification 317 for the Advanced Encryption Standard (AES)", FIPS 197, November 2001. 319 [BGMM] Ballard, L., Green, M., de Medeiros B., and Monrose, F., 320 "Correlation-Resistant Storage via Keyword-Searchable Encryption", 321 Cryptology ePrint Archive, Report 2005/417 323 [BN] Barreto, P., Naehrig, M., "Pairing-Friendly elliptic curves of 324 prime order", SAC 2005, LNCS 3897, Springer-Verlag (2006), pp. 319- 325 331. 327 [BNN] Bellare, M., Namprempre, C., and Neven, G., "Security proofs 328 for identity-based identification and signature schemes", Eurocrypt 329 2004, LNCS 3027, Springer-Verlag (2004), pp. 268-286. 331 [KH] Kurosawa, K. Heng, S., "From Digital Signature to ID- based 332 Identification/Signature", PKC 2004, LNCS 2947, Springer-Verlag 333 (2006), pp. 125-143. 335 [Scott] Scott, M. "Authenticated ID-based Key Exchange and remote 336 log-in with simple token and PIN number", Cryptology ePrint Archive, 337 Report 2002/164 339 Authors' Addresses 341 Michael Scott 342 4 Foster Place North 343 Ballybough 344 Dublin 3 345 Ireland 347 Email: mike.scott@miracl.com 349 Brian Spector 350 81 Rivington Street 351 London EC2A 3AY 352 England 354 Email: brian.spector@miracl.com 356 Go Yamamoto 357 NTT 359 Email: yamamoto.go@ntti3.com