idnits 2.17.00 (12 Aug 2021) /tmp/idnits9738/draft-ietf-tls-psk-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 549), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 415 has weird spacing: '...rsuites for...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 18, 2004) is 6484 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3268 (ref. '2') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 1750 (ref. '4') (Obsoleted by RFC 4086) == Outdated reference: draft-ietf-sasl-saslprep has been published as RFC 4013 -- Obsolete informational reference (is this intentional?): RFC 3454 (ref. '9') (Obsoleted by RFC 7564) == Outdated reference: draft-ietf-tls-rfc2246-bis has been published as RFC 4346 == Outdated reference: draft-ietf-tls-srp has been published as RFC 5054 Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TLS Working Group P. Eronen 2 Internet-Draft Nokia 3 Expires: February 16, 2005 H. Tschofenig 4 Siemens 5 August 18, 2004 7 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) 8 draft-ietf-tls-psk-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 16, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document specifies three sets of new ciphersuites for the 42 Transport Layer Security (TLS) protocol to support authentication 43 based on pre-shared keys. These pre-shared keys are symmetric keys, 44 shared in advance among the communicating parties. The first set of 45 ciphersuites uses only symmetric key operations for authentication. 46 The second set uses a Diffie-Hellman exchange authenticated with a 47 pre-shared key; and the third set combines public key authentication 48 of the server with pre-shared key authentication of the client. 50 1. Introduction 52 Usually TLS uses public key certificates [3] or Kerberos [11] for 53 authentication. This document describes how to use symmetric keys 54 (later called pre-shared keys or PSKs), shared in advance among the 55 communicating parties, to establish a TLS connection. 57 There are basically two reasons why one might want to do this: 59 o First, TLS may be used in performance-constrained environments 60 where the CPU power needed for public key operations is not 61 available. 63 o Second, pre-shared keys may be more convenient from a key 64 management point of view. For instance, in closed environments 65 where the connections are mostly configured manually in advance, 66 it may be easier to configure a PSK than to use certificates. 67 Another case is when the parties already have a mechanism for 68 setting up a shared secret key, and that mechanism could be used 69 to "bootstrap" a key for authenticating a TLS connection. 71 This document specifies three sets of new ciphersuites for TLS. 72 These ciphersuites use new key exchange algorithms, and re-use 73 existing cipher and MAC algorithms from [3] and [2]. A summary of 74 these ciphersuites is shown below. 76 CipherSuite Key Exchange Cipher Hash 78 TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA 79 TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA 80 TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA 81 TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA 82 TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA 83 TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA 84 TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA 85 TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA 86 TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA 87 TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA 88 TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA 89 TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA 91 The first set of ciphersuites (with PSK key exchange algorithm), 92 defined in Section 2 use only symmetric key algorithms, and are thus 93 especially suitable for performance-constrained environments. 95 The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm) 96 use a PSK to authenticate a Diffie-Hellman exchange. These 97 ciphersuites give some additional protection against dictionary 98 attacks, and also provide Perfect Forward Secrecy (PFS). 100 The third set of ciphersuites (with RSA_PSK key exchange algorithm), 101 defined in Section 4, combine public key based authentication of the 102 server (using RSA and certificates) with mutual authentication using 103 a PSK. 105 1.1 Applicability statement 107 The ciphersuites defined in this document are intended for a rather 108 limited set of applications, usually involving only a very small 109 number of clients and servers. Even in such environments, other 110 alternatives may be more appropriate. 112 If the main goal is to avoid PKIs, another possibility worth 113 considering is to use self-signed certificates with public key 114 fingerprints. Instead of manually configuring a shared secret in, 115 for instance, some configuration file, a fingerprint (hash) of the 116 other party's public key (or certificate) could be placed there 117 instead. 119 It is also possible to use the SRP (Secure Remote Password) 120 ciphersuites for shared secret authentication [13]. SRP was designed 121 to be used with passwords, and incorporates protection against 122 dictionary attacks. However, it is computationally more expensive 123 than the PSK ciphersuites in Section 2. 125 1.2 Conventions used in this document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [1]. 131 2. PSK key exchange algorithm 133 This section defines the PSK key exchange algorithm and associated 134 ciphersuites. These ciphersuites use only symmetric key algorithms. 136 It is assumed that the reader is familiar with ordinary TLS 137 handshake, shown below. The elements in parenthesis are not included 138 when PSK key exchange algorithm is used. 140 Client Server 141 ------ ------ 143 ClientHello --------> 144 ServerHello 145 (Certificate) 146 ServerKeyExchange 147 (CertificateRequest) 148 <-------- ServerHelloDone 149 (Certificate) 150 ClientKeyExchange 151 (CertificateVerify) 152 ChangeCipherSpec 153 Finished --------> 154 ChangeCipherSpec 155 <-------- Finished 156 Application Data <-------> Application Data 158 The client indicates its willingness to use pre-shared key 159 authentication by including one or more PSK ciphersuites in the 160 ClientHello message. If the TLS server also wants to use pre-shared 161 keys, it selects one of the PSK ciphersuites, places the selected 162 ciphersuite in the ServerHello message, and includes an appropriate 163 ServerKeyExchange message (see below). The Certificate and 164 CertificateRequest payloads are omitted from the response. 166 Both clients and servers may have pre-shared keys with several 167 different parties. The client indicates which key to use by 168 including a "PSK identity" in the ClientKeyExchange message (note 169 that unlike in [6], the session_id field in ClientHello message keeps 170 its usual meaning). To help the client in selecting which identity 171 to use, the server can provide a "PSK identity hint" in the 172 ServerKeyExchange message (note that if no hint is provided, a 173 ServerKeyExchange message is still sent). 175 This document does not specify the format of the PSK identity or PSK 176 identity hint; neither is specified how exactly the client uses the 177 hint (if it uses it at all). The parties have to agree on the 178 identities when the shared secret is configured (however, see Section 179 6 for related security considerations). In situations where the 180 identity is entered by a person, it is RECOMMENDED that the input is 181 processed using an appropriate stringprep [9] profile and encoded in 182 octets using UTF-8 encoding [14]. One possible stringprep profile is 183 described in [8]. 185 The format of the ServerKeyExchange and ClientKeyExchange messages is 186 shown below. 188 struct { 189 select (KeyExchangeAlgorithm) { 190 /* other cases for rsa, diffie_hellman, etc. */ 191 case psk: /* NEW */ 192 opaque psk_identity_hint<0..2^16-1>; 193 }; 194 } ServerKeyExchange; 196 struct { 197 select (KeyExchangeAlgorithm) { 198 /* other cases for rsa, diffie_hellman, etc. */ 199 case psk: /* NEW */ 200 opaque psk_identity<0..2^16-1>; 201 } exchange_keys; 202 } ClientKeyExchange; 204 The premaster secret is formed as follows: If the PSK is N octets 205 long, concatenate N zero octets and the PSK. 207 Note: This effectively means that only the HMAC-SHA1 part of the 208 TLS PRF is used, and the HMAC-MD5 part is not used. See [7] for a 209 more detailed rationale. 211 The TLS handshake is authenticated using the Finished messages as 212 usual. 214 If the server does not recognize the PSK identity, it MAY respond 215 with an "unknown_psk_identity" alert message. Alternatively, if the 216 server wishes to hide the fact that the PSK identity was not known, 217 it MAY continue the protocol as if the PSK identity existed but the 218 key was incorrect: that is, respond with a "decrypt_error" alert. 220 3. DHE_PSK key exchange algorithm 222 This section defines additional ciphersuites that use a PSK to 223 authenticate a Diffie-Hellman exchange. These ciphersuites give some 224 additional protection against dictionary attacks, and also provide 225 Perfect Forward Secrecy (PFS). See Section 6 for discussion of 226 related security considerations. 228 When these ciphersuites are used, the ServerKeyExchange and 229 ClientKeyExchange also include the Diffie-Hellman parameters. The 230 PSK identity and identity hint fields have the same meaning as in the 231 previous section. 233 The format of the ServerKeyExchange and ClientKeyExchange messages is 234 shown below. 236 struct { 237 select (KeyExchangeAlgorithm) { 238 /* other cases for rsa, diffie_hellman, etc. */ 239 case diffie_hellman_psk: /* NEW */ 240 opaque psk_identity_hint<0..2^16-1>; 241 ServerDHParams params; 242 }; 243 } ServerKeyExchange; 245 struct { 246 select (KeyExchangeAlgorithm) { 247 /* other cases for rsa, diffie_hellman, etc. */ 248 case diffie_hellman_psk: /* NEW */ 249 opaque psk_identity<0..2^16-1>; 250 ClientDiffieHellmanPublic public; 251 } exchange_keys; 252 } ClientKeyExchange; 254 The premaster secret is formed as follows: concatenate the value 255 produced by the Diffie-Hellman exchange (with leading zero bytes 256 stripped as in other Diffie-Hellman based ciphersuites) and the PSK, 257 in this order. 259 4. RSA_PSK key exchange algorithm 261 The ciphersuites in this section use RSA and certificates to 262 authenticate the server, in addition to using a PSK. 264 As in normal RSA ciphersuites, the server must send a Certificate 265 message. The format of the ServerKeyExchange and ClientKeyExchange 266 messages is shown below. 268 struct { 269 select (KeyExchangeAlgorithm) { 270 /* other cases for rsa, diffie_hellman, etc. */ 271 case rsa_psk: /* NEW */ 272 opaque psk_identity_hint<0..2^16-1>; 273 }; 274 } ServerKeyExchange; 276 struct { 277 select (KeyExchangeAlgorithm) { 278 /* other cases for rsa, diffie_hellman, etc. */ 279 case rsa_psk: /* NEW */ 280 opaque psk_identity<0..2^16-1>; 281 EncryptedPreMasterSecret; 282 } exchange_keys; 283 } ClientKeyExchange; 285 The premaster secret is formed as follows: concatenate the 48-byte 286 value generated by the client (and sent to the server in 287 ClientKeyExchange message) and the PSK, in this order. 289 5. IANA considerations 291 (This depends on whether this document is published before or after 292 TLS 1.1.) 294 (If after 1.1) This document does not create any new namespaces to be 295 maintained by IANA, but it requires new values in the ciphersuite 296 namespace defined in TLS 1.1 specification. 298 (If before 1.1) There are no IANA actions associated with this 299 document. For easier reference in the future, the ciphersuite 300 numbers defined in this document are summarized below. 302 CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD }; 303 CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD }; 304 CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD }; 305 CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD }; 306 CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD }; 307 CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD }; 308 CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD }; 309 CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD }; 310 CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD }; 311 CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD }; 312 CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD }; 313 CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD }; 315 This document also defines a new TLS alert message, 316 unknown_psk_identity(TBD). Since IANA does not maintain a registry 317 of TLS alert messages, no IANA action is needed for this. 319 6. Security Considerations 321 As with all schemes involving shared keys, special care should be 322 taken to protect the shared values and to limit their exposure over 323 time. 325 6.1 Perfect forward secrecy (PFS) 327 The PSK and RSA_PSK ciphersuites defined in this document do not 328 provide Perfect Forward Secrecy (PFS). That is, if the shared secret 329 key (in PSK ciphersuites), or both the shared secret key and the RSA 330 private key (in RSA_PSK ciphersuites), is somehow compromised, an 331 attacker can decrypt old conversations. 333 The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh 334 DH private key is generated for each handshake. 336 6.2 Brute-force and dictionary attacks 338 Use of a fixed shared secret of limited entropy (such as a password) 339 may allow an attacker to perform a brute-force or dictionary attack 340 to recover the secret. This may be either an off-line attack 341 (against a captured TLS handshake messages), or an on-line attack 342 where the attacker attempts to connect to the server and tries 343 different keys. 345 For the PSK ciphersuites, an attacker can get the information 346 required for an off-line attack by eavesdropping a TLS handshake, or 347 by getting a valid client to attempt connection with the attacker (by 348 tricking the client to connect to wrong address, or intercepting a 349 connection attempt to the correct address, for instance). 351 For the DHE_PSK ciphersuites, an attacker can obtain the information 352 by getting a valid client to attempt connection with the attacker. 353 Passive eavesdropping alone is not sufficient. 355 For the RSA_PSK ciphersuites, only the server (authenticated using 356 RSA and certificates) can obtain sufficient information for an 357 off-line attack. 359 It is RECOMMENDED that implementations that allow the administrator 360 to manually configure the PSK also provide a functionality for 361 generating a new random PSK, taking [4] into account. 363 6.3 Identity privacy 365 The PSK identity is sent in cleartext. While using a user name or 366 other similar string as the PSK identity is the most straightforward 367 option, it may lead to problems in some environments since an 368 eavesdropper is able to identify the communicating parties. Even 369 when the identity does not reveal any information itself, reusing the 370 same identity over time may eventually allow an attacker to perform 371 traffic analysis to identify the parties. It should be noted that 372 this is no worse than client certificates, since they are also sent 373 in cleartext. 375 6.4 Implementation notes 377 The implementation notes in [10] about correct implementation and use 378 of RSA (including Section 7.4.7.1) and Diffie-Hellman (including 379 Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as 380 well. 382 7. Acknowledgments 384 The protocol defined in this document is heavily based on work by Tim 385 Dierks and Peter Gutmann, and borrows some text from [6] and [2]. 386 Valuable feedback was also provided by Philip Ginzboorg, Peter 387 Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, and Mika 388 Tervonen. 390 When the first version of this draft was almost ready, the authors 391 learned that something similar had been proposed already in 1996 392 [12]. However, this draft is not intended for web password 393 authentication, but rather for other uses of TLS. 395 The DHE_PSK and RSA_PSK ciphersuites borrow heavily from [5]. 397 8. Open issues 399 o Identity privacy could be provided (in DHE_PSK/RSA_PSK versions) 400 by encrypting the psk_identity payload with keys derived from the 401 DH value/RSA-encrypted random (but not PSK). But perhaps this 402 would be an unnecessary complication. 404 o The way the PSK is combined with DH value (and is then used to 405 calculate the Finished message) is not exactly the traditional 406 way. It should be OK with TLS-PRF, though. 408 9. References 410 9.1 Normative References 412 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 413 Levels", RFC 2119, March 1997. 415 [2] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 416 Transport Layer Security (TLS)", RFC 3268, June 2002. 418 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 419 2246, January 1999. 421 [4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 422 Recommendations for Security", RFC 1750, December 1994. 424 9.2 Informative References 426 [5] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni, 427 "Pre-Shared-Key key Exchange methods for TLS", 428 draft-badra-tls-key-exchange-00 (work in progress), August 429 2004. 431 [6] Gutmann, P., "Use of Shared Keys in the TLS Protocol", 432 draft-ietf-tls-sharedkeys-02 (expired), October 2003. 434 [7] Krawczyk, H., "Re: TLS shared keys PRF", message on 435 ietf-tls@lists.certicom.com mailing list 2004-01-13, 436 http://www.imc.org/ietf-tls/mail-archive/msg04098.html. 438 [8] Zeilenga, K., "SASLprep: Stringprep profile for user names and 439 passwords", draft-ietf-sasl-saslprep-10 (work in progress), 440 July 2004. 442 [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 443 Strings ("stringprep")", RFC 3454, December 2002. 445 [10] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 446 draft-ietf-tls-rfc2246-bis-08 (work in progress), August 2004. 448 [11] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites 449 to Transport Layer Security (TLS)", RFC 2712, October 1999. 451 [12] Simon, D., "Addition of Shared Key Authentication to Transport 452 Layer Security (TLS)", draft-ietf-tls-passauth-00 (expired), 453 November 1996. 455 [13] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using 456 SRP for TLS Authentication", draft-ietf-tls-srp-07 (work in 457 progress), June 2004. 459 [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 460 3629, November 2003. 462 Authors' Addresses 464 Pasi Eronen 465 Nokia Research Center 466 P.O. Box 407 467 FIN-00045 Nokia Group 468 Finland 470 EMail: pasi.eronen@nokia.com 472 Hannes Tschofenig 473 Siemens 474 Otto-Hahn-Ring 6 475 Munich, Bayern 81739 476 Germany 478 EMail: Hannes.Tschofenig@siemens.com 480 Appendix A. Changelog 482 (This section should be removed by the RFC Editor before 483 publication.) 485 Changes from draft-ietf-tls-psk-00 to -01: 487 o Added DHE_PSK and RSA_PSK key exchange algorithms, and updated 488 other text accordingly 490 o Removed SHA-1 hash from PSK key exchange premaster secret 491 construction (since premaster secret doesn't need to be 48 bytes). 493 o Added unknown_psk_identity alert message. 495 o Updated IANA considerations section. 497 Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00: 499 o Updated dictionary attack considerations based on comments from 500 David Jablon. 502 o Added a recommendation about using UTF-8 in the identity field. 504 o Removed Appendix A comparing this document with 505 draft-ietf-tls-sharedkeys-02. 507 o Removed IPR comment about SPR. 509 o Minor editorial changes. 511 Intellectual Property Statement 513 The IETF takes no position regarding the validity or scope of any 514 Intellectual Property Rights or other rights that might be claimed to 515 pertain to the implementation or use of the technology described in 516 this document or the extent to which any license under such rights 517 might or might not be available; nor does it represent that it has 518 made any independent effort to identify any such rights. Information 519 on the procedures with respect to rights in RFC documents can be 520 found in BCP 78 and BCP 79. 522 Copies of IPR disclosures made to the IETF Secretariat and any 523 assurances of licenses to be made available, or the result of an 524 attempt made to obtain a general license or permission for the use of 525 such proprietary rights by implementers or users of this 526 specification can be obtained from the IETF on-line IPR repository at 527 http://www.ietf.org/ipr. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org. 535 Disclaimer of Validity 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 540 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 541 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 542 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 543 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 Copyright Statement 547 Copyright (C) The Internet Society (2004). This document is subject 548 to the rights, licenses and restrictions contained in BCP 78, and 549 except as set forth therein, the authors retain all their rights. 551 Acknowledgment 553 Funding for the RFC Editor function is currently provided by the 554 Internet Society.