idnits 2.17.1 draft-tuexen-sctp-auth-chunk-03.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 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 503. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 94 has weird spacing: '...hich is preco...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The chunk types for INIT, INIT-ACK, COOKIE-ECHO, COOKIE-ACK, SHUTDOWN-COMPLETE and AUTH chunks MUST not be listed in the CHUNKS parameter. However, if a CHUNKS parameter is received then the types for INIT, INIT-ACK, COOKIE-ECHO, COOKIE-ACK, SHUTDOWN-COMPLETE and AUTH chunks MUST be ignored. -- 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 (February 20, 2005) is 6998 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 406, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 415, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 418, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 429, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 439, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '3') ** Obsolete normative reference: RFC 2409 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2960 (ref. '7') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-10 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft Univ. of Applied Sciences Muenster 4 Expires: August 24, 2005 R. Stewart 5 P. Lei 6 Cisco Systems, Inc. 7 E. Rescorla 8 RTFM, Inc. 9 February 20, 2005 11 Authenticated Chunks for Stream Control Transmission Protocol (SCTP) 12 draft-tuexen-sctp-auth-chunk-03.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 24, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document describes a new chunk type, several parameters and 48 procedures for SCTP. This new chunk type can be used to authenticate 49 SCTP chunks by using a shared key between the sender and receiver. 50 The new parameters are used to establish the shared key. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. New Parameter Types . . . . . . . . . . . . . . . . . . . . . 3 57 3.1 Random Parameter (RANDOM) . . . . . . . . . . . . . . . . 4 58 3.2 Chunk List Parameter (CHUNKS) . . . . . . . . . . . . . . 4 59 4. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1 Authentication Chunk (AUTH) . . . . . . . . . . . . . . . 5 61 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1 Establishment of an association shared key . . . . . . . . 6 63 5.2 Sending authenticated chunks . . . . . . . . . . . . . . . 7 64 5.3 Receiving authenticated chunks . . . . . . . . . . . . . . 8 65 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 70 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 72 Intellectual Property and Copyright Statements . . . . . . . . 12 74 1. Introduction 76 SCTP uses 32 bit verification tags to protect itself against blind 77 attackers. These values are not changed during the lifetime of an 78 SCTP association. 80 Looking at new SCTP extensions there is the need to have a method of 81 proving that an SCTP chunk(s) was really sent by the original peer 82 that started the association and not by a malicious attacker. 84 Using TLS as defined in RFC3436 [8] does not help here because it 85 only secures SCTP user data. 87 Therefore an SCTP extension is presented in this document which 88 allows an SCTP sender to sign chunks using a shared key between the 89 sender and receiver. The receiver can then verify, that the chunks 90 are sent from the sender and not from a malicious attacker. 92 This extension also provides a mechanism for deriving a shared key 93 for each association. This association shared key is derived from a 94 endpoint pair shared key, which is preconfigured and might be empty. 96 2. Conventions 98 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 99 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 100 they appear in this document, are to be interpreted as described in 101 RFC2119 [4]. 103 3. New Parameter Types 105 This section defines the new parameter types that will be used to 106 negotiate the authentication during association setup. Figure 1 107 illustrates the new parameter types. 109 Parameter Type Parameter Name 110 -------------------------------------------------------------- 111 0x8002 Random Parameter (RANDOM) 112 0x8003 Chunk List Parameter (CHUNKS) 114 Figure 1 116 It should be noted that the parameter format requires the receiver to 117 ignore the parameter and continue processing if it is not understood. 118 This is accomplished as described in RFC2960 [7] section 3.2.1. by 119 the use of the upper bit of the parameter type. 121 3.1 Random Parameter (RANDOM) 123 This parameter is used to carry an arbitrary length random number. 125 0 1 2 3 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Parameter Type = 0x8002 | Parameter Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | 131 \ Random Number / 132 / \ 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Figure 2 137 Parameter Type: 2 bytes (unsigned integer) This value MUST be set to 138 0x8002. 140 Parameter Length: 2 bytes (unsigned integer) This value is the length 141 of the Random Number plus 4. 143 Random Number: n bytes (unsigned integer) This value represents an 144 arbitrary Random Number in network byte order. 146 The RANDOM parameter MUST be included once in the INIT or INIT-ACK 147 chunk if the sender wants to send or receive authenticated chunks. 149 3.2 Chunk List Parameter (CHUNKS) 151 This parameter is used to specify which chunk types are required to 152 be sent authenticated by the peer. 154 0 1 2 3 155 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Parameter Type = 0x8003 | Parameter Length | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Chunk Type 1 | Chunk Type 2 | Chunk Type 4 | Chunk Type 4 | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 / / 162 \ ... \ 163 / / 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Chunk Type n | Padding | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 3 169 Parameter Type: 2 bytes (unsigned integer) This value MUST be set to 170 0x8003. 172 Parameter Length: 2 bytes (unsigned integer) This value is the number 173 of listed Chunk Types plus 4. 175 Chunk Type n: 1 byte (unsigned integer) Each Chunk Type listed is 176 required to be authenticated when sent by the peer. 178 The CHUNKS parameter MUST be included once in the INIT or INIT-ACK 179 chunk if the sender wants to receive authenticated chunks. Its 180 maximum length is 260 bytes. 182 The chunk types for INIT, INIT-ACK, COOKIE-ECHO, COOKIE-ACK, 183 SHUTDOWN-COMPLETE and AUTH chunks MUST not be listed in the CHUNKS 184 parameter. However, if a CHUNKS parameter is received then the types 185 for INIT, INIT-ACK, COOKIE-ECHO, COOKIE-ACK, SHUTDOWN-COMPLETE and 186 AUTH chunks MUST be ignored. 188 4. New Chunk Type 190 This section defines the new chunk type that will be used to 191 authenticate chunks. Figure 4 illustrates the new chunk type. 193 Chunk Type Chunk Name 194 -------------------------------------------------------------- 195 0x10 Authentication Chunk (AUTH) 197 Figure 4 199 It should be noted that the AUTH-chunk format requires the receiver 200 to ignore the chunk if it is not understood and silently discard all 201 chunks that follow. This is accomplished as described in RFC2960 [7] 202 section 3.2. by the use of the upper bit of the chunk type. 204 4.1 Authentication Chunk (AUTH) 206 This chunk is used to hold the result of the HMAC calculation. 208 0 1 2 3 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type = 0x10 | Flags=0 | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | HMAC Identifier | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 \ HMAC / 217 / \ 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 5 222 Type: 1 byte (unsigned integer) This value MUST be set to 0x83 for 223 all AUTH-chunks. 225 Flags: 1 byte (unsigned integer) Set to zero on transmit and ignored 226 on receipt. 228 Length: 2 bytes (unsigned integer) This value holds the length of the 229 HMAC plus 8. 231 HMAC Identifier: 4 bytes (unsigned integer) This value describes 232 which message digest is being used. The following Figure 6 shows 233 the currently defined values. 235 HMAC Identifier Message Digest Algorithm 236 --------------------------------------------------------------- 237 0 MD-5 defined in [1] 238 1 SHA-1 defined in [10] 240 Figure 6 242 HMAC: n bytes (unsigned integer) This hold the result of the HMAC 243 calculation. 245 The control chunk AUTH can appear at most once in an SCTP packet. 246 All control and data chunks which are placed after the AUTH chunk in 247 the packet are sent in an authenticated way. Those chunks placed in 248 a packet before the AUTH chunk are not authenticated. 250 5. Procedures 252 5.1 Establishment of an association shared key 254 An SCTP endpoint willing to receive or send authenticated chunks has 255 to send one RANDOM parameter in its INIT or INIT-ACK chunk. The 256 RANDOM parameter MUST contain a 32 byte random number. This random 257 number is handled like the verification tag in case of INIT 258 collisions. Therefore each endpoint knows its own random number and 259 the peers random number after the association has been established. 261 An SCTP endpoint has a list of chunks it only accepts if they are 262 received in an authenticated way. This list is included in the INIT 263 and INIT-ACK and MAY be omitted if it is empty. Since this list is 264 for an endpoint there is no problem in case of INIT collision. 266 Both enpoints of an association have an endpoint pair shared key 267 which is a byte vector and preconfigured or established by another 268 mechanism. If it is not preconfigured or established by another 269 mechanism it is set to the empty byte vector. 271 From this endpoint pair shared key the association shared key is 272 computed by concatenating the endpoint pair shared key with the 273 random numbers exchanged in the INIT and INIT-ACK. This is performed 274 by selecting the smaller random number and concatenating it to the 275 endpoint pair shared key. Then concatenating the larger of the 276 random numbers to that. If both random numbers are equal they may be 277 concatenated to the endpoint pair key in any order. The 278 concatenation is performed on byte vectors representing all numbers 279 in network byte order. The result is the association shared key. 281 5.2 Sending authenticated chunks 283 Chunks can only be authenticated when the SCTP association is in the 284 ESTABLISHED state. Both endpoints MUST send all those chunks 285 authenticated where this has been requested by the peer. The other 286 chunks MAY be sent authenticated. 288 To send chunks in an authenticated way, the sender has to include 289 these chunks after an AUTH chunk. This means that a sender MUST 290 bundle chunks in order to authenticate them. 292 The sender MUST calculate the MAC using the hash function H as 293 described by the MAC Identifier and the shared association key K. 294 The 'data' used for the computation is the AUTH-chunk as given by 295 Figure 7 and all chunks that are placed after the AUTH chunk in the 296 SCTP packet. RFC2104 [3] can be used as a guideline for generating 297 the MAC. 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type = 0x10 | Flags=0 | Chunk Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | HMAC Identifier | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 \ 0 / 306 / \ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 7 311 Please note that all fields are in network byte order. 313 The sender fills the HMAC then into the HMAC field and sends the 314 packet. 316 5.3 Receiving authenticated chunks 318 The receiver has a list of chunk types which it expects to be 319 received only after an AUTH-chunk. This list has been sent to the 320 peer during the association setup. It MUST silently discard these 321 chunks if they are not placed after an AUTH chunk in the packet. 323 The receiver MUST use the HMAC algorithm indicated in the HMAC 324 Identifier field. If this algorithm is not known the AUTH chunk and 325 all chunks after it MUST silently be discarded. 327 The receiver now performs the same calculation as described for the 328 sender based on Figure 7. If the result of the calculation is the 329 same as given in the HMAC field, all chunks following the AUTH chunk 330 are processed. If the field does not match the result of the 331 calculation all these chunks MUST be silently discarded. 333 6. Examples 335 This section gives examples of message exchanges for association 336 setup. 338 The simplest way of using the extension described in this document is 339 given by the following message exchange. 341 ---------------- INIT[RANDOM; CHUNKS] ---------------> 342 <------------- INIT-ACK[RANDOM; CHUNKS] -------------- 343 -------------------- COOKIE-ECHO --------------------> 344 <-------------------- COOKIE-ACK --------------------- 346 Please note that the CHUNKS parameter is optional in the INIT and 347 INIT-ACK. 349 If the server wants to receive DATA chunks in an authenticated way, 350 the following message exchange is possible: 352 ---------------- INIT[RANDOM; CHUNKS] ---------------> 353 <------------- INIT-ACK[RANDOM; CHUNKS] -------------- 354 --------------- COOKIE-ECHO; AUTH; DATA -------------> 355 <----------------- COOKIE-ACK; SACK ------------------ 357 Please note that if the endpoint pair shared key depends on the 358 client and the server and that it is only known by the upper layer 359 this message exchange requires an upper layer intervention between 360 the processing of the COOKIE-ECHO chunk (COMMUNICATION-UP 361 notification followed by the presentation of the endpoint pair shared 362 key by the upper layer to the SCTP stack) and the processing of the 363 AUTH and DATA chunk. If this intervention is not possible due to 364 limitations of the API the server might discard the AUTH and DATA 365 chunk making a retransmission of the DATA chunk necessary. If the 366 same endpoint pair shared key is used for multiple endpoints and does 367 not depend on the client this intervention might not be necessary. 369 7. IANA Considerations 371 A chunk type for the AUTH chunk has to be assigned by IANA. It is 372 suggested to use the value given above. 374 Parameter types have to be assigned for the RANDOM and CHUNKS 375 parameter by IANA. It is suggested to use the values given above. 377 8. Security Considerations 379 This section is still incomplete. 381 If no endpoint pair shared key is used an attacker which captures the 382 association setup message exchange can later insert arbitrary packets 383 in an authenticated way. However, if the attacker did not capture 384 this initial message exchange he can not successfully inject chunks 385 which are required to be authenticated. 387 If an enpoint pair shared key is used even a true man in the middle 388 can not inject chunks which are required to be authenticated even if 389 he intercepts the initial message exchange. 391 Because SCTP has already a mechanism built-in that handles the 392 reception of duplicated chunks the presented solution makes use of 393 this functionality and does not provide a method to avoid replay 394 attacks by itself. Of course, this only works within each SCTP 395 association. Therefore a separate shared key is used for each SCTP 396 association to handle replay attacks covering multiple SCTP 397 associations. 399 9. References 401 9.1 Normative References 403 [1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 404 1992. 406 [2] Bradner, S., "The Internet Standards Process -- Revision 3", 407 BCP 9, RFC 2026, October 1996. 409 [3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 410 for Message Authentication", RFC 2104, February 1997. 412 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 413 Levels", BCP 14, RFC 2119, March 1997. 415 [5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 416 RFC 2409, November 1998. 418 [6] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, 419 June 1999. 421 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 422 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 423 "Stream Control Transmission Protocol", RFC 2960, October 2000. 425 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer 426 Security over Stream Control Transmission Protocol", RFC 3436, 427 December 2002. 429 [9] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 430 Diffie-Hellman groups for Internet Key Exchange (IKE)", 431 RFC 3526, May 2003. 433 [10] National Institute of Standards and Technology, "Secure Hash 434 Standard", FIPS PUB 180-1, April 1995, 435 . 437 9.2 Informative References 439 [11] Stewart, R., "Stream Control Transmission Protocol (SCTP) 440 Dynamic Address Reconfiguration", 441 Internet-Draft draft-ietf-tsvwg-addip-sctp-10, January 2005. 443 Authors' Addresses 445 Michael Tuexen 446 Univ. of Applied Sciences Muenster 447 Stegerwaldstr. 39 448 48565 Steinfurt 449 Germany 451 Email: tuexen@fh-muenster.de 453 Randall R. Stewart 454 Cisco Systems, Inc. 455 4875 Forest Drive 456 Suite 200 457 Columbia, SC 29206 458 USA 460 Email: rrs@cisco.com 462 Peter Lei 463 Cisco Systems, Inc. 464 8735 West Higgins Road 465 Suite 300 466 Chicago, IL 60631 467 USA 469 Phone: 470 Email: peterlei@cisco.com 472 Eric Rescorla 473 RTFM, Inc. 474 2064 Edgewood Drive 475 Palo Alto, CA 94303 476 USA 478 Phone: +1 650-320-8549 479 Email: ekr@rtfm.com 481 Intellectual Property Statement 483 The IETF takes no position regarding the validity or scope of any 484 Intellectual Property Rights or other rights that might be claimed to 485 pertain to the implementation or use of the technology described in 486 this document or the extent to which any license under such rights 487 might or might not be available; nor does it represent that it has 488 made any independent effort to identify any such rights. Information 489 on the procedures with respect to rights in RFC documents can be 490 found in BCP 78 and BCP 79. 492 Copies of IPR disclosures made to the IETF Secretariat and any 493 assurances of licenses to be made available, or the result of an 494 attempt made to obtain a general license or permission for the use of 495 such proprietary rights by implementers or users of this 496 specification can be obtained from the IETF on-line IPR repository at 497 http://www.ietf.org/ipr. 499 The IETF invites any interested party to bring to its attention any 500 copyrights, patents or patent applications, or other proprietary 501 rights that may cover technology that may be required to implement 502 this standard. Please address the information to the IETF at 503 ietf-ipr@ietf.org. 505 Disclaimer of Validity 507 This document and the information contained herein are provided on an 508 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 509 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 510 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 511 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 512 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 513 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 515 Copyright Statement 517 Copyright (C) The Internet Society (2005). This document is subject 518 to the rights, licenses and restrictions contained in BCP 78, and 519 except as set forth therein, the authors retain all their rights. 521 Acknowledgment 523 Funding for the RFC Editor function is currently provided by the 524 Internet Society.