doc/protocol/draft-ietf-tls-srp-00.txt

   1
   2
   3 Network Working Group                                          D. Taylor
   4 Internet-Draft                                    Forge Research Pty Ltd
   5 Expires: August 6, 2001                                 February 5, 2001
   6
   7
   8                     Using SRP for TLS Authentication
   9                          draft-ietf-tls-srp-00.txt
  10
  11 Status of this Memo
  12
  13    This document is an Internet-Draft and is in full conformance with
  14    all provisions of Section 10 of RFC2026.
  15
  16    Internet-Drafts are working documents of the Internet Engineering
  17    Task Force (IETF), its areas, and its working groups. Note that
  18    other groups may also distribute working documents as
  19    Internet-Drafts.
  20
  21    Internet-Drafts are draft documents valid for a maximum of six
  22    months and may be updated, replaced, or obsoleted by other documents
  23    at any time. It is inappropriate to use Internet-Drafts as reference
  24    material or to cite them other than as "work in progress."
  25
  26    The list of current Internet-Drafts can be accessed at
  27    http://www.ietf.org/ietf/1id-abstracts.txt.
  28
  29    The list of Internet-Draft Shadow Directories can be accessed at
  30    http://www.ietf.org/shadow.html.
  31
  32    This Internet-Draft will expire on August 6, 2001.
  33
  34 Copyright Notice
  35
  36    Copyright (C) The Internet Society (2001). All Rights Reserved.
  37
  38 Abstract
  39
  40    This memo presents a technique for using the SRP (Secure Remote
  41    Password) protocol as an authentication method for the TLS
  42    (Transport Layer Security) protocol.
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55 Taylor                   Expires August 6, 2001                 [Page 1]
  56 \f
  57 Internet-Draft      Using SRP for TLS Authentication       February 2001
  58
  59
  60 1. Introduction
  61
  62    At the time of writing, TLS[1] uses public key certificiates with
  63    RSA/DSA digital signatures, or Kerberos, for authentication.
  64
  65    These authentication methods do not seem well suited to the
  66    applications now being adapted to use TLS (IMAP[3], FTP[4], or
  67    TELNET[5], for example). Given these protocols (and others like
  68    them) are designed to use the user name and password method of
  69    authentication, being able to use user names and passwords to
  70    authenticate the TLS connection seems to be a useful feature.
  71
  72    SRP[2] is an authentication method that allows the use of user names
  73    and passwords in a safe manner.
  74
  75    This document describes the use of the SRP authentication method for
  76    TLS.
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Taylor                   Expires August 6, 2001                 [Page 2]
 112 \f
 113 Internet-Draft      Using SRP for TLS Authentication       February 2001
 114
 115
 116 2. SRP Authentication in TLS
 117
 118 2.1 Modifications to the TLS Handshake Sequence
 119
 120    The SRP protocol can not be implemented using the sequence of
 121    handshake messages defined in [1] due to the sequence in which the
 122    SRP messages must be sent.
 123
 124    This document proposes a new sequence of handshake messages for
 125    handshakes using the SRP authentication method.
 126
 127 2.1.1 Message Sequence
 128
 129    Handshake Message Flow for SRP Authentication
 130
 131           Client                                 Server
 132             |                                      |
 133        Client Hello (U) ------------------------>  |
 134             |  <---------------------------- Server Hello
 135             |  <---------------------------- Server Key Exchange (g, N, s)
 136        Client Key Exchange (A) ----------------->  |
 137             |  <---------------------------- Server Key Exchange (B)
 138             |  <---------------------------- Server Hello Done
 139        change cipher spec                          |
 140        Finished -------------------------------->  |
 141             |                                change cipher spec
 142             |  <---------------------------- Finished
 143             |                                      |
 144
 145    The identifiers given after each message name refer to variables
 146    defined in [2] that are sent in that message.
 147
 148    This new handshake sequence has a number of differences from the
 149    standard TLS handshake sequence:
 150
 151    o  The client hello message has the user name appended to the
 152       message. This is allowable as stated in section 7.4.1.2 of [1].
 153
 154    o  The client cannot generate its its public key (A) until after it
 155       has received the (g) and (N) paramters from the server, and the
 156       client must send its public key before it receives the servers
 157       public key (B) (as stated in section 3 of [2]). This means the
 158       client must wait for a server key exchange message containing (g)
 159       and (N), send a client key exchange message containing (A), and
 160       then wait for another server key exchange message containing (B).
 161
 162    o  There is no server identification in this version of a TLS
 163       handshake. If an attacker gets the SRP password file, they can
 164       masquerade as the real system.
 165
 166
 167 Taylor                   Expires August 6, 2001                 [Page 3]
 168 \f
 169 Internet-Draft      Using SRP for TLS Authentication       February 2001
 170
 171
 172 2.2 Changes to the Handshake Message Contents
 173
 174    This section describes the changes to the TLS handshake message
 175    contents when SRP is being used for authentication. The details of
 176    the on-the-wire changes are given in Section 2.5.
 177
 178 2.2.1 The Client Hello Message
 179
 180    The user name is appended to the standard client hello message. The
 181    extra data is included in the handshake message hashes.
 182
 183 2.2.2 The First Server Key Exchange Message
 184
 185    The server key exchange message in the first round contains the
 186    generator (g), the prime (N), and the salt value (s) read from the
 187    SRP password file.
 188
 189 2.2.3 The Client Key Exchange Message
 190
 191    The client key exchange message carries the clients public key (A),
 192    which is calculated using both information known locally, and
 193    information received in the first server key exchange message. This
 194    message MUST be sent between the first and second server key
 195    exchange messages.
 196
 197 2.2.4 The Second Server Key Exchange Message
 198
 199    The server key exchange message in the second round contains the
 200    servers public key (B).
 201
 202 2.3 Calculating the Pre-master Secret
 203
 204    The shared secret resulting from the SRP calculations (S) is used as
 205    the pre-master secret.
 206
 207    The finished messages perform the same function as the client and
 208    server evidence messages specified in [2]. If either the client or
 209    the server calculate an incorrect value, the finished messages will
 210    not be understood, and the connection will be dropped as specified
 211    in [1].
 212
 213 2.4 Cipher Suite Definitions
 214
 215    The following cipher suites are added by this draft. The numbers
 216    have been left blank until a suitable range has been selected.
 217
 218       CipherSuite     TLS_SRP_WITH_3DES_EDE_CBC_SHA       = { ?,? };
 219
 220       CipherSuite     TLS_SRP_WITH_RC4_128_SHA            = { ?,? };
 221
 222
 223 Taylor                   Expires August 6, 2001                 [Page 4]
 224 \f
 225 Internet-Draft      Using SRP for TLS Authentication       February 2001
 226
 227
 228       CipherSuite     TLS_SRP_WITH_IDEA_CBC_SHA           = { ?,? };
 229
 230       CipherSuite     TLS_SRP_WITH_3DES_EDE_CBC_MD5       = { ?,? };
 231
 232       CipherSuite     TLS_SRP_WITH_RC4_128_MD5            = { ?,? };
 233
 234       CipherSuite     TLS_SRP_WITH_IDEA_CBC_MD5           = { ?,? };
 235
 236 2.5 New Message Structures
 237
 238    This section shows the structure of the messages passed during a
 239    handshake that uses SRP for authentication. The representation
 240    language used is that used in [1].
 241
 242    opaque Username<1..2^8-1>;
 243
 244    enum { non_srp, srp } CipherSuiteType;
 245
 246    struct {
 247       ProtocolVersion client_version;
 248       Random random;
 249       SessionID session_id;
 250       CipherSuite cipher_suites<2..2^16-1>;
 251
 252       /* Need a better way to show the optional user_name field */
 253       select (CipherSuiteType) {
 254          case non_srp:
 255             CompressionMethod compression_methods<1..2^8-1>;
 256          case srp:
 257             CompressionMethod compression_methods<1..2^8-1>;
 258             Username user_name;   /* new entry */
 259       };
 260    } ClientHello;
 261
 262    enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
 263
 264    enum { first, second } KeyExchangeRound;
 265
 266    struct {
 267       select (KeyExchangeRound) {
 268          case first:
 269             opaque srp_s<1..2^8-1>
 270             opaque srp_N<1..2^16-1>;
 271             opaque srp_g<1..2^16-1>;
 272          case second:
 273             opaque srp_B<1..2^16-1>;
 274       };
 275    } ServerSRPParams;     /* SRP parameters */
 276
 277
 278
 279 Taylor                   Expires August 6, 2001                 [Page 5]
 280 \f
 281 Internet-Draft      Using SRP for TLS Authentication       February 2001
 282
 283
 284    struct {
 285       select (KeyExchangeAlgorithm) {
 286          case diffie_hellman:
 287             ServerDHParams params;
 288             Signature signed_params;
 289          case rsa:
 290             ServerRSAParams params;
 291             Signature signed_params;
 292          case srp:
 293             ServerSRPParams params;   /* new entry */
 294       };
 295    } ServerKeyExchange;
 296
 297    struct {
 298       opaque srp_A<1..2^16-1>;
 299    } SRPClientEphemeralPublic;
 300
 301    struct {
 302       select (KeyExchangeAlgorithm) {
 303          case rsa: EncryptedPreMasterSecret;
 304          case diffie_hellman: ClientDiffieHellmanPublic;
 305          case srp: SRPClientEphemeralPublic;   /* new entry */
 306       } exchange_keys;
 307    } ClientKeyExchange;
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335 Taylor                   Expires August 6, 2001                 [Page 6]
 336 \f
 337 Internet-Draft      Using SRP for TLS Authentication       February 2001
 338
 339
 340 3. Security Considerations
 341
 342    There is no server identification in this version of a TLS
 343    handshake. If an attacker gets the SRP password file, they can
 344    masquerade as the real system.
 345
 346    What are the security issues of this new handshake sequence? Are the
 347    SRP parameters passed in a safe order? Is it a problem having the
 348    username appended to the client hello message?
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391 Taylor                   Expires August 6, 2001                 [Page 7]
 392 \f
 393 Internet-Draft      Using SRP for TLS Authentication       February 2001
 394
 395
 396 References
 397
 398    [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
 399         1999.
 400
 401    [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
 402         2945, September 2000.
 403
 404    [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
 405         June 1999.
 406
 407    [4]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
 408         V. Wiegand, "Securing FTP with TLS",
 409         draft-murray-auth-ftp-ssl-06 (work in progress), September 2000.
 410
 411    [5]  Boe, M. and J. Altman, "TLS-based Telnet Security",
 412         draft-ietf-tn3270e-telnet-tls-05 (work in progress), October
 413         2000.
 414
 415
 416 Author's Address
 417
 418    David Taylor
 419    Forge Research Pty Ltd
 420
 421    EMail: DavidTaylor@forge.com.au
 422    URI:   http://www.protekt.com/
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Taylor                   Expires August 6, 2001                 [Page 8]
 448 \f
 449 Internet-Draft      Using SRP for TLS Authentication       February 2001
 450
 451
 452 Full Copyright Statement
 453
 454    Copyright (C) The Internet Society (2001). All Rights Reserved.
 455
 456    This document and translations of it may be copied and furnished to
 457    others, and derivative works that comment on or otherwise explain it
 458    or assist in its implementation may be prepared, copied, published
 459    and distributed, in whole or in part, without restriction of any
 460    kind, provided that the above copyright notice and this paragraph
 461    are included on all such copies and derivative works. However, this
 462    document itself may not be modified in any way, such as by removing
 463    the copyright notice or references to the Internet Society or other
 464    Internet organizations, except as needed for the purpose of
 465    developing Internet standards in which case the procedures for
 466    copyrights defined in the Internet Standards process must be
 467    followed, or as required to translate it into languages other than
 468    English.
 469
 470    The limited permissions granted above are perpetual and will not be
 471    revoked by the Internet Society or its successors or assigns.
 472
 473    This document and the information contained herein is provided on an
 474    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 475    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 476    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 477    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 478    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 479
 480 Acknowledgement
 481
 482    Funding for the RFC editor function is currently provided by the
 483    Internet Society.
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503 Taylor                   Expires August 6, 2001                 [Page 9]
 504 \f