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

   1
   2
   3
   4 TLS Working Group                                              D. Taylor
   5 Internet-Draft                                               Independent
   6 Expires: December 28, 2006                                         T. Wu
   7                                                      Stanford University
   8                                                     N. Mavrogiannopoulos
   9                                                                T. Perrin
  10                                                              Independent
  11                                                            June 26, 2006
  12
  13
  14                     Using SRP for TLS Authentication
  15                          draft-ietf-tls-srp-12
  16
  17 Status of this Memo
  18
  19    By submitting this Internet-Draft, each author represents that any
  20    applicable patent or other IPR claims of which he or she is aware
  21    have been or will be disclosed, and any of which he or she becomes
  22    aware will be disclosed, in accordance with Section 6 of BCP 79.
  23
  24    Internet-Drafts are working documents of the Internet Engineering
  25    Task Force (IETF), its areas, and its working groups.  Note that
  26    other groups may also distribute working documents as Internet-
  27    Drafts.
  28
  29    Internet-Drafts are draft documents valid for a maximum of six months
  30    and may be updated, replaced, or obsoleted by other documents at any
  31    time.  It is inappropriate to use Internet-Drafts as reference
  32    material or to cite them other than as "work in progress."
  33
  34    The list of current Internet-Drafts can be accessed at
  35    http://www.ietf.org/ietf/1id-abstracts.txt.
  36
  37    The list of Internet-Draft Shadow Directories can be accessed at
  38    http://www.ietf.org/shadow.html.
  39
  40    This Internet-Draft will expire on December 28, 2006.
  41
  42 Copyright Notice
  43
  44    Copyright (C) The Internet Society (2006).
  45
  46 Abstract
  47
  48    This memo presents a technique for using the Secure Remote Password
  49    protocol as an authentication method for the Transport Layer Security
  50    protocol.
  51
  52
  53
  54
  55 Taylor, et al.          Expires December 28, 2006               [Page 1]
  56 \f
  57 Internet-Draft      Using SRP for TLS Authentication           June 2006
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63    2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
  64      2.1.  Notation and Terminology . . . . . . . . . . . . . . . . .  4
  65      2.2.  Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
  66      2.3.  Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
  67      2.4.  SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
  68      2.5.  Changes to the Handshake Message Contents  . . . . . . . .  5
  69        2.5.1.  Client Hello . . . . . . . . . . . . . . . . . . . . .  5
  70        2.5.2.  Server Certificate . . . . . . . . . . . . . . . . . .  7
  71        2.5.3.  Server Key Exchange  . . . . . . . . . . . . . . . . .  7
  72        2.5.4.  Client Key Exchange  . . . . . . . . . . . . . . . . .  8
  73      2.6.  Calculating the Pre-master Secret  . . . . . . . . . . . .  8
  74      2.7.  Cipher Suite Definitions . . . . . . . . . . . . . . . . .  9
  75      2.8.  New Message Structures . . . . . . . . . . . . . . . . . . 10
  76        2.8.1.  Client Hello . . . . . . . . . . . . . . . . . . . . . 10
  77        2.8.2.  Server Key Exchange  . . . . . . . . . . . . . . . . . 10
  78        2.8.3.  Client Key Exchange  . . . . . . . . . . . . . . . . . 11
  79      2.9.  Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
  80    3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
  81    4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
  82    5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  83      5.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
  84      5.2.  Informative References . . . . . . . . . . . . . . . . . . 16
  85    Appendix A.  SRP Group Parameters  . . . . . . . . . . . . . . . . 18
  86    Appendix B.  SRP Test Vectors  . . . . . . . . . . . . . . . . . . 23
  87    Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 25
  88    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
  89    Intellectual Property and Copyright Statements . . . . . . . . . . 27
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Taylor, et al.          Expires December 28, 2006               [Page 2]
 112 \f
 113 Internet-Draft      Using SRP for TLS Authentication           June 2006
 114
 115
 116 1.  Introduction
 117
 118    At the time of writing TLS [TLS] uses public key certificates, pre-
 119    shared keys, or Kerberos for authentication.
 120
 121    These authentication methods do not seem well suited to certain
 122    applications now being adapted to use TLS ([IMAP] for example).
 123    Given that many protocols are designed to use the user name and
 124    password method of authentication, being able to safely use user
 125    names and passwords provides an easier route to additional security.
 126
 127    SRP ([SRP], [SRP-6]) is an authentication method that allows the use
 128    of user names and passwords over unencrypted channels without
 129    revealing the password to an eavesdropper.  SRP also supplies a
 130    shared secret at the end of the authentication sequence that can be
 131    used to generate encryption keys.
 132
 133    This document describes the use of the SRP authentication method for
 134    TLS.
 135
 136    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 137    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 138    document are to be interpreted as described in RFC 2119.
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Taylor, et al.          Expires December 28, 2006               [Page 3]
 168 \f
 169 Internet-Draft      Using SRP for TLS Authentication           June 2006
 170
 171
 172 2.  SRP Authentication in TLS
 173
 174 2.1.  Notation and Terminology
 175
 176    The version of SRP used here is sometimes referred to as "SRP-6"
 177    [SRP-6].  This version is a slight improvement over "SRP-3", which
 178    was described in [SRP] and [SRP-RFC].
 179
 180    This document uses the variable names defined in [SRP-6]:
 181
 182       N, g: group parameters (prime and generator)
 183
 184       s: salt
 185
 186       B, b: server's public and private values
 187
 188       A, a: client's public and private values
 189
 190       I: user name (aka "identity")
 191
 192       P: password
 193
 194       v: verifier
 195
 196       k: SRP-6 multiplier
 197
 198    The | symbol indicates string concatenation, the ^ operator is the
 199    exponentiation operation, and the % operator is the integer remainder
 200    operation.
 201
 202    Conversion between integers and byte-strings assumes the most-
 203    significant bytes are stored first, as per [TLS] and [SRP-RFC].  In
 204    the following text, if a conversion from integer to byte-string is
 205    implicit, the most-significant byte in the resultant byte-string MUST
 206    be non-zero.  If a conversion is explicitly specified with the
 207    operator PAD(), the integer will first be implicitly converted, then
 208    the resultant byte-string will be left-padded with zeros (if
 209    necessary) until its length equals the implicitly-converted length of
 210    N.
 211
 212 2.2.  Handshake Protocol Overview
 213
 214    The advent of [SRP-6] allows the SRP protocol to be implemented using
 215    the standard sequence of handshake messages defined in [TLS].
 216
 217    The parameters to various messages are given in the following
 218    diagram.
 219
 220
 221
 222
 223 Taylor, et al.          Expires December 28, 2006               [Page 4]
 224 \f
 225 Internet-Draft      Using SRP for TLS Authentication           June 2006
 226
 227
 228    Client                                            Server
 229
 230    Client Hello (I)        -------->
 231                                                Server Hello
 232                                                Certificate*
 233                                         Server Key Exchange (N, g, s, B)
 234                            <--------      Server Hello Done
 235    Client Key Exchange (A) -------->
 236    [Change cipher spec]
 237    Finished                -------->
 238                                        [Change cipher spec]
 239                            <--------               Finished
 240
 241    Application Data        <------->       Application Data
 242
 243    * Indicates an optional message which is not always sent.
 244
 245    Figure 1
 246
 247 2.3.  Text Preparation
 248
 249    The user name and password strings shall be UTF-8 encoded Unicode,
 250    prepared using the [SASLPREP] profile of [STRINGPREP].
 251
 252 2.4.  SRP Verifier Creation
 253
 254    The verifier is calculated as described in section 3 of [SRP-RFC].
 255    We give the algorithm here for convenience.
 256
 257    The verifier (v) is computed based on the salt (s), user name (I),
 258    password (P), and group parameters (N, g).  The computation uses the
 259    [SHA1] hash algorithm:
 260
 261         x = SHA1(s | SHA1(I | ":" | P))
 262         v = g^x % N
 263
 264 2.5.  Changes to the Handshake Message Contents
 265
 266    This section describes the changes to the TLS handshake message
 267    contents when SRP is being used for authentication.  The definitions
 268    of the new message contents and the on-the-wire changes are given in
 269    Section 2.8.
 270
 271 2.5.1.  Client Hello
 272
 273    The user name is appended to the standard client hello message using
 274    the hello message extension mechanism defined in [TLSEXT] (see
 275    Section 2.8.1).
 276
 277
 278
 279 Taylor, et al.          Expires December 28, 2006               [Page 5]
 280 \f
 281 Internet-Draft      Using SRP for TLS Authentication           June 2006
 282
 283
 284 2.5.1.1.  Session Resumption
 285
 286    When a client attempts to resume a session that uses SRP
 287    authentication, the client MUST include the user name extension in
 288    the client hello message, in case the server cannot or will not allow
 289    session resumption, meaning a full handshake is required.
 290
 291    If the server does agree to resume an existing session the server
 292    MUST ignore the information in the SRP extension of the client hello
 293    message, except for its inclusion in the finished message hashes.
 294    This is to ensure attackers cannot replace the authenticated identity
 295    without supplying the proper authentication information.
 296
 297 2.5.1.2.  Missing SRP Username
 298
 299    The client may offer SRP ciphersuites in the hello message but omit
 300    the SRP extension.  If the server would like to select an SRP
 301    ciphersuite in this case, the server MAY return a
 302    "missing_srp_username" alert (see Section 2.9) immediately after
 303    processing the client hello message.  This alert signals the client
 304    to resend the hello message, this time with the SRP extension.  This
 305    allows the client to advertise that it supports SRP, but not have to
 306    prompt the user for his user name and password, nor expose the user
 307    name in the clear, unless necessary.
 308
 309    After sending the "missing_srp_username" alert, the server MUST leave
 310    the TLS connection open, yet reset its handshake protocol state so it
 311    is prepared to receive a second client hello message.  Upon receiving
 312    the "missing_srp_username" alert, the client MUST either send a
 313    second client hello message, or send a fatal user_cancelled alert.
 314
 315    If the client sends a second hello message, the second hello message
 316    MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
 317    the server MUST choose one of the SRP ciphersuites.  Both client
 318    hello messages MUST be treated as handshake messages and included in
 319    the hash calculations for the TLS Finished message.  The premaster
 320    and master secret calculations will use the random value from the
 321    second client hello message, not the first.
 322
 323 2.5.1.3.  Unknown SRP Username
 324
 325    If the server doesn't have a verifier for the given user name, the
 326    server MAY abort the handshake with an "unknown_srp_username" alert
 327    (see Section 2.9).  Alternatively, if the server wishes to hide the
 328    fact that this user name doesn't have a verifier, the server MAY
 329    simulate the protocol as if a verifier existed, but then reject the
 330    client's finished message with a "bad_record_mac" alert, as if the
 331    password was incorrect.
 332
 333
 334
 335 Taylor, et al.          Expires December 28, 2006               [Page 6]
 336 \f
 337 Internet-Draft      Using SRP for TLS Authentication           June 2006
 338
 339
 340    To simulate the existence of an entry for each user name, the server
 341    must consistently return the same salt (s) and group (N, g) values
 342    for the same user name.  For example, the server could store a secret
 343    "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
 344    generate the salts [HMAC].  For B, the server can return a random
 345    value between 1 and N-1 inclusive.  However, the server should take
 346    care to simulate computation delays.  One way to do this is to
 347    generate a fake verifier using the "seed key" approach, and then
 348    proceed with the protocol as usual.
 349
 350 2.5.2.  Server Certificate
 351
 352    The server MUST send a certificate if it agrees to an SRP cipher
 353    suite that requires the server to provide additional authentication
 354    in the form of a digital signature.  See Section 2.7 for details of
 355    which ciphersuites defined in this document require a server
 356    certificate to be sent.
 357
 358 2.5.3.  Server Key Exchange
 359
 360    The server key exchange message contains the prime (N), the generator
 361    (g), and the salt value (s) read from the SRP password file based on
 362    the user name (I) received in the client hello extension.
 363
 364    The server key exchange message also contains the server's public
 365    value (B).  The server calculates this value as B = k*v + g^b % N,
 366    where b is a random number which SHOULD be at least 256 bits in
 367    length, and k = SHA1(N | PAD(g)).
 368
 369    If the server has sent a certificate message, the server key exchange
 370    message MUST be signed.
 371
 372    The group parameters (N, g) sent in this message MUST have N as a
 373    safe prime (a prime of the form N=2q+1, where q is also prime).  The
 374    integers from 1 to N-1 will form a group under multiplication % N,
 375    and g MUST be a generator of this group.  In addition, the group
 376    parameters MUST NOT be specially chosen to allow efficient
 377    computation of discrete logarithms.
 378
 379    The SRP group parameters in Appendix A satisfy the above
 380    requirements, so the client SHOULD accept any parameters from this
 381    Appendix which have large enough N values to meet her security
 382    requirements.
 383
 384    The client MAY accept other group parameters from the server, if the
 385    client has reason to believe these parameters satisfy the above
 386    requirements, and the parameters have large enough N values.  For
 387    example, if the parameters transmitted by the server match parameters
 388
 389
 390
 391 Taylor, et al.          Expires December 28, 2006               [Page 7]
 392 \f
 393 Internet-Draft      Using SRP for TLS Authentication           June 2006
 394
 395
 396    on a "known-good" list, the client may choose to accept them.  See
 397    Section 3 for additional security considerations relevant to the
 398    acceptance of the group parameters.
 399
 400    Group parameters that are not accepted via one of the above methods
 401    MUST be rejected with an "untrusted_srp_parameters" alert (see
 402    Section 2.9).
 403
 404    The client MUST abort the handshake with an "illegal_parameter" alert
 405    if B % N = 0.
 406
 407 2.5.4.  Client Key Exchange
 408
 409    The client key exchange message carries the client's public value
 410    (A).  The client calculates this value as A = g^a % N, where a is a
 411    random number which SHOULD be at least 256 bits in length.
 412
 413    The server MUST abort the handshake with an "illegal_parameter" alert
 414    if A % N = 0.
 415
 416 2.6.  Calculating the Pre-master Secret
 417
 418    The pre-master secret is calculated by the client as follows:
 419
 420         I, P = <read from user>
 421         N, g, s, B = <read from server>
 422         a = random()
 423         A = g^a % N
 424         u = SHA1(PAD(A) | PAD(B))
 425         k = SHA1(N | PAD(g))
 426         x = SHA1(s | SHA1(I | ":" | P))
 427         <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
 428
 429    The pre-master secret is calculated by the server as follows:
 430
 431         N, g, s, v = <read from password file>
 432         b = random()
 433         k = SHA1(N | PAD(g))
 434         B = k*v + g^b % N
 435         A = <read from client>
 436         u = SHA1(PAD(A) | PAD(B))
 437         <premaster secret> = (A * v^u) ^ b % N
 438
 439    The finished messages perform the same function as the client and
 440    server evidence messages (M1 and M2) specified in [SRP-RFC].  If
 441    either the client or the server calculate an incorrect premaster
 442    secret, the finished messages will fail to decrypt properly, and the
 443    other party will return a "bad_record_mac" alert.
 444
 445
 446
 447 Taylor, et al.          Expires December 28, 2006               [Page 8]
 448 \f
 449 Internet-Draft      Using SRP for TLS Authentication           June 2006
 450
 451
 452    If a client application receives a "bad_record_mac" alert when
 453    performing an SRP handshake, it should inform the user that the
 454    entered user name and password are incorrect.
 455
 456 2.7.  Cipher Suite Definitions
 457
 458    The following cipher suites are added by this draft.  The usage of
 459    AES ciphersuites is as defined in [AESCIPH].
 460
 461       CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD5 };
 462
 463       CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD6
 464       };
 465
 466       CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD7
 467       };
 468
 469       CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0x00,0xTBD8 };
 470
 471       CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0x00,0xTBD9
 472       };
 473
 474       CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0xTBD10
 475       };
 476
 477       CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0x00,0xTBD11 };
 478
 479       CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0x00,0xTBD12
 480       };
 481
 482       CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0x00,0xTBD13
 483       };
 484
 485    Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
 486    require the server to send a certificate message containing a
 487    certificate with the specified type of public key, and to sign the
 488    server key exchange message using a matching private key.
 489
 490    Cipher suites that do not include a digital signature algorithm
 491    identifier assume the server is authenticated by its possesion of the
 492    SRP verifier.
 493
 494    Implementations conforming to this specification MUST implement the
 495    TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
 496    TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
 497    ciphersuites, and MAY implement the remaining ciphersuites.
 498
 499
 500
 501
 502
 503 Taylor, et al.          Expires December 28, 2006               [Page 9]
 504 \f
 505 Internet-Draft      Using SRP for TLS Authentication           June 2006
 506
 507
 508 2.8.  New Message Structures
 509
 510    This section shows the structure of the messages passed during a
 511    handshake that uses SRP for authentication.  The representation
 512    language used is the same as that used in [TLS].
 513
 514 2.8.1.  Client Hello
 515
 516    A new extension "srp" with value TBD1, has been added to the
 517    enumerated ExtensionType defined in [TLSEXT].  This value MUST be
 518    used as the extension number for the SRP extension.
 519
 520    The "extension_data" field of the SRP extension SHALL contain:
 521
 522         opaque srp_I<1..2^8-1>
 523
 524    where srp_I is the user name, encoded per Section 2.4.
 525
 526 2.8.2.  Server Key Exchange
 527
 528    A new value, "srp", has been added to the enumerated
 529    KeyExchangeAlgorithm originally defined in [TLS].
 530
 531    When the value of KeyExchangeAlgorithm is set to "srp", the server's
 532    SRP parameters are sent in the server key exchange message, encoded
 533    in a ServerSRPParams structure.
 534
 535    If a certificate is sent to the client the server key exchange
 536    message must be signed.
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559 Taylor, et al.          Expires December 28, 2006              [Page 10]
 560 \f
 561 Internet-Draft      Using SRP for TLS Authentication           June 2006
 562
 563
 564         enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
 565
 566         struct {
 567            select (KeyExchangeAlgorithm) {
 568               case diffie_hellman:
 569                  ServerDHParams params;
 570                  Signature signed_params;
 571               case rsa:
 572                  ServerRSAParams params;
 573                  Signature signed_params;
 574               case srp:   /* new entry */
 575                  ServerSRPParams params;
 576                  Signature signed_params;
 577            };
 578         } ServerKeyExchange;
 579
 580         struct {
 581            opaque srp_N<1..2^16-1>;
 582            opaque srp_g<1..2^16-1>;
 583            opaque srp_s<1..2^8-1>
 584            opaque srp_B<1..2^16-1>;
 585         } ServerSRPParams;     /* SRP parameters */
 586
 587 2.8.3.  Client Key Exchange
 588
 589    When the value of KeyExchangeAlgorithm is set to "srp", the client's
 590    public value (A) is sent in the client key exchange message, encoded
 591    in a ClientSRPPublic structure.
 592
 593         struct {
 594            select (KeyExchangeAlgorithm) {
 595               case rsa: EncryptedPreMasterSecret;
 596               case diffie_hellman: ClientDiffieHellmanPublic;
 597               case srp: ClientSRPPublic;   /* new entry */
 598            } exchange_keys;
 599         } ClientKeyExchange;
 600
 601         struct {
 602            opaque srp_A<1..2^16-1>;
 603         } ClientSRPPublic;
 604
 605 2.9.  Error Alerts
 606
 607    Three new error alerts are defined:
 608
 609    o  "unknown_srp_username" (TBD2) - this alert MAY be sent by a server
 610       that receives an unknown user name.  This alert is always fatal.
 611       See Section 2.5.1.3 for details.
 612
 613
 614
 615 Taylor, et al.          Expires December 28, 2006              [Page 11]
 616 \f
 617 Internet-Draft      Using SRP for TLS Authentication           June 2006
 618
 619
 620    o  "missing_srp_username" (TBD3) - this alert MAY be sent by a server
 621       that would like to select an offered SRP ciphersuite, if the SRP
 622       extension is absent from the client's hello message.  This alert
 623       is always a warning.  Upon receiving this alert, the client MAY
 624       send a new hello message on the same connection, this time
 625       including the SRP extension.  See Section 2.5.1.2 for details.
 626
 627    o  "untrusted_srp_parameters" (TBD4) - this alert MUST be sent by a
 628       client that receives unknown or untrusted (N, g) values.  This
 629       alert is always fatal.  See Section 2.5.3 for details.
 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 Taylor, et al.          Expires December 28, 2006              [Page 12]
 672 \f
 673 Internet-Draft      Using SRP for TLS Authentication           June 2006
 674
 675
 676 3.  Security Considerations
 677
 678    If an attacker is able to steal the SRP verifier file, the attacker
 679    can masquerade as the real server, and can also use dictionary
 680    attacks to recover client passwords.
 681
 682    An attacker could repeatedly contact an SRP server and try to guess a
 683    legitimate user's password.  Servers SHOULD take steps to prevent
 684    this, such as limiting the rate of authentication attempts from a
 685    particular IP address, or against a particular user account, or
 686    locking the user account once a threshold of failed attempts is
 687    reached.
 688
 689    The client's user name is sent in the clear in the Client Hello
 690    message.  To avoid sending the user name in the clear, the client
 691    could first open a conventional anonymous, or server-authenticated
 692    connection, then renegotiate an SRP-authenticated connection with the
 693    handshake protected by the first connection.
 694
 695    An attacker who could calculate discrete logarithms in the
 696    multiplicative group % N could compromise user passwords, and could
 697    also compromise the the confidentiality and integrity of TLS
 698    sessions.  Clients MUST ensure that the received parameter N is large
 699    enough to make calculating discrete logarithms computationally
 700    infeasible.
 701
 702    An attacker may try to send a prime value N which is large enough to
 703    be secure, but which has a special form for which the attacker can
 704    more easily compute discrete logarithms (e.g., using the algorithm
 705    discussed in [TRAPDOOR]).  If the client executes the protocol using
 706    such a prime, the client's password could be compromised.  Because of
 707    the difficulty of checking for such special primes in real-time,
 708    clients SHOULD only accept group parameters that come from a trusted
 709    source, such as those listed in Appendix A, or parameters configured
 710    locally by a trusted administrator.
 711
 712    The checks described in Section 2.5.3 and Section 2.5.4 on the
 713    received values for A and B are crucial for security and MUST be
 714    performed.
 715
 716    The private values a and b SHOULD be at least 256 bit random numbers,
 717    to give approximately 128 bits of security against certain methods of
 718    calculating discrete logarithms.
 719
 720    If the client receives a missing_srp_username alert, the client
 721    should be aware that unless the handshake protocol is run to
 722    completion, this alert may have been inserted by an attacker.  If the
 723    handshake protocol is not run to completion, the client should not
 724
 725
 726
 727 Taylor, et al.          Expires December 28, 2006              [Page 13]
 728 \f
 729 Internet-Draft      Using SRP for TLS Authentication           June 2006
 730
 731
 732    make any decisions, nor form any assumptions, based on receiving this
 733    alert.
 734
 735    It is possible to choose a (user name, password) pair such that the
 736    resulting verifier will also match other, related, (user name,
 737    password) pairs.  Thus, anyone using verifiers should be careful not
 738    to assume that only a single (user name, password) pair matches the
 739    verifier.
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783 Taylor, et al.          Expires December 28, 2006              [Page 14]
 784 \f
 785 Internet-Draft      Using SRP for TLS Authentication           June 2006
 786
 787
 788 4.  IANA Considerations
 789
 790    This document defines a new TLS extension "srp", assigned the value
 791    TBD1 (the value 6 is suggested) from the TLS ExtensionType registry
 792    defined in [TLSEXT].
 793
 794    The error alerts that are defined in this document are assigned to
 795    the TLS Alert registry defined in [TLS].  The alerts together with
 796    their assigned number (the values 120-122 are suggested) are shown
 797    below.
 798
 799    o  "unknown_srp_username" (TBD2)
 800
 801    o  "missing_srp_username" (TBD3)
 802
 803    o  "untrusted_srp_parameters" (TBD4)
 804
 805    IANA assigned the cipher suites' numbers to the Cipher Suite
 806    Registry, defined in [TLS].  The assigned values are listed below
 807    (the numbers between 0x50 to 0x58 are suggested).
 808
 809       CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD5 };
 810
 811       CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD6
 812       };
 813
 814       CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD7
 815       };
 816
 817       CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0x00,0xTBD8 };
 818
 819       CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0x00,0xTBD9
 820       };
 821
 822       CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0xTBD10
 823       };
 824
 825       CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0x00,0xTBD11 };
 826
 827       CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0x00,0xTBD12
 828       };
 829
 830       CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0x00,0xTBD13
 831       };
 832
 833
 834
 835
 836
 837
 838
 839 Taylor, et al.          Expires December 28, 2006              [Page 15]
 840 \f
 841 Internet-Draft      Using SRP for TLS Authentication           June 2006
 842
 843
 844 5.  References
 845
 846 5.1.  Normative References
 847
 848    [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol version
 849               1.1", RFC 4346, April 2006.
 850
 851    [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
 852               Remote Password Protocol", October 2002,
 853               <http://srp.stanford.edu/srp6.ps>.
 854
 855    [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
 856               and T. Wright, "TLS Extensions", RFC 3546, June 2003.
 857
 858    [STRINGPREP]
 859               Hoffman, P. and M. Blanchet, "Preparation of
 860               Internationalized Strings ("stringprep")", RFC 3454,
 861               December 2002.
 862
 863    [SASLPREP]
 864               Zeilenga, K., "SASLprep: Stringprep profile for user names
 865               and passwords", RFC 4013, February 2005.
 866
 867    [SRP-RFC]  Wu, T., "The SRP Authentication and Key Exchange System",
 868               RFC 2945, September 2000.
 869
 870    [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
 871               September 2000.
 872
 873    [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
 874               Hashing for Message Authentication", RFC 2104,
 875               February 1997.
 876
 877    [AESCIPH]  Chown, P., "Advanced Encryption Standard (AES)
 878               Ciphersuites for Transport Layer Security (TLS)",
 879               RFC 3268, June 2002.
 880
 881    [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
 882               (MODP) Diffie-Hellman groups for Internet Key Exchange
 883               (IKE)", RFC 3526, May 2003.
 884
 885 5.2.  Informative References
 886
 887    [IMAP]     Newman, C., "Using TLS with IMAP, POP3 and ACAP",
 888               RFC 2595, June 1999.
 889
 890    [SRP]      Wu, T., "The Secure Remote Password Protocol", Proceedings
 891               of the 1998 Internet Society Network and Distributed
 892
 893
 894
 895 Taylor, et al.          Expires December 28, 2006              [Page 16]
 896 \f
 897 Internet-Draft      Using SRP for TLS Authentication           June 2006
 898
 899
 900               System Security Symposium pp. 97-111, March 1998.
 901
 902    [TRAPDOOR]
 903               Gordon, D., "Designing and Detecting Trapdoors for
 904               Discrete Log Cryptosystems", Springer-Verlag Advances in
 905               Cryptology - Crypto '92, pp. 66-75, 1993.
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951 Taylor, et al.          Expires December 28, 2006              [Page 17]
 952 \f
 953 Internet-Draft      Using SRP for TLS Authentication           June 2006
 954
 955
 956 Appendix A.  SRP Group Parameters
 957
 958    The 1024, 1536, and 2048-bit groups are taken from software developed
 959    by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
 960    subsequently proven to be prime.  The larger primes are taken from
 961    [MODP], but generators have been calculated that are primitive roots
 962    of N, unlike the generators in [MODP].
 963
 964    The 1024-bit and 1536-bit groups MUST be supported.
 965
 966    1.  1024-bit Group
 967
 968        The hexadecimal value for the prime is:
 969
 970           EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
 971           9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
 972           8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
 973           7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
 974           FD5138FE 8376435B 9FC61D2F C0EB06E3
 975
 976
 977        The generator is: 2.
 978
 979
 980    2.  1536-bit Group
 981
 982        The hexadecimal value for the prime is:
 983
 984           9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
 985           4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
 986           80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
 987           E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
 988           6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
 989           F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
 990           8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
 991
 992
 993        The generator is: 2.
 994
 995
 996    3.  2048-bit Group
 997
 998        The hexadecimal value for the prime is:
 999
1000           AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
1001           3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
1002           CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
1003           D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
1004
1005
1006
1007 Taylor, et al.          Expires December 28, 2006              [Page 18]
1008 \f
1009 Internet-Draft      Using SRP for TLS Authentication           June 2006
1010
1011
1012           7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
1013           436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
1014           5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
1015           03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
1016           94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
1017           9E4AFF73
1018
1019
1020        The generator is: 2.
1021
1022
1023    4.  3072-bit Group
1024
1025        This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
1026        1690314 }
1027
1028        Its hexadecimal value is:
1029
1030           FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
1031           8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
1032           302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
1033           A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
1034           49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
1035           FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
1036           670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
1037           180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
1038           3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
1039           04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
1040           B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1041           1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
1042           BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
1043           E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
1044
1045
1046        The generator is: 5.
1047
1048
1049    5.  4096-bit Group
1050
1051        This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
1052        240904 }
1053
1054        Its hexadecimal value is:
1055
1056           FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
1057           8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
1058           302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
1059           A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
1060
1061
1062
1063 Taylor, et al.          Expires December 28, 2006              [Page 19]
1064 \f
1065 Internet-Draft      Using SRP for TLS Authentication           June 2006
1066
1067
1068           49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
1069           FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
1070           670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
1071           180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
1072           3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
1073           04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
1074           B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1075           1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
1076           BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
1077           E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
1078           99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
1079           04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
1080           233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
1081           D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
1082           FFFFFFFF FFFFFFFF
1083
1084
1085        The generator is: 5.
1086
1087
1088    6.  6144-bit Group
1089
1090        This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
1091        929484 }
1092
1093        Its hexadecimal value is:
1094
1095           FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
1096           8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
1097           302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
1098           A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
1099           49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
1100           FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
1101           670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
1102           180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
1103           3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
1104           04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
1105           B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1106           1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
1107           BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
1108           E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
1109           99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
1110           04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
1111           233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
1112           D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
1113           36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
1114           AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
1115           DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
1116
1117
1118
1119 Taylor, et al.          Expires December 28, 2006              [Page 20]
1120 \f
1121 Internet-Draft      Using SRP for TLS Authentication           June 2006
1122
1123
1124           2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
1125           F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
1126           BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
1127           CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
1128           B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
1129           387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
1130           6DCC4024 FFFFFFFF FFFFFFFF
1131
1132
1133        The generator is: 5.
1134
1135
1136    7.  8192-bit Group
1137
1138        This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
1139        4743158 }
1140
1141        Its hexadecimal value is:
1142
1143           FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
1144           8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
1145           302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
1146           A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
1147           49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
1148           FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
1149           670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
1150           180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
1151           3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
1152           04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
1153           B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1154           1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
1155           BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
1156           E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
1157           99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
1158           04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
1159           233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
1160           D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
1161           36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
1162           AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
1163           DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
1164           2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
1165           F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
1166           BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
1167           CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
1168           B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
1169           387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
1170           6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
1171           3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
1172
1173
1174
1175 Taylor, et al.          Expires December 28, 2006              [Page 21]
1176 \f
1177 Internet-Draft      Using SRP for TLS Authentication           June 2006
1178
1179
1180           5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
1181           22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
1182           2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
1183           6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
1184           0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
1185           359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
1186           FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
1187           60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
1188
1189
1190        The generator is: 19 (decimal).
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231 Taylor, et al.          Expires December 28, 2006              [Page 22]
1232 \f
1233 Internet-Draft      Using SRP for TLS Authentication           June 2006
1234
1235
1236 Appendix B.  SRP Test Vectors
1237
1238    The following test vectors demonstrate calculation of the verifier
1239    and premaster secret.
1240
1241       I = "alice"
1242
1243       P = "password123"
1244
1245       s = BEB25379 D1A8581E B5A72767 3A2441EE
1246
1247       N, g = <1024-bit parameters from Appendix A>
1248
1249       k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
1250
1251       x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
1252
1253       v =
1254
1255          7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
1256          9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
1257          C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
1258          EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
1259          E955A5E2 9E7AB245 DB2BE315 E2099AFB
1260
1261       a =
1262
1263          60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
1264          DA2D4393
1265
1266       b =
1267
1268          E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
1269          05284D20
1270
1271       A =
1272
1273          61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
1274          4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
1275          8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
1276          BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
1277          B349EF5D 76988A36 72FAC47B 0769447B
1278
1279       B =
1280
1281          BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
1282          BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
1283          6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
1284
1285
1286
1287 Taylor, et al.          Expires December 28, 2006              [Page 23]
1288 \f
1289 Internet-Draft      Using SRP for TLS Authentication           June 2006
1290
1291
1292          37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
1293          EB4012B7 D7665238 A8E3FB00 4B117B58
1294
1295       u =
1296
1297          CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
1298
1299       <premaster secret> =
1300
1301          B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
1302          233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
1303          41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
1304          3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
1305          C346D7E4 74B29EDE 8A469FFE CA686E5A
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343 Taylor, et al.          Expires December 28, 2006              [Page 24]
1344 \f
1345 Internet-Draft      Using SRP for TLS Authentication           June 2006
1346
1347
1348 Appendix C.  Acknowledgements
1349
1350    Thanks to all on the IETF TLS mailing list for ideas and analysis.
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399 Taylor, et al.          Expires December 28, 2006              [Page 25]
1400 \f
1401 Internet-Draft      Using SRP for TLS Authentication           June 2006
1402
1403
1404 Authors' Addresses
1405
1406    David Taylor
1407    Independent
1408
1409    Email: dtaylor@gnutls.org
1410
1411
1412    Tom Wu
1413    Stanford University
1414
1415    Email: tjw@cs.stanford.edu
1416
1417
1418    Nikos Mavrogiannopoulos
1419    Independent
1420
1421    Email: nmav@gnutls.org
1422    URI:   http://www.gnutls.org/
1423
1424
1425    Trevor Perrin
1426    Independent
1427
1428    Email: trevp@trevp.net
1429    URI:   http://trevp.net/
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455 Taylor, et al.          Expires December 28, 2006              [Page 26]
1456 \f
1457 Internet-Draft      Using SRP for TLS Authentication           June 2006
1458
1459
1460 Intellectual Property Statement
1461
1462    The IETF takes no position regarding the validity or scope of any
1463    Intellectual Property Rights or other rights that might be claimed to
1464    pertain to the implementation or use of the technology described in
1465    this document or the extent to which any license under such rights
1466    might or might not be available; nor does it represent that it has
1467    made any independent effort to identify any such rights.  Information
1468    on the procedures with respect to rights in RFC documents can be
1469    found in BCP 78 and BCP 79.
1470
1471    Copies of IPR disclosures made to the IETF Secretariat and any
1472    assurances of licenses to be made available, or the result of an
1473    attempt made to obtain a general license or permission for the use of
1474    such proprietary rights by implementers or users of this
1475    specification can be obtained from the IETF on-line IPR repository at
1476    http://www.ietf.org/ipr.
1477
1478    The IETF invites any interested party to bring to its attention any
1479    copyrights, patents or patent applications, or other proprietary
1480    rights that may cover technology that may be required to implement
1481    this standard.  Please address the information to the IETF at
1482    ietf-ipr@ietf.org.
1483
1484
1485 Disclaimer of Validity
1486
1487    This document and the information contained herein are provided on an
1488    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1489    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1490    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1491    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1492    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1493    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1494
1495
1496 Copyright Statement
1497
1498    Copyright (C) The Internet Society (2006).  This document is subject
1499    to the rights, licenses and restrictions contained in BCP 78, and
1500    except as set forth therein, the authors retain all their rights.
1501
1502
1503 Acknowledgment
1504
1505    Funding for the RFC Editor function is currently provided by the
1506    Internet Society.
1507
1508
1509
1510
1511 Taylor, et al.          Expires December 28, 2006              [Page 27]
1512 \f