doc/protocol/draft-rescorla-tls-suiteb-00.txt

   1
   2
   3
   4 Network Working Group                                          M. Salter
   5 Internet-Draft                                  National Security Agency
   6 Expires:  June 16, 2007                                      E. Rescorla
   7                                                        Network Resonance
   8                                                        December 13, 2006
   9
  10
  11                       SuiteB CipherSuites for TLS
  12                     draft-rescorla-tls-suiteb-00.txt
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37    This Internet-Draft will expire on June 16, 2007.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2006).
  42
  43 Abstract
  44
  45    RFC 4492 describes elliptic curve cipher suites for Transport Layer
  46    Security (TLS).  However, all those cipher suites use SHA-1 as their
  47    MAC algorithm, which makes them unsuitable for some applications.
  48    This document describes eight new CipherSuites for TLS/DTLS which
  49    specify stronger digest algorithms and therefore are suitable for use
  50    in applications which require compliance with the United States
  51    Government's guidelines for "NSA Suite B Cryptography" dated July,
  52
  53
  54
  55 Salter & Rescorla         Expires June 16, 2007                 [Page 1]
  56 \f
  57 Internet-Draft               SuiteB for TLS                December 2006
  58
  59
  60    2005.
  61
  62
  63 Table of Contents
  64
  65    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  66    2.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
  67    3.  SuiteB Requirements  . . . . . . . . . . . . . . . . . . . . .  3
  68    4.  Cipher Suites  . . . . . . . . . . . . . . . . . . . . . . . .  4
  69      4.1.  HMAC-based Cipher Suites . . . . . . . . . . . . . . . . .  4
  70      4.2.  Galois Counter Mode-based Cipher Suites  . . . . . . . . .  5
  71    5.  Suite B Compliance Requirements  . . . . . . . . . . . . . . .  6
  72      5.1.  Security Levels  . . . . . . . . . . . . . . . . . . . . .  6
  73      5.2.  Acceptable Curves  . . . . . . . . . . . . . . . . . . . .  6
  74    6.  TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . .  7
  75    7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
  76      7.1.  Downgrade Attack . . . . . . . . . . . . . . . . . . . . .  7
  77      7.2.  Perfect Forward Secrecy  . . . . . . . . . . . . . . . . .  8
  78      7.3.  Counter Reuse with GCM . . . . . . . . . . . . . . . . . .  8
  79    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
  80    9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
  81    10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  82      10.1. Normative References . . . . . . . . . . . . . . . . . . .  8
  83      10.2. Informative References . . . . . . . . . . . . . . . . . .  9
  84    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
  85    Intellectual Property and Copyright Statements . . . . . . . . . . 11
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Salter & Rescorla         Expires June 16, 2007                 [Page 2]
 112 \f
 113 Internet-Draft               SuiteB for TLS                December 2006
 114
 115
 116 1.  Introduction
 117
 118    In July, 2005 the National Security Agency posted "Fact Sheet, NSA
 119    Suite B Cryptography" which stated:
 120
 121        To complement the existing policy for the use of the Advanced
 122        Encryption Standard (AES) to protect national security systems
 123        and information as specified in The National Policy on the use of
 124        the Advanced Encryption Standard (AES) to Protect National
 125        Security Systems and National Security Information (CNSSP-15),
 126        the National Security Agency (NSA) announced Suite B Cryptography
 127        at the 2005 RSA Conference.  In addition to the AES, Suite B
 128        includes cryptographic algorithms for hashing, digital
 129        signatures, and key exchange.
 130
 131        Suite B only specifies the cryptographic algorithms to be
 132        used. Many other factors need to be addressed in determining
 133        whether a particular device implementing a particular set of
 134        cryptographic algorithms should be used to satisfy a particular
 135        requirement.
 136
 137    Among those factors are "requirements for interoperability both
 138    domestically and internationally".
 139
 140    This document is intended to address those requirements in the
 141    particular case of TLS [RFC4346] and Datagram TLS [RFC4347].  Much of
 142    what is needed to define the Suite B CipherSuites is specified in RFC
 143    4492 "ECC for TLS" [RFC4492].  We use the terminology, notation, and
 144    details from that document to the extent possible.  A key ingredient
 145    of SuiteB not found in RFC4492--or the definition of TLS itself prior
 146    to 1.2--is the use of SHA256 or SHA384 for key derivation.  TLS 1.2
 147    [I-D.ietf-tls-rfc4346-bis] allows for the use of these hash in the
 148    pseudo-random function (PRF) used to derive the keys.
 149
 150    Unless specifically stated herein, details of the protocol are
 151    identical to those given in [I-D.ietf-tls-rfc4346-bis] and [RFC4492]
 152
 153
 154 2.  Conventions Used In This Document
 155
 156    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 157    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 158    document are to be interpreted as described in [RFC2119].
 159
 160
 161 3.  SuiteB Requirements
 162
 163    The "Suite B Fact Sheet" requires that key establishment and
 164
 165
 166
 167 Salter & Rescorla         Expires June 16, 2007                 [Page 3]
 168 \f
 169 Internet-Draft               SuiteB for TLS                December 2006
 170
 171
 172    authentication algorithms be based on Elliptic Curve Cryptography,
 173    that the encryption algorithm be AES [AES], and that the function
 174    used for key derivation and data integrity be SHA [SHS].  It defines
 175    two security levels, of 128 and 192 bits.
 176
 177    In particular it states:
 178
 179       SUITE B includes:
 180
 181         Encryption:          Advanced Encryption Standard (AES)  -
 182                              FIPS 197 with keys sizes of 128 and 256
 183                              bits)
 184
 185         Digital Signature:   Elliptic Curve Digital Signature Algorithm -
 186                              FIPS 186-2 (using the curves with 256 and
 187                              384-bit prime moduli)
 188
 189         Key Exchange:        Elliptic Curve Diffie-Hellman or Elliptic
 190                              Curve MQV Draft NIST Special Publication
 191                              800-56 (using the curves with 256 and
 192                              384-bit prime moduli)
 193
 194         Hashing:             Secure Hash Algorithm - FIPS 180-2
 195                              (using SHA-256 and SHA-384)
 196
 197       All implementations of Suite B must, at a minimum, include AES
 198       with 128-bit keys, the 256-bit prime modulus elliptic curve and
 199       SHA-256 as a common mode for widespread interoperability.
 200
 201    The 128-bit security level corresponds to an elliptic curve size of
 202    256 bits, AES-128, and SHA-256.  The 192-bit security level
 203    corresponds to an elliptic curve size of 384 bits, AES-256, and SHA-
 204    384.  Because both settings require a digest algorithm other than
 205    SHA-1, new cipher suites are required and defined in this document.
 206
 207
 208 4.  Cipher Suites
 209
 210    This document defines 8 new cipher suites to be added to TLS.  All
 211    use Elliptic Curve Cryptography for key exchange and digital
 212    signature, as defined in RFC 4492.
 213
 214 4.1.  HMAC-based Cipher Suites
 215
 216    The first four cipher suites use AES in CBC mode with an HMAC-based
 217    MAC:
 218
 219
 220
 221
 222
 223 Salter & Rescorla         Expires June 16, 2007                 [Page 4]
 224 \f
 225 Internet-Draft               SuiteB for TLS                December 2006
 226
 227
 228         CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX}
 229         CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX}
 230         CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX}
 231         CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX}
 232
 233    These four cipher suites are the same as the corresponding cipher
 234    suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
 235    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
 236    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
 237    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except that SHA-256 is used for
 238    the MAC with AES-128 and SHA-384 is used for the MAC with AES-256.
 239    As described in TLS 1.2, the digest used for the MAC MUST also be
 240    used in the PRF.
 241
 242 4.2.  Galois Counter Mode-based Cipher Suites
 243
 244    The second four cipher suites use the new authenticated encryption
 245    modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
 246
 247         CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX}
 248         CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX}
 249         CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX}
 250         CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX}
 251
 252    These cipher suites use the authenticated encryption with additional
 253    data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
 254    [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
 255    be 12 bytes long, and constructed as follows:
 256
 257              struct {
 258                 case client:
 259                     uint32 client_write_IV;  // low order 32-bits
 260                 case server:
 261                     uint32 server_write_IV;  // low order 32-bits
 262                 uint64 seq_num;
 263              } GCMNonce.
 264
 265    In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
 266    48-bit seq_num.
 267
 268    This construction allows the internal counter to be 32-bits long,
 269    which is the most convenient size for use with GCM.
 270
 271    Note:  the role played by the client_write_IV and server_write_IV is
 272    often called "salt" in counter mode specifications [RFC3686].
 273
 274    Because GCM does not use HMAC as a MAC function, the hash function
 275    for the TLS PRF must be explicitly specified.
 276
 277
 278
 279 Salter & Rescorla         Expires June 16, 2007                 [Page 5]
 280 \f
 281 Internet-Draft               SuiteB for TLS                December 2006
 282
 283
 284    For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
 285    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be SHA-256.
 286
 287    For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
 288    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be SHA-384.
 289
 290
 291 5.  Suite B Compliance Requirements
 292
 293    The following requirements apply only to SuiteB compliant
 294    implementations.  However, ordinary TLS implementations MAY use these
 295    cipher suites even if they do not comply with the requirements in
 296    this section.
 297
 298    To be considered "SuiteB compatible" at least one of the CipherSuites
 299    defined in this document MUST be negotiated.  In compliance with the
 300    guidance in the Suite B Fact Sheet every TLS implementation of SuiteB
 301    SHOULD implement TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
 302
 303 5.1.  Security Levels
 304
 305    As described in Section 1, Suite B specifies two security levels, 128
 306    and 192 bit.  The following table lists the security levels for each
 307    cipher suite:
 308
 309        +-----------------------------------------+----------------+
 310        | Cipher Suite                            | Security Level |
 311        +-----------------------------------------+----------------+
 312        | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | 128            |
 313        | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | 192            |
 314        | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256  | 128            |
 315        | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384  | 192            |
 316        | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128            |
 317        | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192            |
 318        | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256  | 128            |
 319        | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384  | 192            |
 320        +-----------------------------------------+----------------+
 321
 322 5.2.  Acceptable Curves
 323
 324    RFC 4492 defines a variety of elliptic curves.  For cipher suites
 325    defined in this specification, only secp256r1 (23) or secp384r1 (24)
 326    may be used.  (These are the same curves that appear in FIPS 186-2
 327    and ANSI X9.62 as P256 and P384, respectively).  For cipher suites at
 328    the 128-bit security level, secp256r1 MUST be used.  For cipher
 329    suites at the 192-bit security level, secp256r MUST be used.  Both
 330    uncompressed (0) and ansiX962_compressed_prime(1) point formats
 331    SHOULD be supported.
 332
 333
 334
 335 Salter & Rescorla         Expires June 16, 2007                 [Page 6]
 336 \f
 337 Internet-Draft               SuiteB for TLS                December 2006
 338
 339
 340    Clients desiring to negotiate only a SuiteB-compliant connection MUST
 341    generate a "Supported Elliptic Curves Extension" containing only the
 342    allowed curves.  These curves MUST match the cipher suite security
 343    levels being offered.  Clients which are willing to do both SuiteB-
 344    compliant and non-SuiteB-compliant connections MAY omit the extension
 345    or send the extension but offer other curves as well as the
 346    appropriate SuiteB ones.
 347
 348    Servers desiring to negotiate a SuiteB-compliant connection SHOULD
 349    check for the presence of the extension, but MUST NOT negotiate
 350    inappropriate curves even if they are offered by the client.  This
 351    allows a Client which is willing to do either SuiteB-compliant or
 352    non-SuiteB-compliant modes to interoperate with a server which will
 353    only do SuiteB-compliant modes.  If the client does not advertise an
 354    acceptable curve, the server MUST generate a fatal
 355    "handshake_failure" alert and terminate the connection.  Clients
 356    SHOULD check the chosen curve to make sure it is acceptable.
 357
 358
 359 6.  TLS Versions
 360
 361    Because these cipher suites depend on features available only in TLS
 362    1.2 (PRF flexibility and combined authenticated encryption cipher
 363    modes), they MUST NOT be negotiated in older versions of TLS.
 364    Clients MUST NOT offer these cipher suites if they do not offer TLS
 365    1.2 or later.  Servers which select an earlier version of TLS MUST
 366    NOT select one of these cipher suites.  Because TLS has no way for
 367    the client to indicate that it supports TLS 1.2 but not earlier, a
 368    non-compliant server might potentially negotiate TLS 1.1 or earlier
 369    and select one of the cipher suites in this document.  Clients MUST
 370    check the TLS version and generate a fatal "illegal_parameter" alert
 371    if they detect an incorrect version.
 372
 373
 374 7.  Security Considerations
 375
 376    The security considerations in RFC 4346 and RFC 4492 apply to this
 377    document as well.  The remainder of this section describes security
 378    considerations specific to the cipher suites described in this
 379    document.
 380
 381 7.1.  Downgrade Attack
 382
 383    TLS negotiation is only as secure as the weakest cipher suite that is
 384    supported.  For instance, an implementation which supports both 160-
 385    bit and 256-bit elliptic curves can be subject to an active downgrade
 386    attack to the 160-bit security level.  An attacker who can attack
 387    that can then forge the Finished handshake check and successfully
 388
 389
 390
 391 Salter & Rescorla         Expires June 16, 2007                 [Page 7]
 392 \f
 393 Internet-Draft               SuiteB for TLS                December 2006
 394
 395
 396    mount a man-in-the-middle attack.
 397
 398    In environments where there is a concern about this form of attack,
 399    implementations SHOULD only offer cipher suites which are as strong
 400    as their minimum acceptable security level.
 401
 402 7.2.  Perfect Forward Secrecy
 403
 404    The static ECDH cipher suites specified in this document do not
 405    provide perfect forward secrecy (PFS).  Thus, compromise of a single
 406    static key leads to potential decryption of all traffic protected
 407    using that key.  Implementors of this specification SHOULD provide at
 408    least one ECDHE mode of operation.
 409
 410 7.3.  Counter Reuse with GCM
 411
 412    AES-GCM is only secure if the counter is never reused.  The IV
 413    construction algorithm above is designed to ensure that that cannot
 414    happen.
 415
 416
 417 8.  IANA Considerations
 418
 419    IANA has assigned the following values for the SuiteB cipher suites:
 420
 421       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX}
 422       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX}
 423       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX}
 424       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX}
 425       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX}
 426       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX}
 427       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX}
 428       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX}
 429
 430
 431 9.  Acknowledgements
 432
 433    This work was supported by the US Department of Defense.
 434
 435
 436 10.  References
 437
 438 10.1.  Normative References
 439
 440    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 441               Requirement Levels", BCP 14, RFC 2119, March 1997.
 442
 443    [RFC3686]  Housley, R., "Using Advanced Encryption Standard (AES)
 444
 445
 446
 447 Salter & Rescorla         Expires June 16, 2007                 [Page 8]
 448 \f
 449 Internet-Draft               SuiteB for TLS                December 2006
 450
 451
 452               Counter Mode With IPsec Encapsulating Security Payload
 453               (ESP)", RFC 3686, January 2004.
 454
 455    [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
 456               (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 457
 458    [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 459               Security", RFC 4347, April 2006.
 460
 461    [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
 462               Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
 463               for Transport Layer Security (TLS)", RFC 4492, May 2006.
 464
 465    [I-D.mcgrew-auth-enc]
 466               McGrew, D., "An Interface and Algorithms for Authenticated
 467               Encryption", draft-mcgrew-auth-enc-01 (work in progress),
 468               October 2006.
 469
 470    [I-D.ietf-tls-rfc4346-bis]
 471               Dierks, T. and E. Rescorla, "The TLS Protocol Version
 472               1.2", draft-ietf-tls-rfc4346-bis-02 (work in progress),
 473               October 2006.
 474
 475    [I-D.ietf-tls-ctr]
 476               Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher
 477               Suites for TLS and DTLS", draft-ietf-tls-ctr-01 (work in
 478               progress), June 2006.
 479
 480    [AES]      National Institute of Standards and Technology,
 481               "Specification for the Advanced Encryption Standard
 482               (AES)", FIPS 197, November 2001.
 483
 484    [SHS]      National Institute of Standards and Technology, "Secure
 485               Hash Standard", FIPS 180-2, August 2002.
 486
 487    [GCM]      National Institute of Standards and Technology,
 488               "Recommendation for Block Cipher Modes of Operation:
 489               Galois;/Counter Mode (GCM) for Confidentiality and
 490               Authentication", SP 800-38D, April 2006.
 491
 492 10.2.  Informative References
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503 Salter & Rescorla         Expires June 16, 2007                 [Page 9]
 504 \f
 505 Internet-Draft               SuiteB for TLS                December 2006
 506
 507
 508 Authors' Addresses
 509
 510    Margaret Salter
 511    National Security Agency
 512    9800 Savage Rd.
 513    Fort Meade  20755-6709
 514    USA
 515
 516    Email:  msalter@restarea.ncsc.mil
 517
 518
 519    Eric Rescorla
 520    Network Resonance
 521    2483 E. Bayshore #212
 522    Palo Alto  94303
 523    USA
 524
 525    Email:  ekr@networkresonance.com
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559 Salter & Rescorla         Expires June 16, 2007                [Page 10]
 560 \f
 561 Internet-Draft               SuiteB for TLS                December 2006
 562
 563
 564 Intellectual Property Statement
 565
 566    The IETF takes no position regarding the validity or scope of any
 567    Intellectual Property Rights or other rights that might be claimed to
 568    pertain to the implementation or use of the technology described in
 569    this document or the extent to which any license under such rights
 570    might or might not be available; nor does it represent that it has
 571    made any independent effort to identify any such rights.  Information
 572    on the procedures with respect to rights in RFC documents can be
 573    found in BCP 78 and BCP 79.
 574
 575    Copies of IPR disclosures made to the IETF Secretariat and any
 576    assurances of licenses to be made available, or the result of an
 577    attempt made to obtain a general license or permission for the use of
 578    such proprietary rights by implementers or users of this
 579    specification can be obtained from the IETF on-line IPR repository at
 580    http://www.ietf.org/ipr.
 581
 582    The IETF invites any interested party to bring to its attention any
 583    copyrights, patents or patent applications, or other proprietary
 584    rights that may cover technology that may be required to implement
 585    this standard.  Please address the information to the IETF at
 586    ietf-ipr@ietf.org.
 587
 588
 589 Disclaimer of Validity
 590
 591    This document and the information contained herein are provided on an
 592    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 593    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 594    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 595    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 596    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 597    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 598
 599
 600 Copyright Statement
 601
 602    Copyright (C) The Internet Society (2006).  This document is subject
 603    to the rights, licenses and restrictions contained in BCP 78, and
 604    except as set forth therein, the authors retain all their rights.
 605
 606
 607 Acknowledgment
 608
 609    Funding for the RFC Editor function is currently provided by the
 610    Internet Society.
 611
 612
 613
 614
 615 Salter & Rescorla         Expires June 16, 2007                [Page 11]
 616 \f
 617