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

   1
   2
   3
   4 Transport Layer Security Working                               D. Taylor
   5 Group                                             Forge Research Pty Ltd
   6 Internet-Draft                                         September 4, 2002
   7 Expires: March 5, 2003
   8
   9
  10                     Using SRP for TLS Authentication
  11                          draft-ietf-tls-srp-03
  12
  13 Status of this Memo
  14
  15    This document is an Internet-Draft and is in full conformance with
  16    all provisions of Section 10 of RFC2026.
  17
  18    Internet-Drafts are working documents of the Internet Engineering
  19    Task Force (IETF), its areas, and its working groups.  Note that
  20    other groups may also distribute working documents as Internet-
  21    Drafts.
  22
  23    Internet-Drafts are draft documents valid for a maximum of six months
  24    and may be updated, replaced, or obsoleted by other documents at any
  25    time.  It is inappropriate to use Internet-Drafts as reference
  26    material or to cite them other than as "work in progress."
  27
  28    The list of current Internet-Drafts can be accessed at http://
  29    www.ietf.org/ietf/1id-abstracts.txt.
  30
  31    The list of Internet-Draft Shadow Directories can be accessed at
  32    http://www.ietf.org/shadow.html.
  33
  34    This Internet-Draft will expire on March 5, 2003.
  35
  36 Copyright Notice
  37
  38    Copyright (C) The Internet Society (2002).  All Rights Reserved.
  39
  40 Abstract
  41
  42    This memo presents a technique for using the SRP [2] (Secure Remote
  43    Password) protocol as an authentication method for the TLS
  44    [1](Transport Layer Security) protocol.
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56 Taylor                   Expires March 5, 2003                  [Page 1]
  57 \f
  58 Internet-Draft      Using SRP for TLS Authentication      September 2002
  59
  60
  61 Table of Contents
  62
  63    1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
  64    2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
  65    2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
  66    2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
  67    2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  4
  68    2.2   SRP Verifier Message Digest Selection  . . . . . . . . . . .  5
  69    2.3   Changes to the Handshake Message Contents  . . . . . . . . .  5
  70    2.3.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  5
  71    2.3.2 Server hello . . . . . . . . . . . . . . . . . . . . . . . .  5
  72    2.3.3 Server certificate . . . . . . . . . . . . . . . . . . . . .  5
  73    2.3.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  6
  74    2.3.5 Server key exchange  . . . . . . . . . . . . . . . . . . . .  6
  75    2.4   Calculating the Pre-master Secret  . . . . . . . . . . . . .  6
  76    2.5   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  6
  77    2.6   New Message Structures . . . . . . . . . . . . . . . . . . .  7
  78    2.6.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  7
  79    2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  7
  80    2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . .  8
  81    2.6.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
  82    2.6.5 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
  83    3.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
  84          References . . . . . . . . . . . . . . . . . . . . . . . . . 11
  85          Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
  86    A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
  87          Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112 Taylor                   Expires March 5, 2003                  [Page 2]
 113 \f
 114 Internet-Draft      Using SRP for TLS Authentication      September 2002
 115
 116
 117 1. Introduction
 118
 119    At the time of writing, TLS uses public key certificiates with RSA/
 120    DSA digital signatures, or Kerberos, for authentication.
 121
 122    These authentication methods do not seem well suited to the
 123    applications now being adapted to use TLS (IMAP [3], FTP [5], or
 124    TELNET [6], for example).  Given these protocols (and others like
 125    them) are designed to use the user name and password method of
 126    authentication, being able to safely use user names and passwords to
 127    authenticate the TLS connection provides a much easier route to
 128    additional security than implementing a public key infrastructure in
 129    certain situations.
 130
 131    SRP is an authentication method that allows the use of user names and
 132    passwords over unencrypted channels without revealing the password to
 133    an eavesdropper.  SRP also supplies a shared secret at the end of the
 134    authetication sequence that can be used to generate encryption keys.
 135
 136    This document describes the use of the SRP authentication method for
 137    TLS.
 138
 139    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 140    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 141    document are to be interpreted as described in RFC 2119.
 142
 143    Changes in this version:
 144
 145       Changed the order of the s, N, and g parameters for the Server
 146       Hello message in the handshake sequence diagram to conform to the
 147       SRPExtension structure.
 148
 149       Removed the requirement to add leading zeros to encoded numbers
 150       whose most significant bit is set.
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168 Taylor                   Expires March 5, 2003                  [Page 3]
 169 \f
 170 Internet-Draft      Using SRP for TLS Authentication      September 2002
 171
 172
 173 2. SRP Authentication in TLS
 174
 175 2.1 Modifications to the TLS Handshake Sequence
 176
 177    The SRP protocol can not be implemented using the sequence of
 178    handshake messages defined in [1] due to the sequence in which the
 179    SRP messages must be sent.
 180
 181    This document presents a new sequence of handshake messages for
 182    handshakes using the SRP authentication method.
 183
 184 2.1.1 Message Sequence
 185
 186    Handshake Message Flow for SRP Authentication
 187
 188           Client                                 Server
 189             |                                      |
 190        Client Hello (U) ------------------------>  |
 191             |  <---------------------------- Server Hello (s, N, g)
 192             |  <---------------------------- Certificate*
 193        Client Key Exchange (A) ----------------->  |
 194             |  <---------------------------- Server Key Exchange (B)
 195             |  <---------------------------- Server Hello Done
 196        change cipher spec                          |
 197        Finished -------------------------------->  |
 198             |                                change cipher spec
 199             |  <---------------------------- Finished
 200             |                                      |
 201
 202    * Indicates optional or situation-dependent messages that are not
 203    always sent.
 204
 205    The identifiers given after each message name refer to the SRP
 206    variables included in that message.  The variables U, g, N, s, A, and
 207    B are defined in [2].
 208
 209    Extended client and server hello messages, as defined in [7], are
 210    used to to send the initial client and server values.
 211
 212    The client key exchange message is sent during the sequence of server
 213    messages.  This modification is required because the client must send
 214    its public key (A) before it receives the servers public key (B), as
 215    stated in Section 3 of [2].
 216
 217 2.1.2 Session Re-use
 218
 219    The short handshake mechanism for re-using sessions for new
 220    connections, and renegotiating keys for existing connections will
 221
 222
 223
 224 Taylor                   Expires March 5, 2003                  [Page 4]
 225 \f
 226 Internet-Draft      Using SRP for TLS Authentication      September 2002
 227
 228
 229    still work with the SRP authentication mechanism and handshake.
 230
 231    When a client attemps to re-use a session that uses SRP
 232    authentication, it MUST still include the SRP extension carrying the
 233    user name (U) in the client hello message, in case the server cannot
 234    or will not allow re-use of the session, meaning a full handshake
 235    sequence is required.
 236
 237    If a client requests an existing session and the server agrees to use
 238    it (meaning the short handshake will be used), the server MAY omit
 239    the SRP extension from the server hello message, as the information
 240    it contains is not used in the short handshake.
 241
 242 2.2 SRP Verifier Message Digest Selection
 243
 244    The cipher suites defined in this document use the SHA-1 message
 245    digest with the SRP algorithm, as specified in [2].  Implementations
 246    conforming to this document MUST use the SHA-1 message digest.
 247
 248    Future documents may define other cipher suites that use different
 249    message digests, or other similar functions, with the SRP algorithm.
 250
 251 2.3 Changes to the Handshake Message Contents
 252
 253    This section describes the changes to the TLS handshake message
 254    contents when SRP is being used for authentication.  The definitions
 255    of the new message contents and the on-the-wire changes are given in
 256    Section 2.6.
 257
 258 2.3.1 Client hello
 259
 260    The user name is appended to the standard client hello message using
 261    the hello message extension mechanism defined in [7].
 262
 263 2.3.2 Server hello
 264
 265    The the generator (g), the prime (N), and the salt value (s) read
 266    from the SRP password file are appended to the server hello message
 267    using the hello message extension mechanism defined in [7].
 268
 269 2.3.3 Server certificate
 270
 271    The server MUST send a certificate if it agrees to an SRP cipher
 272    suite that requires the server to provide additional authentication
 273    in the form of a digital signature.  See Section 2.5 for details of
 274    which ciphersuites defined in this document require a server
 275    certificate to be sent.
 276
 277
 278
 279
 280 Taylor                   Expires March 5, 2003                  [Page 5]
 281 \f
 282 Internet-Draft      Using SRP for TLS Authentication      September 2002
 283
 284
 285    Because the server's certificate is only used for generating a
 286    digital signature in SRP cipher suites, the certificate sent MUST
 287    contain a public key that can be used for generating digital
 288    signatures.
 289
 290 2.3.4 Client key exchange
 291
 292    The client key exchange message carries the client's public key (A),
 293    which is calculated using both information known locally, and
 294    information received in the server hello message.  This message MUST
 295    be sent before the server key exchange message.
 296
 297 2.3.5 Server key exchange
 298
 299    The server key exchange message contains the server's public key (B).
 300    The server key exchange message MUST be sent after the client key
 301    exchange message.
 302
 303    If the server has sent a certificate message, the server key exchange
 304    message MUST be signed.
 305
 306 2.4 Calculating the Pre-master Secret
 307
 308    The shared secret resulting from the SRP calculations (S) (defined in
 309    [2]) is used as the pre-master secret.
 310
 311    The finished messages perform the same function as the client and
 312    server evidence messages specified in [2].  If either the client or
 313    the server calculate an incorrect value, the finished messages will
 314    not be understood, and the connection will be dropped as specified in
 315    [1].
 316
 317 2.5 Cipher Suite Definitions
 318
 319    The following cipher suites are added by this draft.  The usage of
 320    AES ciphersuites is as defined in [4].
 321
 322       CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
 323
 324       CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
 325
 326       CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
 327
 328       CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
 329
 330       CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
 331
 332       CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
 333
 334
 335
 336 Taylor                   Expires March 5, 2003                  [Page 6]
 337 \f
 338 Internet-Draft      Using SRP for TLS Authentication      September 2002
 339
 340
 341       CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
 342
 343       CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
 344
 345       CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
 346
 347    Cipher suites that do not include a digitial signature algorithm
 348    identifier assume the server is authenticated by its possesion of the
 349    SRP database.
 350
 351    Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
 352    require the server to send a certificate message containing a
 353    certificate with the specified type of public key, and to sign the
 354    server key exchange message using a matching private key.
 355
 356    Implementations conforming to this specification MUST implement the
 357    TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
 358    TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
 359    ciphersuites, and MAY implement the remaining ciphersuites.
 360
 361 2.6 New Message Structures
 362
 363    This section shows the structure of the messages passed during a
 364    handshake that uses SRP for authentication.  The representation
 365    language used is the same as that used in [1].
 366
 367 2.6.1 ExtensionType
 368
 369    A new value, "srp(6)", has been added to the enumerated
 370    ExtensionType, defined in [7].  This value is used as the extension
 371    number for the extensions in both the client hello message and the
 372    server hello message.
 373
 374 2.6.2 Client Hello
 375
 376    The user name (U) is encoded in an SRPExtension structure, and sent
 377    in an extended client hello message, using an extension of type
 378    "srp".
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392 Taylor                   Expires March 5, 2003                  [Page 7]
 393 \f
 394 Internet-Draft      Using SRP for TLS Authentication      September 2002
 395
 396
 397    enum { client, server } ClientOrServerExtension;
 398
 399    struct {
 400       select(ClientOrServerExtension) {
 401          case client:
 402             opaque srp_U<1..2^8-1>;
 403          case server:
 404             opaque srp_s<1..2^8-1>
 405             opaque srp_N<1..2^16-1>;
 406             opaque srp_g<1..2^16-1>;
 407       }
 408    } SRPExtension;
 409
 410
 411 2.6.3 Server Hello
 412
 413    The generator (g), the prime (N), and the salt value (s) are encoded
 414    in an SRPExtension structure, which is sent in an extended server
 415    hello message, using an extension of type "srp".
 416
 417 2.6.4 Client Key Exchange
 418
 419    When the value of KeyExchangeAlgorithm is set to "srp", the client's
 420    ephemeral public key (A) is sent in the client key exchange message,
 421    encoded in an ClientSRPPublic structure.
 422
 423    An extra value, srp, has been added to the enumerated
 424    KeyExchangeAlgorithm, originally defined in TLS [1].
 425
 426    struct {
 427       select (KeyExchangeAlgorithm) {
 428          case rsa: EncryptedPreMasterSecret;
 429          case diffie_hellman: ClientDiffieHellmanPublic;
 430          case srp: ClientSRPPublic;   /* new entry */
 431       } exchange_keys;
 432    } ClientKeyExchange;
 433
 434    enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
 435
 436    struct {
 437       opaque srp_A<1..2^16-1>;
 438    } ClientSRPPublic;
 439
 440
 441 2.6.5 Server Key Exchange
 442
 443    When the value of KeyExchangeAlgorithm is set to "srp", the server's
 444    ephemeral public key (B) is sent in the server key exchange message,
 445
 446
 447
 448 Taylor                   Expires March 5, 2003                  [Page 8]
 449 \f
 450 Internet-Draft      Using SRP for TLS Authentication      September 2002
 451
 452
 453    encoded in an ServerSRPPublic structure.
 454
 455    The following table gives the SignatureAlgorithm value to be used for
 456    each ciphersuite.
 457
 458       Ciphersuite                            SignatureAlgorithm
 459
 460       TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
 461
 462       TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
 463
 464       TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
 465
 466       TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
 467
 468       TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
 469
 470       TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
 471
 472       TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
 473
 474       TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
 475
 476       TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
 477
 478
 479    struct {
 480       select (KeyExchangeAlgorithm) {
 481          case diffie_hellman:
 482             ServerDHParams params;
 483             Signature signed_params;
 484          case rsa:
 485             ServerRSAParams params;
 486             Signature signed_params;
 487          case srp:   /* new entry */
 488             ServerSRPPublic params;
 489             Signature signed_params;
 490       };
 491    } ServerKeyExchange;
 492
 493    struct {
 494       opaque srp_B<1..2^16-1>;
 495    } ServerSRPPublic;     /* SRP parameters */
 496
 497
 498
 499
 500
 501
 502
 503
 504 Taylor                   Expires March 5, 2003                  [Page 9]
 505 \f
 506 Internet-Draft      Using SRP for TLS Authentication      September 2002
 507
 508
 509 3. Security Considerations
 510
 511    If an attacker is able to steal the SRP verifier file, the attacker
 512    can masquerade as the real host.  Filesystem based X.509 certificate
 513    installations are vulnerable to a similar attack unless the server's
 514    certificate is issued from a PKI that maintains revocation lists, and
 515    the client TLS code can both contact the PKI and make use of the
 516    revocation list.
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560 Taylor                   Expires March 5, 2003                 [Page 10]
 561 \f
 562 Internet-Draft      Using SRP for TLS Authentication      September 2002
 563
 564
 565 References
 566
 567    [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
 568         1999.
 569
 570    [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
 571         2945, September 2000.
 572
 573    [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
 574         1999.
 575
 576    [4]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
 577         Transport Layer Security (TLS)", RFC 3268, June 2002.
 578
 579    [5]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
 580         V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
 581         09 (work in progress), April 2002.
 582
 583    [6]  Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
 584         tn3270e-telnet-tls-06 (work in progress), April 2002.
 585
 586    [7]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
 587         Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in
 588         progress), July 2002.
 589
 590
 591 Author's Address
 592
 593    David Taylor
 594    Forge Research Pty Ltd
 595
 596    EMail: DavidTaylor@forge.com.au
 597    URI:   http://www.forge.com.au/
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616 Taylor                   Expires March 5, 2003                 [Page 11]
 617 \f
 618 Internet-Draft      Using SRP for TLS Authentication      September 2002
 619
 620
 621 Appendix A. Acknowledgements
 622
 623    Thanks to all on the IETF tls mailing list for ideas and analysis.
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672 Taylor                   Expires March 5, 2003                 [Page 12]
 673 \f
 674 Internet-Draft      Using SRP for TLS Authentication      September 2002
 675
 676
 677 Full Copyright Statement
 678
 679    Copyright (C) The Internet Society (2002).  All Rights Reserved.
 680
 681    This document and translations of it may be copied and furnished to
 682    others, and derivative works that comment on or otherwise explain it
 683    or assist in its implementation may be prepared, copied, published
 684    and distributed, in whole or in part, without restriction of any
 685    kind, provided that the above copyright notice and this paragraph are
 686    included on all such copies and derivative works.  However, this
 687    document itself may not be modified in any way, such as by removing
 688    the copyright notice or references to the Internet Society or other
 689    Internet organizations, except as needed for the purpose of
 690    developing Internet standards in which case the procedures for
 691    copyrights defined in the Internet Standards process must be
 692    followed, or as required to translate it into languages other than
 693    English.
 694
 695    The limited permissions granted above are perpetual and will not be
 696    revoked by the Internet Society or its successors or assigns.
 697
 698    This document and the information contained herein is provided on an
 699    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 700    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 701    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 702    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 703    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 704
 705 Acknowledgement
 706
 707    Funding for the RFC Editor function is currently provided by the
 708    Internet Society.
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728 Taylor                   Expires March 5, 2003                 [Page 13]
 729 \f
 730