draft-ietf-tls-pwd-01.txt   draft-ietf-tls-pwd-02.txt 
Transport Layer Security D. Harkins, Ed. Transport Layer Security D. Harkins, Ed.
Internet-Draft Aruba Networks Internet-Draft Aruba Networks
Intended status: Standards Track D. Halasz, Ed. Intended status: Standards Track D. Halasz, Ed.
Expires: February 16, 2014 Halasz Ventures Expires: May 27, 2014 Halasz Ventures
August 15, 2013 November 23, 2013
Secure Password Ciphersuites for Transport Layer Security (TLS) Secure Password Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-pwd-01 draft-ietf-tls-pwd-02
Abstract Abstract
This memo defines several new ciphersuites for the Transport Layer This memo defines several new ciphersuites for the Transport Layer
Security (TLS) protocol to support certificate-less, secure Security (TLS) protocol to support certificate-less, secure
authentication using only a simple, low-entropy, password. The authentication using only a simple, low-entropy, password. The
ciphersuites are all based on an authentication and key exchange ciphersuites are all based on an authentication and key exchange
protocol that is resistant to off-line dictionary attack. protocol that is resistant to off-line dictionary attack.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
4.2.3.2. Processing of Client Key Exchange . . . . . . . . 16 4.2.3.2. Processing of Client Key Exchange . . . . . . . . 16
4.3. Computing the Premaster Secret . . . . . . . . . . . . . . 16 4.3. Computing the Premaster Secret . . . . . . . . . . . . . . 16
5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . . 17 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Implementation Considerations . . . . . . . . . . . . . . . . 22 9. Implementation Considerations . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Background 1. Background
1.1. The Case for Certificate-less Authentication 1.1. The Case for Certificate-less Authentication
TLS usually uses public key certificates for authentication TLS usually uses public key certificates for authentication
[RFC5246]. This is problematic in some cases: [RFC5246]. This is problematic in some cases:
o Frequently, TLS [RFC5246] is used in devices owned, operated, and o Frequently, TLS [RFC5246] is used in devices owned, operated, and
provisioned by people who lack competency to properly use provisioned by people who lack competency to properly use
skipping to change at page 22, line 35 skipping to change at page 22, line 35
finite cyclic group to use with the ciphersuite are divorced in this finite cyclic group to use with the ciphersuite are divorced in this
memo but they remain intimately close. memo but they remain intimately close.
It is RECOMMENDED that implementations take note of the strength It is RECOMMENDED that implementations take note of the strength
estimates of particular groups and to select a ciphersuite providing estimates of particular groups and to select a ciphersuite providing
commensurate security with its hash and encryption algorithms. A commensurate security with its hash and encryption algorithms. A
ciphersuite whose encryption algorithm has a keylength less than the ciphersuite whose encryption algorithm has a keylength less than the
strength estimate, or whose hash algorithm has a blocksize that is strength estimate, or whose hash algorithm has a blocksize that is
less than twice the strength estimate SHOULD NOT be used. less than twice the strength estimate SHOULD NOT be used.
For example, the elliptic curve named secp256r1 (whose IANA-assigned For example, the elliptic curve named brainpoolP256r1 (whose IANA-
number is 23) provides an estimated 128 bits of strength and would be assigned number is 26) provides an estimated 128 bits of strength and
compatible with an encryption algorithm supporting a key of that would be compatible with an encryption algorithm supporting a key of
length, and a hash algorithm that has at least a 256-bit blocksize. that length, and a hash algorithm that has at least a 256-bit
Therefore, a suitable ciphersuite to use with secp256r1 could be blocksize. Therefore, a suitable ciphersuite to use with
TLS_ECCPWD_WITH_AES_128_GCM_SHA256. 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 Resistance to dictionary attack means that the attacker must launch
an active attack to make a single guess at the password. If the size 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 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 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 the probability of success after a single guess is 1/D. After X
guesses, and removal of failed guesses from the pool of possible guesses, and removal of failed guesses from the pool of possible
passwords, the probability becomes 1/(D-X). As X grows so does the passwords, the probability becomes 1/(D-X). As X grows so does the
probability of success. Therefore it is possible for an attacker to probability of success. Therefore it is possible for an attacker to
determine the password through repeated brute-force, active, guessing determine the password through repeated brute-force, active, guessing
skipping to change at page 24, line 28 skipping to change at page 24, line 28
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011. Curve Cryptography Algorithms", RFC 6090, February 2011.
[SP800-56A] [SP800-56A]
Barker, E., Johnson, D., and M. Smid, "Recommendations for Barker, E., Johnson, D., and M. Smid, "Recommendations for
Pair-Wise Key Establishment Schemes Using Discrete Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography", NIST Special Publication 800-56A, Logarithm Cryptography", NIST Special Publication 800-56A,
March 2007. 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 Authors' Addresses
Dan Harkins (editor) Dan Harkins (editor)
Aruba Networks Aruba Networks
1322 Crossman Avenue 1322 Crossman Avenue
Sunnyvale, CA 94089-1113 Sunnyvale, CA 94089-1113
United States of America United States of America
Email: dharkins@arubanetworks.com Email: dharkins@arubanetworks.com
Dave Halasz (editor) Dave Halasz (editor)
Halasz Ventures Halasz Ventures
8401 Chagrin Road, Suite 10A 8401 Chagrin Road, Suite 10A
Chagrin Falls, OH 44023 Chagrin Falls, OH 44023
United States of America United States of America
Email: david.e.halasz@gmail.com Email: david.e.halasz@gmail.com
 End of changes. 7 change blocks. 
12 lines changed or deleted 213 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/