idnits 2.17.00 (12 Aug 2021) /tmp/idnits25783/draft-rescorla-stateless-tokens-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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 590. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 31 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (March 01, 2007) is 5553 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) -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. '3') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4507 (ref. '4') (Obsoleted by RFC 5077) == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft Network Resonance 4 Intended status: Standards Track March 01, 2007 5 Expires: September 2, 2007 7 How to Implement Secure (Mostly) Stateless Tokens 8 draft-rescorla-stateless-tokens-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 20 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 September 2, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 A common protocol problem is to want to arrange to maintain client 42 state with little or no local storage. The usual design pattern here 43 is to provide the client with a token which is returned with 44 subsequent interactions. In order to prevent tampering, forgery, and 45 privacy issues, such tokens should be cryptographically protected. 46 This draft describes one workable mechanism for constructing such 47 tokens. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 53 3. General Principles . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Reference Architecture . . . . . . . . . . . . . . . . . . 3 55 3.2. Token Construction and Processing . . . . . . . . . . . . 4 56 3.3. Invalidation and Supercession . . . . . . . . . . . . . . 5 57 4. Example Token Format . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . 8 59 5. ITLs Data Structures . . . . . . . . . . . . . . . . . . . . . 9 60 5.1. Simple Lists . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.2. Bit Fields . . . . . . . . . . . . . . . . . . . . . . . . 9 62 5.3. Bloom Filters . . . . . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 6.1. Failure to Authenticate . . . . . . . . . . . . . . . . . 10 65 6.2. Failure to Encrypt . . . . . . . . . . . . . . . . . . . . 11 66 6.3. Distinguishable Encryption . . . . . . . . . . . . . . . . 11 67 6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 11 68 6.5. Token Binding . . . . . . . . . . . . . . . . . . . . . . 12 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 8.2. Informational References . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Introduction 78 A common protocol problem is to want to arrange to maintain client 79 state with little or no local storage. The usual design pattern here 80 is to provide the client with a token which is returned with 81 subsequent interactions. One such application is TLS tickets [4], 82 which allow the server to offload the TLS session cache onto the 83 client. Another application is globally routable unique identifiers 84 [5] (GRUUs) which bind a second URI to a SIP AOR. GRUUs can be 85 defined in a stateless mode, which requires no storage on the SIP 86 registrar. Another application for this kind of technique is to 87 build Web "shopping carts". 89 Because the state token is stored on a remote node it is susceptible 90 to inspection and /or tampering by untrusted third parties. 91 Therefore, it becomes important to cryptographically secure tokens, 92 typically by encrypting them to provide confidentiality and adding a 93 message integrity check (MIC) to provide integrity for the token data 94 and assurance that it was generated by the consuming node. Note that 95 the remote node doesn't need to do anything with the token other than 96 echo it back, therefore there is no need for it to be able to access 97 the internals of the token. 99 Although the general techniques for constructing tokens of this type 100 are well understood, there are some subtle issues involved and there 101 is no single reference that describes acceptable constructions. 102 Accordingly, each token-using application has had to design its own 103 construction. The purpose of this document is to provide such a 104 reference. 106 2. Conventions Used In This Document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [1]. 112 3. General Principles 114 This section provides a somewhat abstract overview of the techniques 115 for constructing stateless tokens. In the next section we will 116 describe precise example formats that implement these principles. 118 3.1. Reference Architecture 120 The reference architecture for this kind of system is shown in the 121 figure below: 123 Client Server 124 ------ ------ 125 1. Hello ---------> \ State 126 <--------- 2. State token / Creation 128 [time passes] 130 3. State token ---------> \ State 131 <--------- 4. I remember you / Recovery 133 In message 1, the client contacts the server. The server creates 134 some state (e.g., creates a shopping cart structure), serializes that 135 into a state token, and sends it to the client in message 2. From 136 the client's perspective, this token is opaque, though it of course 137 has some internal structure that is parseable by the server. 139 Some time later, the client wants to talk to the server again. When 140 it reconnects, it sends the state token back in message 3. The 141 server decodes the state token and recovers the previously created 142 state and can process whatever transaction the client is trying to 143 perform. 145 3.2. Token Construction and Processing 147 We assume that the server has some static cryptographic keying 148 material, consisting of: 150 K_e -- an encryption key 151 K_m -- a message integrity (MAC) key 153 These keys SHOULD be randomly generated and of sufficient length to 154 match whatever cryptographic algorithms are in use. They are stored 155 in semi-permanent storage and used for protecting all tokens. 157 In order to construct a token, the server takes its state and packs 158 it into a single string S. S should be constructed so that it can be 159 unambiguously parsed by the server. The server than encrypts the 160 token and applies a MAC. For instance: 162 EA = Encrypt(K_e, S) 163 Token = EA || MAC(K_m, EA) 165 The encryption algorithm SHOULD to be chosen to have the following 166 properties: 168 1. Given any (EA, S) pair, it is computationally infeasible to 169 determine whether EA was derived from S. (Note that you may 170 obtain some information from length). 172 2. Multiple encryptions of the same value S produce different tokens 173 3. It is computationally infeasible to determine any information 174 about the relationship between the S values embedded in two 175 separate tokens. 177 AES [6] in either CBC or counter (CTR) with randomly chosen IVs both 178 meet these requirements. 180 The MAC algorithm is simply a standard MAC, such as HMAC [2]. 182 The design described above works in a variety of situations but has 183 the significant drawback that it does not permit the server to 184 invalidate or supercede states. Consider the case where the token is 185 being used to contain login state. One function such interfaces 186 typically offer is a "logout" button. However, if the server is 187 stateless, then there is no way to detect that a token which is 188 presented corresponds to a session which has been invalidated. A 189 related issue is "state rollback". If a server gives a client a new 190 state token (e.g., decrementing an account balance) the client can 191 send an older token instead; this is effectively a replay attack. 193 3.3. Invalidation and Supercession 195 Invalidating or superceding tokens requires the server to be able to 196 store some state. The usual procedure is for the server to retain a 197 list of invalid tokens. In the most primitive implementation, this 198 requires the server to keep all invalid tokens since the beginning of 199 time. Obviously this is inconvenient, so tokens are created with an 200 expiration time, thus limiting the invalid list to unexpired tokens 201 which are invalid (there is a parallel here to certificate revocation 202 lists [3]). 204 Even with expiry, high invalidation rates can lead to large Invalid 205 Token Lists (ITLs). This is especially true if you are having state 206 n+1 supercede state n (this is done by invalidating state n and then 207 issueing state n+1). A number of techniques can be used to minimize 208 the size of the ITL. For instance, it may be stored in a Bloom 209 filter or each token may be assigned an index with the ITL stored as 210 a bit field. These options are examined in more detail in Section 5. 212 4. Example Token Format 214 In this section we describe one acceptable token format that complies 215 with the guidelines in the previous section. For reference, consider 216 a state value as shown in Figure 1: 218 0 1 2 3 219 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 220 +---------------------------------------------------------------+ 221 | User Name | 222 | (64 bits) | 223 +---------------------------------------------------------------+ 224 | E-mail address | 225 / (variable length) / 226 | | 227 +---------------------------------------------------------------+ 229 Figure 1: Example state value 231 This state value would allow the server to "remember" some 232 registration information, e.g., for a web bulletin board. Note that 233 the token construction is agnostic about the state value as long as 234 it can be represented as a byte string. 236 The token format is shown in Figure 1. 238 0 1 2 3 239 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 240 +-------------------------------+-------------------------------+ <-+ 241 | Version (16 bits) | Protection Suite ID (16 bits) | | 242 +---------------------------------------------------------------+ <-+-+ 243 | | | 244 | Initialization Vector (IV) | | 245 | (typically 128 bits) | | 246 | | | 247 +-> +-------------------------------+-------------------------------+ <-+-+ 248 | | Expiration Time (32 bits) | | 249 | +---------------------------------------------------------------+ | 250 | | Sequence Number (32 bits) | | 251 | +---------------------------------------------------------------+ | 252 | | | | 253 | | State (S) | | 254 | / (Variable Length) / | 255 | | | | 256 | | +-------------------------------------+ | 257 | | | Padding | | 258 | +-------------------------+ Variable length | | 259 | | | | 260 +-> +---------------------------------------------------------------+ <-+ 261 | | | | 262 | | MAC | | 263 | | (Typically 160 bits) | | 264 | | | | 265 | | | | 266 | +---------------------------------------------------------------+ | 267 | | 268 | | 269 Encrypted Authenticated 270 Portion Portion 272 Figure 2: Example stateless token format 274 We assume that the state value that the server wishes to deliver is a 275 byte string S. 277 To construct a token, follow the following steps. 279 1. Construct TI = ET || SEQ || S where ET is the expiry time in 280 seconds since the UNIX epoch and SEQ is the token sequence 281 number. Both are 32-bit integers so TI can be unambiguously 282 parsed. 284 2. Generate a random 128-bit initialization vector. 285 3. Set EA equal to the encryption of TI with key K_e and 286 initialization vector IV: EA = Encrypt(K_e, IV, TI) 287 4. Compute the MAC over the Version, Protection Suite ID (PSID), and 288 EA: H = MAC(K_m, Version || PSID || EA) 289 5. Pack the values into token T. 291 Because the producer and consumer of the token are the same machine, 292 the Version and Protection Suite IDs are strictly unnecessary because 293 the consumer knows what kind of tokens it produces. However, in the 294 interest of tokens being self-describing and ease of version/ 295 algorithm transition, they are included in the token. Similarly, 296 there is no need to have standardized Version and Protection Suite ID 297 (PSID) values. However, we recommend that Version be the integer 1 298 and the following Prot_Id values: 300 +--------------------------+------+-------------+--------------+ 301 | Protection Suite | PSID | Encryption | MAC | 302 +--------------------------+------+-------------+--------------+ 303 | AES_128_CBC_WITH_SHA1 | 1 | AES-128-CBC | HMAC-SHA1 | 304 | AES_256_CBC_WITH_SHA_256 | 2 | AES-256-CBC | HMAC-SHA-256 | 305 +--------------------------+------+-------------+--------------+ 307 Table 1 309 Note that this follows the "Encrypt-then-Authenticate (EtA) paradigm 310 recommended by Krawczyk [7]. 312 To verify token T, perform the following steps: 314 1. Compare MAC(K_m, Version || Prot_ID || EA) to the MAC in the 315 token. If they don't match, reject the token. 316 2. Decrypt EA using K_e and IV to recover TI: TI = Decrypt(K_e, IV, 317 EA) 318 3. Break up TI into ET, SEQ, and S. 319 4. If the current time is after ET, the token is expired and should 320 be rejected. 321 5. If applicable, verify that the token is not on the ITL. 322 6. Deliver the token to the application 324 4.1. Key Rollover 326 One concern that people sometimes have is that you may wish to 327 periodically roll over keys. In general, this is not necessary since 328 modern cryptosystems do not require rekeying with the traffic volumes 329 relevant here. If this is a concern, then there are several easy 330 options, including adding a key ID, placing the sequence number in 331 the clear, or overloading the IV or protection suite ID. If only a 332 few keys are used, trial verification can be used to determine which 333 one is active. 335 5. ITLs Data Structures 337 In this section, we discuss three data structures for maintaining the 338 ITL. 340 5.1. Simple Lists 342 The most natural implementation is to simply store a list of all the 343 invalid but unexpired tokens. This requires I*size(Token) bytes of 344 storage where I is the number of tokens. If you instead store a list 345 of sequence numbers, then the required storage becomes 4I. It's 346 probably a good idea to keep this list sorted so that binary search 347 can be used for looking up potential tokens. Note that if you have a 348 very high invalidity rate it is more efficient to maintain a valid 349 token list. 351 5.2. Bit Fields 353 In environments where a large fraction (> 1/32) of tokens will 354 eventually be invalidated, a superior data structure is a bitmask 355 vector. What needs to be recorded here is: 357 o The sequence number of the earliest valid token (the low-water 358 mark) 359 o A bit vector with one bit for every token from the low water mark 360 to the latest unexpired invalid token (the high-water mark). 362 For instance, if you have issued tokens 0-18 and tokens 1, 3, 5, 7, 363 11 12, and 15 have been invalidated, but tokens 0-7 have also 364 expired, you would need to store a low-water of 8 (the earliest valid 365 token), plus to store an 8-bit bitmask vector as shown in Figure 3. 366 Note that because the high-water mark is 15, there is no need to 367 store bits corresponding to sequence numbers 16-18. 369 1 1 1 1 1 1 370 8 9 0 1 2 3 4 5 371 +-+-+-+-+-+-+-+-+ 372 |0 0 0 1 1 0 0 1| 373 +-+-+-+-+-+-+-+-+ 375 Figure 3: Bitmask vector invalidation list 377 The bitmask may also be stored compressed (e.g., run length encoded), 378 though of course this provides slower access. 380 5.3. Bloom Filters 382 With lower invalidation rates, Bloom filters [9] can be used to store 383 the ITL. Bloom filters have the significant advantage that they are 384 much smaller (about 10x smaller for bitmasks for 1% revocation 385 rates). They have the drawback that they have false positives 386 (tokens which appear to be invalidated but are not in fact invalid). 387 In settings where the state being stored is soft (e.g., [4]), this 388 isn't a problem but when it is hard state, then it can be. The Bloom 389 filter can be tuned for arbitrary false positive rates, but improved 390 specificity requires larger Bloom filter sizes. 392 Another issue with simple Bloom filters is that they do not allow you 393 to delete entries from the ITL when the token expires. The result is 394 that the filter fills up with expired tokens and produces a 395 monotonically increasing false positive rate. One approach here is 396 to use counting Bloom filters [10]. However, these can still 397 overflow and produce false positives. A superior solution is simply 398 to use multiple Bloom filters corresponding to different expiry 399 periods and then delete a Bloom filter once the current time sweeps 400 past the expiry period represented by the filter. 402 6. Security Considerations 404 In this section, we address a number of easy mistakes to make in 405 designing mechanisms of this type. 407 6.1. Failure to Authenticate 409 One common error is to simply encrypt the token without using any 410 authentication or message integrity. The result is that tokens are 411 susceptible to a variety of forgery attacks. This is a particular 412 problem if a stream cipher such as counter mode is used, because an 413 attacker can make targeted changes to any bit in the token, but 414 attacks are possible with CBC mode as well. 416 Consider a token format like the one presented in Figure 1 but 417 without an integrity check. The attacker contacts the server and 418 gets a state token T, containing his identity. The first block (128 419 bits) of ciphertext contain ET, SEQ, and the first 64 bits of S, 420 which contain the username, which we call I. The attacker wants to 421 pose as username I'. The attacker then generates a new IV' with the 422 low order 64-bits set to IV XOR I XOR I' and builds a new token T' = 423 IV' || EA. Because of the properties of CBC, when T' is decrypted 424 its first block will decrypt to EQ || SEQ || I', thus allowing a user 425 to pose as any other user. Such attacks are much more serious with 426 CTR mode, where the whole plaintext may be tampered with. This is 427 simply a special case of the general cryptographic rule that 428 encryption cannot be counted on to provide integrity. 430 6.2. Failure to Encrypt 432 Encryption of tokens is not strictly necessary in order to provide 433 integrity for the tokens. However, in most settings it is desirable 434 to provide confidentiality. In the case of TLS tickets, that is 435 because secret keying material is carried in the token. In the case 436 of GRUUs one of the purposes of the construction is to provide 437 privacy. Therefore, despite the possibility that confidentiality is 438 not required, in general we recommend encrypting the data unless 439 there is a clear requirement for it not to be. 441 6.3. Distinguishable Encryption 443 In cases such as GRUU where privacy is a requirement, then it is 444 important for tokens to be unlinkable; at minimum, it must be 445 infeasible for an attacker to determine whether two tokens issued by 446 the same server correspond to the same or related underlying state 447 information. Optimally, it should be infeasible for an attacker to 448 determine whether two tokens were generated by the same server or 449 different servers (obviously, this depends on them using the same 450 token format and similar state value lengths.) 452 This places a requirement on the algorithms used to encrypt the 453 token; repeated encryptions of the same (or related) plaintexts must 454 produce ciphertexts that cannot be distinguished from encryptions of 455 different plaintexts. Specifically, block ciphers in ECB mode are 456 not suitable here and block ciphers in CBC or CTR mode require unique 457 initialization vectors. In order to avoid attackers determining the 458 temporal relationship between two tokens, the IV should be generated 459 with a cryptographically secure random or pseudorandom number 460 generator. This is also the rationale for encrypting the expiry time 461 and sequence number. Note, however, that this is a tradeoff; having 462 these values in the clear would allow immediate rejection of 463 invalidated or expired tokens. Instead, the server has to decrypt 464 the token in order to check its status. 466 6.4. Replay Attacks 468 As described in Section 5, if one wishes to be able to invalidate 469 tokens, one must keep state on the server. This is obvious in 470 contexts where you wish to invalidate tokens directly (such as 471 logout) but in cases where you simply wish one state to supersede 472 another, the necessity for invalidating the old state is less 473 obvious. However, the failure to do so subjects you to replay 474 attacks. Implementations which replace state tokens therefore need 475 to maintain invalid token lists. 477 6.5. Token Binding 479 In order to prevent a token from being used outside its intended 480 context it may be necessary to bind the token to a set of verifiable 481 information associated with the intended context. For example, if a 482 token belongs to a particular user then including the username in the 483 token allows the server to verify that the user authenticated during 484 the current session is indeed the user that was issued the token. 485 Another possibility is to bind the token to a particular key that the 486 client possess and is included in the token (note that in this case 487 the token must be encrypted). Other information may be bound within 488 the token, which may further limit its use in other contexts. In 489 some cases privacy or other considerations may prevent inserting this 490 information into the token. In these cases the system should attempt 491 prevent the disclosure of the token to third parties through the use 492 of encryption and other access control mechanisms. 494 7. Acknowledgments 496 The material in Section 5 is based on the analysis in [8]. The 497 material in Section 6.5 was contributed by Joe Salowey. Thanks to 498 Joe Salowey for review comments. 500 8. References 502 8.1. Normative References 504 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 505 Levels", BCP 14, RFC 2119, March 1997. 507 8.2. Informational References 509 [2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 510 for Message Authentication", RFC 2104, February 1997. 512 [3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 513 Public Key Infrastructure Certificate and Certificate 514 Revocation List (CRL) Profile", RFC 3280, April 2002. 516 [4] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 517 "Transport Layer Security (TLS) Session Resumption without 518 Server-Side State", RFC 4507, May 2006. 520 [5] Rosenberg, J., "Obtaining and Using Globally Routable User 521 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 522 (SIP)", draft-ietf-sip-gruu-11 (work in progress), 523 October 2006. 525 [6] National Institute of Standards and Technology, "Specification 526 for the Advanced Encryption Standard (AES)", FIPS 197, 527 November 2001. 529 [7] Krawczyk, H., "The Order of Encryption and Authentication for 530 Protecting Communications (or: How Secure Is SSL?)", 531 CRYPTO 2001. 533 [8] Schacham, H., Boneh, D., and E. Rescorla, "Client-Side Caching 534 for TLS", ACM Trans. Info. & Sys. Security 7(4):553-75. 536 [9] Bloom, B., "Space/time trade-offs in hash coding with allowable 537 errors", Comm. ACM 13(7):422-6. 539 [10] Fan, L., Cao, P., Almeida, J., and A. Broder, "Summary Cache: A 540 Scalable Wide-Area Web Cache Sharing Protocol", SIGCOMM . 542 Author's Address 544 Eric Rescorla 545 Network Resonance 546 2483 E. Bayshore #212 547 Palo Alto, CA 94303 548 USA 550 Email: ekr@networkresonance.com 552 Full Copyright Statement 554 Copyright (C) The IETF Trust (2007). 556 This document is subject to the rights, licenses and restrictions 557 contained in BCP 78, and except as set forth therein, the authors 558 retain all their rights. 560 This document and the information contained herein are provided on an 561 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 562 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 563 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 564 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 565 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 566 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 568 Intellectual Property 570 The IETF takes no position regarding the validity or scope of any 571 Intellectual Property Rights or other rights that might be claimed to 572 pertain to the implementation or use of the technology described in 573 this document or the extent to which any license under such rights 574 might or might not be available; nor does it represent that it has 575 made any independent effort to identify any such rights. Information 576 on the procedures with respect to rights in RFC documents can be 577 found in BCP 78 and BCP 79. 579 Copies of IPR disclosures made to the IETF Secretariat and any 580 assurances of licenses to be made available, or the result of an 581 attempt made to obtain a general license or permission for the use of 582 such proprietary rights by implementers or users of this 583 specification can be obtained from the IETF on-line IPR repository at 584 http://www.ietf.org/ipr. 586 The IETF invites any interested party to bring to its attention any 587 copyrights, patents or patent applications, or other proprietary 588 rights that may cover technology that may be required to implement 589 this standard. Please address the information to the IETF at 590 ietf-ipr@ietf.org. 592 Acknowledgment 594 Funding for the RFC Editor function is provided by the IETF 595 Administrative Support Activity (IASA).