--- 1/draft-ietf-tls-pwd-01.txt 2013-11-23 16:14:25.299695667 -0800 +++ 2/draft-ietf-tls-pwd-02.txt 2013-11-23 16:14:25.355697070 -0800 @@ -1,19 +1,19 @@ Transport Layer Security D. Harkins, Ed. Internet-Draft Aruba Networks Intended status: Standards Track D. Halasz, Ed. -Expires: February 16, 2014 Halasz Ventures - August 15, 2013 +Expires: May 27, 2014 Halasz Ventures + November 23, 2013 Secure Password Ciphersuites for Transport Layer Security (TLS) - draft-ietf-tls-pwd-01 + draft-ietf-tls-pwd-02 Abstract This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The ciphersuites are all based on an authentication and key exchange protocol that is resistant to off-line dictionary attack. Status of this Memo @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 16, 2014. + This Internet-Draft will expire on May 27, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,21 +76,22 @@ 4.2.3.2. Processing of Client Key Exchange . . . . . . . . 16 4.3. Computing the Premaster Secret . . . . . . . . . . . . . . 16 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Implementation Considerations . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Background 1.1. The Case for Certificate-less Authentication TLS usually uses public key certificates for authentication [RFC5246]. This is problematic in some cases: o Frequently, TLS [RFC5246] is used in devices owned, operated, and provisioned by people who lack competency to properly use @@ -992,26 +993,27 @@ finite cyclic group to use with the ciphersuite are divorced in this memo but they remain intimately close. It is RECOMMENDED that implementations take note of the strength estimates of particular groups and to select a ciphersuite providing commensurate security with its hash and encryption algorithms. A ciphersuite whose encryption algorithm has a keylength less than the strength estimate, or whose hash algorithm has a blocksize that is less than twice the strength estimate SHOULD NOT be used. - For example, the elliptic curve named secp256r1 (whose IANA-assigned - number is 23) provides an estimated 128 bits of strength and would be - compatible with an encryption algorithm supporting a key of that - length, and a hash algorithm that has at least a 256-bit blocksize. - Therefore, a suitable ciphersuite to use with secp256r1 could be - TLS_ECCPWD_WITH_AES_128_GCM_SHA256. + For example, the elliptic curve named brainpoolP256r1 (whose IANA- + assigned number is 26) provides an estimated 128 bits of strength and + would be compatible with an encryption algorithm supporting a key of + that length, and a hash algorithm that has at least a 256-bit + blocksize. Therefore, a suitable ciphersuite to use with + brainpoolP256r1 could be TLS_ECCPWD_WITH_AES_128_GCM_SHA256 (see + Appendix A for an example of such an exchange). Resistance to dictionary attack means that the attacker must launch an active attack to make a single guess at the password. If the size of the pool from which the password was extracted was D, and each password in the pool has an equal probability of being chosen, then the probability of success after a single guess is 1/D. After X guesses, and removal of failed guesses from the pool of possible passwords, the probability becomes 1/(D-X). As X grows so does the probability of success. Therefore it is possible for an attacker to determine the password through repeated brute-force, active, guessing @@ -1078,27 +1080,226 @@ [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. [SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendations for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, March 2007. +Appendix A. Example Exchange + + (Note: at the time of publication of this memo ciphersuites have + not yet been assigned by IANA and the exchange that follows uses + the private numberspace). + + username: fred + password: barney + + ---- prior to running TLS-pwd ---- + + server generates salt: + + 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 + 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 + + and a base: + + 6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 + c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75 + + ---- state derived during the TLS-pwd exchange ---- + + client and server generate PE: + + pe.x: + 29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 + a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6 + + server private and mask: + + private: + 21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b + 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c + mask: + 0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f + 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5 + + client private and mask: + + private: + 17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f + a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b + mask: + 4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88 + 83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd + + both parties generate pre-master secret and master secret + + pre-master secret: + 01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11 + af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4 + master secret: + 65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1 + 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f + 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad + + ---- ssldump output of exchange ---- + + New TCP connection #1: Charlie Client <-> Suzy Server + 1 1 0.0018 (0.0018) C>SV3.3(173) Handshake + ClientHello + Version 3.3 + random[32]= + 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 + d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d + cipher suites + TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV + TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV + Unknown value 0xff + compression methods + NULL + extensions + TLS-pwd name[5]= + 04 66 72 65 64 + elliptic curve point format[4]= + 03 00 01 02 + elliptic curve list[58]= + 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b + 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 + 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 + 00 02 00 03 00 0f 00 10 00 11 + Packet data[178]= + 16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17 + 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf + a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3 + ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65 + 64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00 + 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 + 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 + 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 + 03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06 + 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 + 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 + 01 01 + + 1 2 0.0043 (0.0024) S>CV3.3(94) Handshake + ServerHello + Version 3.3 + random[32]= + 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 + 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa + session_id[32]= + ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 + e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 + cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV + compressionMethod NULL + extensions + renegotiate[1]= + 00 + elliptic curve point format[4]= + 03 00 01 02 + heartbeat[1]= + 01 + Packet data[99]= + 16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43 + 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 + ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08 + 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 + 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00 + 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f + 00 01 01 + + 1 3 0.0043 (0.0000) S>CV3.3(141) Handshake + ServerKeyExchange + params + salt[32]= + 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 + 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 + EC parameters = 3 + curve id = 26 + element[65]= + 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 + 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee + f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 + be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db + e1 + scalar[32]= + 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a + df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21 + Packet data[146]= + 16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1 + 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d + 47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04 + 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 + 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 + 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be + 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 + 00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 + 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc + 49 21 + + 1 4 0.0043 (0.0000) S>CV3.3(4) Handshake + ServerHelloDone + Packet data[9]= + 16 03 03 00 04 0e 00 00 00 + + 1 5 0.0086 (0.0043) C>SV3.3(104) Handshake + ClientKeyExchange + element[65]= + 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 + 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f + 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 + c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd + a0 + scalar[32]= + 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 + 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 + Packet data[109]= + 16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b + 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 + 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd + d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf + e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44 + aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 + 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 + + 1 6 0.0086 (0.0000) C>SV3.3(1) ChangeCipherSpec + Packet data[6]= + 14 03 03 00 01 01 + + 1 7 0.0086 (0.0000) C>SV3.3(40) Handshake + Packet data[45]= + 16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7 + 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a + 0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20 + + 1 8 0.0105 (0.0018) S>CV3.3(1) ChangeCipherSpec + Packet data[6]= + 14 03 03 00 01 01 + + 1 9 0.0105 (0.0000) S>CV3.3(40) Handshake + Packet data[45]= + 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c + 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 + a2 21 94 90 12 72 23 18 24 21 c3 60 a4 + + 1 10 0.0107 (0.0002) C>SV3.3(100) application_data + Packet data.... + Authors' Addresses Dan Harkins (editor) Aruba Networks 1322 Crossman Avenue Sunnyvale, CA 94089-1113 United States of America Email: dharkins@arubanetworks.com - Dave Halasz (editor) Halasz Ventures 8401 Chagrin Road, Suite 10A Chagrin Falls, OH 44023 United States of America Email: david.e.halasz@gmail.com