--- 1/draft-ietf-tls-pwd-06.txt 2016-02-26 00:15:11.105800618 -0800 +++ 2/draft-ietf-tls-pwd-07.txt 2016-02-26 00:15:11.181802530 -0800 @@ -1,19 +1,19 @@ Transport Layer Security D. Harkins, Ed. -Internet-Draft Aruba Networks +Internet-Draft HP Enterprise Intended status: Standards Track D. Halasz, Ed. -Expires: September 25, 2015 Halasz Ventures - March 24, 2015 +Expires: August 28, 2016 Halasz Ventures + February 25, 2016 Secure Password Ciphersuites for Transport Layer Security (TLS) - draft-ietf-tls-pwd-06 + draft-ietf-tls-pwd-07 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,25 +24,25 @@ 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 September 25, 2015. + This Internet-Draft will expire on August 28, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -80,21 +80,21 @@ 4.4. Computing the Premaster Secret . . . . . . . . . . . . . 22 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Human Rights Considerations . . . . . . . . . . . . . . . . . 28 10. Implementation Considerations . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . 30 - Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 30 + Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 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 @@ -387,20 +387,23 @@ very good discussion of this can be found in [RFC4086]. If the server supports username protection (see Section 4.1), it is assumed that the server has chosen a domain parameter set and generated a username-protection keypair. The chosen domain parameter set and public key are assumed to be conveyed to the client at the time the client's username and password were provisioned. 4. Specification of the TLS-PWD Handshake + The key exchange underlying TLS-PWD is the "dragonfly" PAKE as + defined in [RFC7664]. + The authenticated key exchange is accomplished by each side deriving a password-based element, PE, in the chosen group, making a "commitment" to a single guess of the password using PE, and generating the Premaster Secret. The ability of each side to produce a valid finished message authenticates itself to the other side. The authenticated key exchange is dropped into the standard TLS message handshake by modifying some of the messages. Client Server @@ -682,25 +685,25 @@ by flipping a coin and multiplying the blinded value by either a random quadratic residue or a random quadratic nonresidue and checking whether the multiplied value is a quadradic residue or a quadradic nonresidue modulo p, respectively. The random residue and nonresidue can be calculated prior to hunting-and-pecking by calculating the legendre symbol on random values until they are found: do { qr = random() - } while ( lgr(qr, p) == -1) + } while ( lgr(qr, p) != 1) do { qnr = random() - } while ( lgr(qnr, p) == 1) + } while ( lgr(qnr, p) != -1) Algorithmically, the masking technique to find out whether a value is a quadratic residue modulo a prime or not looks like this: is_quadratic_residue (val, p) { r = (random() mod (p - 1)) + 1 num = (val * r * r) mod p if ( lsb(r) == 1 ) num = (num * qr) mod p if ( lgr(num, p) == 1) @@ -1094,20 +1097,23 @@ CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); The RFC editor SHALL replace (TBD, TBD) in all the ciphersuites defined in Section 5 with the appropriate IANA-assigned values. The "DTLS-OK" column in the ciphersuite registry SHALL be set to "Y" for all ciphersuites defined in this memo. 8. Security Considerations + A security proof of this key exchange in the random oracle model is + found in [lanskro]. + A passive attacker against this protocol will see the ServerKeyExchange and the ClientKeyExchange containing the server's scalar and Element, and the client's scalar and Element, respectively. The client and server effectively hide their secret private value by masking it modulo the order of the selected group. If the order is "q", then there are approximately "q" distinct pairs of numbers that will sum to the scalar values observed. It is possible for an attacker to iterate through all such values but for a large value of "q", this exhaustive search technique is computationally infeasible. The attacker would have a better chance @@ -1300,80 +1306,103 @@ refusing authentication attempts by a particular username for a certain amount of time, after the number of failed authentication attempts reaches a certain threshold. No such threshold or amount of time is recommended in this memo. 11. References 11.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February - 1997. + Hashing for Message Authentication", RFC 2104, DOI + 10.17487/RFC2104, February 1997, + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. + Internationalized Strings ("stringprep")", RFC 3454, DOI + 10.17487/RFC3454, December 2002, + . [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names - and Passwords", RFC 4013, February 2005. + and Passwords", RFC 4013, DOI 10.17487/RFC4013, February + 2005, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", RFC 5246, August 2008. + (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ + RFC5246, August 2008, + . [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption - Standard (AES)", RFC 5297, October 2008. + Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October + 2008, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand - Key Derivation Function (HKDF)", RFC 5869, May 2010. + Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ + RFC5869, May 2010, + . 11.2. Informative References [FIPS186-3] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-3, . [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, 1993. - [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness - Requirements for Security", BCP 106, RFC 4086, June 2005. + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + . [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites - for Transport Layer Security (TLS)", RFC 4492, May 2006. + for Transport Layer Security (TLS)", RFC 4492, DOI + 10.17487/RFC4492, May 2006, + . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. - [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over - Secure Transport", RFC 7030, October 2013. + [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., + "Enrollment over Secure Transport", RFC 7030, DOI + 10.17487/RFC7030, October 2013, + . + + [RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI + 10.17487/RFC7664, November 2015, + . [SP800-38A] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation-- Methods and Techniques", NIST Special Publication 800-38A, December 2001. [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. + [lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of + the Dragonfly Protocol", Proceedings of 18th International + Information Security Conference (ISC 2015), pp 244-261, + DOI 10.1007/978-3-319-23318-5_14, September 2015. + 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 ---- @@ -1563,24 +1594,23 @@ 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 + HP Enterprise 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