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

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