doc/protocol/draft-badra-ecdhe-tls-psk-00.txt

   1
   2
   3
   4 Internet Engineering Task Force                                M. Badra
   5 INTERNET DRAFT                                         LIMOS Laboratory
   6 Updates: 4785, 4279
   7
   8 Expires: November 2007                                        July 2007
   9
  10                       ECDHE_PSK Ciphersuites for TLS
  11                     <draft-badra-ecdhe-tls-psk-00.txt>
  12
  13
  14 Status
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups. Note that
  23    other groups may also distribute working documents as Internet
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six
  27    months and may be updated, replaced, or obsoleted by other documents
  28    at any time. It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html
  36
  37    This Internet-Draft will expire on November 2007.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2007).
  42
  43 Abstract
  44
  45    This document updates RFC 4785 and RFC 4279 and specifies a set of
  46    ciphersuites that use an Elliptic Curve Diffie-Hellman exchange
  47    authenticated with a pre-shared key. These ciphersuites provides
  48    Perfect Forward Secrecy. It specifies as well one authentication-
  49    only ciphersuites (with no encryption). This ciphersuite is useful
  50    when authentication and integrity protection is desired, but
  51    confidentiality is not needed or not permitted.
  52
  53    The reader is expected to become familiar with RFC 4785 and RFC 4279
  54    prior to studying this document.
  55
  56
  57 Badra                    Expires November 2007                 [Page 1] \f
  58
  59 Internet-Draft       ECDHE_PSK Ciphersuites for TLS           July 2007
  60
  61
  62 1. Introduction
  63
  64    RFC 4279 specifies ciphersuites for supporting TLS using pre-shared
  65    symmetric keys and they (a) use only symmetric key operations for
  66    authentication, (b) use a Diffie-Hellman exchange  authenticated
  67    with a pre-shared key, or (c) combines public key authentication of
  68    the server with pre-shared key authentication of the client.
  69
  70    RFC 4785 specifies authentication-only ciphersuites (with no
  71    encryption).
  72
  73    This document specifies a set of ciphersuites that use an Elliptic
  74    Curve Diffie-Hellman exchange authenticated with a pre-shared key.
  75    These ciphersuites provides Perfect Forward Secrecy. It specifies as
  76    well one authentication-only ciphersuites (with no encryption). This
  77    ciphersuite is useful when authentication and integrity protection
  78    is desired, but confidentiality is not needed or not permitted.
  79
  80 2. Updating RFC4279
  81
  82    The new ciphersuites proposed here match the ciphersuites defined in
  83    [RFC4279], except that they use an Elliptic Curve Diffie-Hellman
  84    exchange [RFC4492] authenticated with a pre-shared key. They are
  85    defined as follow:
  86
  87    CipherSuite                          Key Exchange  Cipher       Hash
  88
  89    TLS_ECDHE_PSK_WITH_RC4_128_SHA       ECDHE_PSK     RC4_128       SHA
  90    TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA  ECDHE_PSK     3DES_EDE_CBC  SHA
  91    TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA   ECDHE_PSK     AES_128_CBC   SHA
  92    TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA   ECDHE_PSK     AES_256_CBC   SHA
  93
  94    When these ciphersuites are used, the ServerKeyExchange and
  95    ClientKeyExchange messages also include the Diffie-Hellman
  96    parameters.  The PSK identity and identity hint fields have the same
  97    meaning as in the previous section (note that the ServerKeyExchange
  98    message is always sent, even if no PSK identity hint is provided).
  99
 100    The format of the ServerKeyExchange and ClientKeyExchange messages
 101    is shown below.
 102
 103       struct {
 104           select (KeyExchangeAlgorithm) {
 105               /* other cases for rsa, diffie_hellman, etc. */
 106               case ec_diffie_hellman_psk:  /* NEW */
 107                   opaque psk_identity_hint<0..2^16-1>;
 108                   ServerECDHParams params;
 109           };
 110       } ServerKeyExchange;
 111
 112
 113 Badra                    Expires November 2007                 [Page 2] \f
 114
 115 Internet-Draft       ECDHE_PSK Ciphersuites for TLS           July 2007
 116
 117
 118       struct {
 119           select (KeyExchangeAlgorithm) {
 120               /* other cases for rsa, diffie_hellman, etc. */
 121               case ec_diffie_hellman_psk:   /* NEW */
 122                   opaque psk_identity<0..2^16-1>;
 123                   ClientECDiffieHellmanPublic public;
 124           } exchange_keys;
 125       } ClientKeyExchange;
 126
 127    The premaster secret is formed as follows. First, perform the
 128    Elliptic Curve Diffie-Hellman computation in the same way as for
 129    other Diffie-Hellman-based ciphersuites in [TLS1.0] or [TLS1.1]. Let
 130    Z be the value produced by this computation.  Concatenate a uint16
 131    containing the length of Z (in octets), Z itself, a uint16
 132    containing the length of the PSK (in octets), and the PSK itself.
 133
 134    This corresponds to the general structure for the premaster secrets
 135    (see Note 1 in Section 2 in RFC 4279) in [RFC4279], with
 136    "other_secret" containing Z:
 137
 138        struct {
 139            opaque other_secret<0..2^16-1>;
 140            opaque psk<0..2^16-1>;
 141        };
 142
 143    Here "other_secret" comes from the Elliptic Curve Diffie-Hellman
 144    exchange (ECDHE_PSK).
 145
 146 3. Updating RFC4785
 147
 148    The new ciphersuite proposed here match the ciphersuites defined in
 149    [RFC4785], except that it uses an Elliptic Curve Diffie-Hellman
 150    exchange authenticated with a pre-shared key
 151
 152       CipherSuite                     Key Exchange   Cipher      Hash
 153
 154       TLS_ECDHE_PSK_WITH_NULL_SHA     ECDHE_PSK      NULL        SHA
 155
 156 4. Security Considerations
 157
 158    The security considerations described throughout [TLS1.0],
 159    [TLSv1.1], RFC 4785 and RFC 4279 apply here as well.
 160
 161 5. IANA Considerations
 162
 163    This document defines the following new ciphersuites, whose values
 164    are to be assigned from the TLS Cipher Suite registry defined in
 165    [TLS1.1].
 166
 167    CipherSuite   TLS_ECDHE_PSK_WITH_RC4_128_SHA       = { 0xXX, 0xXX };
 168
 169 Badra                    Expires November 2007                 [Page 3] \f
 170
 171 Internet-Draft       ECDHE_PSK Ciphersuites for TLS           July 2007
 172
 173
 174    CipherSuite   TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA  = { 0xXX, 0xXX };
 175    CipherSuite   TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA   = { 0xXX, 0xXX };
 176    CipherSuite   TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA   = { 0xXX, 0xXX };
 177    CipherSuite   TLS_ECDHE_PSK_WITH_NULL_SHA          = { 0xXX, 0xXX };
 178
 179 6. References
 180
 181
 182 6.1. Normative References
 183
 184    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 185              Requirement Levels", BCP 14, RFC 2119, March 1997.
 186
 187    [TLS1.0]  T., Dierks, C., Allen, "The TLS Protocol Version 1.0",
 188              RFC 2246, January 1999.
 189
 190    [TLS1.1]  Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
 191              RFC 4346, April 200P.
 192
 193    [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
 194              for Transport Layer Security (TLS)", RFC 4279, December
 195              2005.
 196
 197    [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK)
 198              Ciphersuites with NULL Encryption for Transport Layer
 199              Security (TLS)", RFC 4785, January 2007.
 200
 201    [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,
 202              Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
 203              Suites for Transport Layer Security (TLS)", RFC 4492, May
 204              2006.
 205
 206 Acknowledgements
 207
 208    The authors would like to thank Bodo Moeller for comments on the
 209    document.
 210
 211 Author's Addresses
 212
 213    Mohamad Badra
 214    LIMOS Laboratory - UMR (6158), CNRS
 215    France                    Email: badra@isima.fr
 216
 217    Full Copyright Statement
 218
 219    Copyright (C) The IETF Trust (2007).
 220
 221    This document is subject to the rights, licenses and restrictions
 222    contained in BCP 78, and except as set forth therein, the authors
 223    retain all their rights.
 224
 225 Badra                    Expires November 2007                 [Page 4] \f
 226
 227 Internet-Draft       ECDHE_PSK Ciphersuites for TLS           July 2007
 228
 229
 230
 231    This document and the information contained herein are provided on
 232    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 233    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
 234    IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
 235    WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
 236    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
 237    ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
 238    FOR A PARTICULAR PURPOSE.
 239
 240    Intellectual Property
 241
 242    The IETF takes no position regarding the validity or scope of any
 243    Intellectual Property Rights or other rights that might be claimed
 244    to pertain to the implementation or use of the technology described
 245    in this document or the extent to which any license under such
 246    rights might or might not be available; nor does it represent that
 247    it has made any independent effort to identify any such rights.
 248    Information on the procedures with respect to rights in RFC
 249    documents can be found in BCP 78 and BCP 79.
 250
 251    Copies of IPR disclosures made to the IETF Secretariat and any
 252    assurances of licenses to be made available, or the result of an
 253    attempt made to obtain a general license or permission for the use
 254    of such proprietary rights by implementers or users of this
 255    specification can be obtained from the IETF on-line IPR repository
 256    at http://www.ietf.org/ipr.
 257
 258    The IETF invites any interested party to bring to its attention any
 259    copyrights, patents or patent applications, or other proprietary
 260    rights that may cover technology that may be required to implement
 261    this standard.  Please address the information to the IETF at ietf-
 262    ipr@ietf.org.
 263
 264    Acknowledgement
 265
 266    Funding for the RFC Editor function is provided by the IETF
 267    Administrative Support Activity (IASA).
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281 Badra                    Expires November 2007                 [Page 5] \f