doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-00.txt

   1 TLS Working Group                                         Mohamad Badra
   2 Internet Draft                                         LIMOS Laboratory
   3 Intended status: Standards Track                         March 29, 2008
   4 Expires: September 2008
   5
   6
   7
   8          Pre-Shared Key Cipher Suites for Transport Layer Security
   9                with SHA-256/384 and AES Galois Counter Mode
  10                 draft-badra-tls-psk-new-mac-aes-gcm-00.txt
  11
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six
  26    months and may be updated, replaced, or obsoleted by other documents
  27    at any time.  It is inappropriate to use Internet-Drafts as
  28    reference material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html
  35
  36    This Internet-Draft will expire on September 29, 2008.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The IETF Trust (2008).
  41
  42 Abstract
  43
  44    RFC 4279 and RFC 4785 describe pre-shared key cipher suites for
  45    Transport Layer Security (TLS).  However, all those cipher suites
  46    use SHA-1 as their MAC algorithm.  This document describes a set of
  47    cipher suites for TLS/DTLS which uses stronger digest algorithms
  48
  49
  50
  51
  52 Badra                 Expires September 29, 2008               [Page 1]
  53 \f
  54 Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008
  55
  56
  57    (i.e. SHA-256 or SHA-384) and another which uses AES in Galois
  58    Counter Mode (GCM).
  59
  60 Table of Contents
  61
  62
  63    1. Introduction...................................................3
  64       1.1. Conventions used in this document.........................3
  65    2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM..3
  66    3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384.........4
  67       3.1. PSK Key Exchange Algorithm with SHA-256/384...............4
  68       3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384...........5
  69       3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384...........5
  70    4. TLS Versions...................................................6
  71    5. Security Considerations........................................6
  72       5.1. Counter Reuse with GCM....................................6
  73       5.2. Recommendations for Multiple Encryption Processors........6
  74    6. IANA Considerations............................................7
  75    7. Acknowledgments................................................8
  76    8. References.....................................................8
  77       8.1. Normative References......................................8
  78       8.2. Informative References....................................9
  79    Author's Addresses................................................9
  80    Intellectual Property Statement..................................10
  81    Disclaimer of Validity...........................................10
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106 Badra                 Expires September 29, 2008               [Page 2]
 107 \f
 108 Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008
 109
 110
 111 1. Introduction
 112
 113    This document describes the use of AES [AES] in Galois Counter Mode
 114    (GCM) [GCM] (AES-GCM) with various pre-shared key (PSK) key exchange
 115    mechanisms ([RFC4279] and [RFC4785]) as a ciphersuite for Transport
 116    Layer Security (TLS).  AES-GCM is not only efficient and secure, but
 117    hardware implementations can achieve high speeds with low cost and
 118    low latency, because the mode can be pipelined.
 119
 120    This document also specifies PSK cipher suites for TLS which replace
 121    SHA-256 and SHA-384 rather than SHA-1. RFC 4279 [RFC4279] and RFC
 122    4785 [RFC4785] describe pre-shared key (PSK) cipher suites for TLS.
 123    However, all of the RFC 4279 and the RFC 4785 suites use HMAC-SHA1
 124    as their MAC algorithm.  Due to recent analytic work on SHA-1
 125    [Wang05], the IETF is gradually moving away from SHA-1 and towards
 126    stronger hash algorithms.
 127
 128    [I-D.ietf-tls-ecc-new-mac] and [I-D.ietf-tls-rsa-aes-gcm] provide
 129    support for GCM with other key establishment methods.
 130
 131 1.1. Conventions used in this document
 132
 133    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 134    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 135    document are to be interpreted as described in [RFC2119].
 136
 137 2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM
 138
 139    The following eight cipher suites use the new authenticated
 140    encryption modes defined in TLS 1.2 with AES in Galois Counter Mode
 141    (GCM) [GCM]:
 142
 143       CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX};
 144       CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX};
 145       CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX};
 146       CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX};
 147       CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX};
 148       CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX};
 149       CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX};
 150       CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX};
 151
 152    These cipher suites use authenticated encryption with additional
 153    data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
 154    RFC 5116.  The "nonce" input to the AEAD algorithm SHALL be 12 bytes
 155    long, and is "partially implicit" (see Section 3.2.1 of RFC 5116).
 156    Part of the nonce is generated as part of the handshake process and
 157    is static for the entire session and part is carried in each packet.
 158
 159
 160 Badra                 Expires September 29, 2008               [Page 3]
 161 \f
 162 Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008
 163
 164
 165                 struct {
 166                    opaque salt[4];
 167                    opaque explicit_nonce_part[8];
 168                 } GCMNonce.
 169
 170    The salt value is either the client_write_IV if the client is
 171    sending or the server_write_IV if the server is sending.  These IVs
 172    SHALL be 4 bytes long.  Therefore, for all the algorithms defined in
 173    this section, SecurityParameters.fixed_iv_length=4.
 174
 175    The explicit_nonce_part is chosen by the sender and included in the
 176    packet.  Each value of the explicit_nonce_part MUST be distinct from
 177    all other values, for any fixed key.  Failure to meet this
 178    uniqueness requirement can significantly degrade security.  The
 179    explicit_nonce_part is carried in the IV field of the
 180    GenericAEADCipher structure.  Therefore, for all the algorithms
 181    defined in this section, SecurityParameters.record_iv_length=8.
 182
 183    In the case of TLS the counter MAY be the 64-bit sequence number.
 184    In the case of Datagram TLS [RFC4347] the counter MAY be formed from
 185    the concatenation of the 16-bit epoch with the 48-bit sequence
 186    number.
 187
 188    The PRF algorithms SHALL be as follows:
 189
 190    For ciphersuites ending in _SHA256 the hash function is SHA256.
 191
 192    For ciphersuites ending in _SHA384 the hash function is SHA384.
 193
 194 3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384
 195
 196    The cipher suites described in this section use AES [AES] in CBC
 197    [CBC] mode with an HMAC-based MAC.
 198
 199 3.1. PSK Key Exchange Algorithm with SHA-256/384
 200
 201       CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX};
 202       CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX};
 203       CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX};
 204       CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX};
 205       CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX};
 206       CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX};
 207
 208    The above six cipher suites are the same as the corresponding cipher
 209    suites in RFC 4279 and RFC 4785 (TLS_PSK_WITH_AES_128_CBC_SHA,
 210    TLS_PSK_WITH_AES_256_CBC_SHA, and TLS_PSK_WITH_NULL_SHA) except for
 211
 212
 213
 214 Badra                 Expires September 29, 2008               [Page 4]
 215 \f
 216 Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008
 217
 218
 219    the hash and PRF algorithms, which are SHA-256 and SHA-384 [SHS] as
 220    follows.
 221
 222    Cipher Suite                             MAC             PRF
 223    ------------                             ---             ---
 224    TLS_PSK_WITH_AES_128_CBC_SHA256          HMAC-SHA-256    P_SHA-256
 225    TLS_PSK_WITH_AES_128_CBC_SHA384          HMAC-SHA-384    P_SHA-384
 226    TLS_PSK_WITH_AES_256_CBC_SHA256          HMAC-SHA-256    P_SHA-256
 227    TLS_PSK_WITH_AES_256_CBC_SHA384          HMAC-SHA-384    P_SHA-384
 228    TLS_PSK_WITH_NULL_SHA256                 HMAC-SHA-256    P_SHA-256
 229    TLS_PSK_WITH_NULL_SHA384                 HMAC-SHA-384    P_SHA-384
 230
 231 3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384
 232
 233       CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};
 234       CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX};
 235       CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};
 236       CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX};
 237       CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};
 238       CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX};
 239
 240    The above six cipher suites are the same as the corresponding cipher
 241    suites in RFC 4279 and RFC 4785 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA,
 242    TLS_DHE_PSK_WITH_AES_256_CBC_SHA, and TLS_DHE_PSK_WITH_NULL_SHA)
 243    except for the hash and PRF algorithms, which are SHA-256 and SHA-
 244    384 [SHS] as follows.
 245
 246    Cipher Suite                             MAC             PRF
 247    ------------                             ---             ---
 248    TLS_DHE_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256
 249    TLS_DHE_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384
 250    TLS_DHE_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256
 251    TLS_DHE_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384
 252
 253 3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384
 254
 255       CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256    = {0xXX,0xXX};
 256       CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384    = {0xXX,0xXX};
 257       CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256    = {0xXX,0xXX};
 258       CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384    = {0xXX,0xXX};
 259
 260    The above four cipher suites are the same as the corresponding
 261    cipher suites in RFC 4279 and RFC 4785
 262    (TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_RSA_PSK_WITH_AES_256_CBC_SHA,
 263    and TLS_RSA_PSK_WITH_NULL_SHA) except for the hash and PRF
 264    algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
 265
 266
 267
 268 Badra                 Expires September 29, 2008               [Page 5]
 269 \f
 270 Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008
 271
 272
 273    Cipher Suite                             MAC             PRF
 274    ------------                             ---             ---
 275    TLS_RSA_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256
 276    TLS_RSA_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384
 277    TLS_RSA_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256
 278    TLS_RSA_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384
 279
 280 4. TLS Versions
 281
 282    Because these cipher suites depend on features available only in TLS
 283    1.2 (PRF flexibility and combined authenticated encryption cipher
 284    modes), they MUST NOT be negotiated by older versions of TLS.
 285    Clients MUST NOT offer these cipher suites if they do not offer TLS
 286    1.2 or later.  Servers which select an earlier version of TLS MUST
 287    NOT select one of these cipher suites.  Because TLS has no way for
 288    the client to indicate that it supports TLS 1.2 but not earlier, a
 289    non-compliant server might potentially negotiate TLS 1.1 or earlier
 290    and select one of the cipher suites in this document.  Clients MUST
 291    check the TLS version and generate a fatal "illegal_parameter" alert
 292    if they detect an incorrect version.
 293
 294 5. Security Considerations
 295
 296    The security considerations in [I-D.ietf-tls-rfc4346-bis], RFC 4279
 297    and RFC 4785 apply to this document as well.  The remainder of this
 298    section describes security considerations specific to the cipher
 299    suites described in this document.
 300
 301 5.1. Counter Reuse with GCM
 302
 303    AES-GCM is only secure if the counter is never reused.  The IV
 304    construction algorithm above is designed to ensure that this cannot
 305    happen.
 306
 307 5.2. Recommendations for Multiple Encryption Processors
 308
 309    If multiple cryptographic processors are in use by the sender, then
 310    the sender MUST ensure that, for a particular key, each value of the
 311    explicit_nonce_part used with that key is distinct.  In this case
 312    each encryption processor SHOULD include in the explicit_nonce_part
 313    a fixed value that is distinct for each processor.  The recommended
 314    format is
 315
 316         explicit_nonce_part = FixedDistinct || Variable
 317
 318    where the FixedDistinct field is distinct for each encryption
 319    processor, but is fixed for a given processor, and the Variable
 320
 321
 322 Badra                 Expires September 29, 2008               [Page 6]
 323 \f
 324 Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008
 325
 326
 327    field is distinct for each distinct nonce used by a particular
 328    encryption processor.  When this method is used, the FixedDistinct
 329    fields used by the different processors MUST have the same length.
 330
 331    In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common
 332    part of the nonce (it is fixed, and it is common across all
 333    encryption processors), the FixedDistinct field exactly corresponds
 334    to the Fixed-Distinct field, and the Variable field corresponds to
 335    the Counter field, and the explicit part exactly corresponds to the
 336
 337    explicit_nonce_part.
 338
 339    For clarity, we provide an example for TLS in which there are two
 340    distinct encryption processors, each of which uses a one-byte
 341    FixedDistinct field:
 342
 343           Salt          = eedc68dc
 344           FixedDistinct = 01      (for the first encryption processor)
 345           FixedDistinct = 02      (for the second encryption processor)
 346
 347    The GCMnonces generated by the first encryption processor, and their
 348    corresponding explicit_nonce_parts, are:
 349
 350           GCMNonce                    explicit_nonce_part
 351           ------------------------    --------------------
 352           eedc68dc0100000000000000    0100000000000000
 353           eedc68dc0100000000000001    0100000000000001
 354           eedc68dc0100000000000002    0100000000000002
 355           ...
 356
 357    The GCMnonces generated by the second encryption processor, and
 358    their corresponding explicit_nonce_parts, are
 359
 360           GCMNonce                    explicit_nonce_part
 361           ------------------------    --------------------
 362           eedc68dc0200000000000000    0200000000000000
 363           eedc68dc0200000000000001    0200000000000001
 364           eedc68dc0200000000000002    0200000000000002
 365           ...
 366
 367 6. IANA Considerations
 368
 369    IANA has assigned the following values for the cipher suites defined
 370    in this document:
 371
 372       CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX};
 373       CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX};
 374
 375
 376 Badra                 Expires September 29, 2008               [Page 7]
 377 \f
 378 Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008
 379
 380
 381       CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX};
 382       CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX};
 383       CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX};
 384       CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX};
 385       CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX};
 386       CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX};
 387       CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX};
 388       CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX};
 389       CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX};
 390       CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX};
 391       CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX};
 392       CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX};
 393       CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};
 394       CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX};
 395       CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};
 396       CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX};
 397       CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};
 398       CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX};
 399       CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};
 400       CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX};
 401       CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};
 402       CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX};
 403
 404 7. Acknowledgments
 405
 406    This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac] and [I-
 407    D.ietf-tls-rsa-aes-gcm].
 408
 409 8. References
 410
 411 8.1. Normative References
 412
 413    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 414              Requirement Levels", BCP 14, RFC 2119, March 1997.
 415
 416    [I-D.ietf-tls-rfc4346-bis]
 417              Dierks, T. and E. Rescorla, "The Transport Layer Security
 418              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-
 419              10, work in progress, March 2008.
 420
 421    [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
 422              Encryption", RFC 5116, January 2008.
 423
 424    [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
 425              for Transport Layer Security (TLS)", RFC 4279, December
 426              2005.
 427
 428
 429
 430 Badra                 Expires September 29, 2008               [Page 8]
 431 \f
 432 Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008
 433
 434
 435    [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK)
 436              Ciphersuites with NULL Encryption for Transport Layer
 437              Security (TLS)", RFC 4785, January 2007.
 438
 439    [AES]     National Institute of Standards and Technology,
 440              "Specification for the Advanced Encryption Standard
 441              (AES)", FIPS 197, November 2001.
 442
 443    [SHS]     National Institute of Standards and Technology, "Secure
 444              Hash Standard", FIPS 180-2, August 2002.
 445
 446    [CBC]     National Institute of Standards and Technology,
 447              "Recommendation for Block Cipher Modes of Operation -
 448              Methods and Techniques", SP 800-38A, December 2001.
 449
 450    [GCM]     National Institute of Standards and Technology,
 451              "Recommendation for Block Cipher Modes of Operation:
 452              Galois;/Counter Mode (GCM) for Confidentiality and
 453              Authentication", SP 800-38D, November 2007.
 454
 455 8.2. Informative References
 456
 457    [Wang05]  Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
 458              Full SHA-1", CRYPTO 2005, August 2005.
 459
 460    [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 461              Security", RFC 4347, April 2006.
 462
 463    [I-D.ietf-tls-ecc-new-mac]
 464              Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
 465              256/384 and AES Galois Counter  Mode", draft-ietf-tls-ecc-
 466              new-mac-04 (work in progress), February 2008.
 467
 468    [I-D.ietf-tls-rsa-aes-gcm]
 469              Salowey, J., A. Choudhury, and C. McGrew, "RSA based AES-
 470              GCM Cipher Suites for TLS", draft-ietf-tls-rsa-aes-gcm-02
 471              (work in progress), February 2008.
 472
 473 Author's Addresses
 474
 475    Mohamad Badra
 476    LIMOS Laboratory - UMR6158, CNRS
 477    France
 478
 479    Email: badra@isima.fr
 480
 481
 482
 483
 484 Badra                 Expires September 29, 2008               [Page 9]
 485 \f
 486 Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008
 487
 488
 489 Intellectual Property Statement
 490
 491    The IETF takes no position regarding the validity or scope of any
 492    Intellectual Property Rights or other rights that might be claimed
 493    to pertain to the implementation or use of the technology described
 494    in this document or the extent to which any license under such
 495    rights might or might not be available; nor does it represent that
 496    it has made any independent effort to identify any such rights.
 497    Information on the procedures with respect to rights in RFC
 498    documents can be found in BCP 78 and BCP 79.
 499
 500    Copies of IPR disclosures made to the IETF Secretariat and any
 501    assurances of licenses to be made available, or the result of an
 502    attempt made to obtain a general license or permission for the use
 503    of such proprietary rights by implementers or users of this
 504    specification can be obtained from the IETF on-line IPR repository
 505    at http://www.ietf.org/ipr.
 506
 507    The IETF invites any interested party to bring to its attention any
 508    copyrights, patents or patent applications, or other proprietary
 509    rights that may cover technology that may be required to implement
 510    this standard.  Please address the information to the IETF at
 511    ietf-ipr@ietf.org.
 512
 513 Disclaimer of Validity
 514
 515    This document and the information contained herein are provided on
 516    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 517    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
 518    IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
 519    WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
 520    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
 521    ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
 522    FOR A PARTICULAR PURPOSE.
 523
 524 Copyright Statement
 525
 526    Copyright (C) The IETF Trust (2008).
 527
 528    This document is subject to the rights, licenses and restrictions
 529    contained in BCP 78, and except as set forth therein, the authors
 530    retain all their rights.
 531
 532 Acknowledgment
 533
 534    Funding for the RFC Editor function is currently provided by the
 535    Internet Society.
 536
 537
 538 Badra                 Expires September 29, 2008              [Page 10]
 539 \f