idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-07.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 543. ** 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. 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 : ---------------------------------------------------------------------------- ** 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 6 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 5, 2006) is 6599 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) -- Looks like a reference, but probably isn't: '0' on line 418 -- Looks like a reference, but probably isn't: '1' on line 417 -- Looks like a reference, but probably isn't: '2' on line 398 -- Looks like a reference, but probably isn't: '3' on line 399 -- Looks like a reference, but probably isn't: '4' on line 400 -- Looks like a reference, but probably isn't: '5' on line 401 -- Looks like a reference, but probably isn't: '6' on line 402 -- Looks like a reference, but probably isn't: '7' on line 403 -- Looks like a reference, but probably isn't: '8' on line 404 -- Looks like a reference, but probably isn't: '9' on line 405 -- Looks like a reference, but probably isn't: '10' on line 406 -- Looks like a reference, but probably isn't: '11' on line 407 -- Looks like a reference, but probably isn't: '12' on line 408 -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP K. Raeburn 3 Internet-Draft MIT 4 Updates: 4120 (if approved) L. Zhu 5 Expires: September 6, 2006 K. Jaganathan 6 Microsoft Corporation 7 March 5, 2006 9 Generating KDC Referrals to Locate Kerberos Realms 10 draft-ietf-krb-wg-kerberos-referrals-07 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 6, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The memo documents a method for a Kerberos Key Distribution Center 44 (KDC) to respond to client requests for Kerberos tickets when the 45 client does not have detailed configuration information on the realms 46 of users or services. The KDC will handle requests for principals in 47 other realms by returning either a referral error or a cross-realm 48 TGT to another realm on the referral path. The clients will use this 49 referral information to reach the realm of the target principal and 50 then receive the ticket. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 56 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4 57 4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5 58 5. Client Name Canonicalization . . . . . . . . . . . . . . . . . 5 59 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 9 62 9. Compatibility with Earlier Implementations of Name 63 Canonicalization . . . . . . . . . . . . . . . . . . . . . . . 9 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 12.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Appendix A. Document history . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 71 Intellectual Property and Copyright Statements . . . . . . . . . . 14 73 1. Introduction 75 Current implementations of the Kerberos AS and TGS protocols, as 76 defined in [RFC4120], use principal names constructed from a known 77 user or service name and realm. A service name is typically 78 constructed from a name of the service and the DNS host name of the 79 computer that is providing the service. Many existing deployments of 80 Kerberos use a single Kerberos realm where all users and services 81 would be using the same realm. However in an environment where there 82 are multiple trusted Kerberos realms, the client needs to be able to 83 determine what realm a particular user or service is in before making 84 an AS or TGS request. Traditionally this requires client 85 configuration to make this possible. 87 When having to deal with multiple trusted realms, users are forced to 88 know what realm they are in before they can obtain a ticket granting 89 ticket (TGT) with an AS request. However, in many cases the user 90 would like to use a more familiar name that is not directly related 91 to the realm of their Kerberos principal name. A good example of 92 this is an RFC 822 style email name. This document describes a 93 mechanism that would allow a user to specify a user principal name 94 that is an alias for the user's Kerberos principal name. In practice 95 this would be the name that the user specifies to obtain a TGT from a 96 Kerberos KDC. The user principal name no longer has a direct 97 relationship with the Kerberos principal or realm. Thus the 98 administrator is able to move the user's principal to other realms 99 without the user having to know that it happened. 101 Once a user has a TGT, they would like to be able to access services 102 in any trusted Kerberos realm. To do this requires that the client 103 be able to determine what realm the target service principal is in 104 before making the TGS request. Current implementations of Kerberos 105 typically have a table that maps DNS host names to corresponding 106 Kerberos realms. In order for this to work on the client, each 107 application canonicalizes the host name of the service, for example 108 by doing a DNS lookup followed by a reverse lookup using the returned 109 IP address. The returned primary host name is then used in the 110 construction of the principal name for the target service. In order 111 for the correct realm to be added for the target host, the mapping 112 table [domain_to_realm] is consulted for the realm corresponding to 113 the DNS host name. The corresponding realm is then used to complete 114 the target service principal name. 116 This traditional mechanism requires that each client have very 117 detailed configuration information about the hosts that are providing 118 services and their corresponding realms. Having client side 119 configuration information can be very costly from an administration 120 point of view - especially if there are many realms and computers in 121 the environment. 123 There are also cases where specific DNS aliases (local names) have 124 been setup in an organization to refer to a server in another 125 organization (remote server). The server has different DNS names in 126 each organization and each organization has a Kerberos realm that is 127 configured to service DNS names within that organization. Ideally 128 users are able to authenticate to the server in the other 129 organization using the local server name. This would mean that the 130 local realm be able to produce a ticket to the remote server under 131 its name. You could give that remote server an identity in the local 132 realm and then have that remote server maintain a separate secret for 133 each alias it is known as. Alternatively you could arrange to have 134 the local realm issue a referral to the remote realm and notify the 135 requesting client of the server's remote name that should be used in 136 order to request a ticket. 138 This memo proposes a solution for these problems and simplifies 139 administration by minimizing the configuration information needed on 140 each computer using Kerberos. Specifically it describes a mechanism 141 to allow the KDC to handle canonicalization of names, provide for 142 principal aliases for users and services and provide a mechanism for 143 the KDC to determine the trusted realm authentication path by being 144 able to generate referrals to other realms in order to locate 145 principals. 147 Two kinds of KDC referrals are introduced in this memo: 149 1. Client referrals, in which the client doesn't know which realm 150 contains a user account. 151 2. Server referrals, in which the client doesn't know which realm 152 contains a server account. 154 2. Conventions Used in This Document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 3. Requesting a Referral 162 In order to request referrals defined in section 5, 6, and 7, the 163 Kerberos client MUST explicitly request the canonicalize KDC option 164 (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to 165 the KDC that the client is prepared to receive a reply that contains 166 a principal name other than the one requested. 168 KDCOptions ::= KerberosFlags 169 -- canonicalize (15) 170 -- other KDCOptions values omitted 172 The client should expect, when sending names with the "canonicalize" 173 KDC option, that names in the KDC's reply MAY be different than the 174 name in the request. A referral TGT is a cross realm TGT that is 175 returned with the server name of the ticket being different from the 176 server name in the request [RFC4120]. 178 4. Realm Organization Model 180 This memo assumes that the world of principals is arranged on 181 multiple levels: the realm, the enterprise, and the world. A KDC may 182 issue tickets for any principal in its realm or cross-realm tickets 183 for realms with which it has a direct trust relationship. The KDC 184 also has access to a trusted name service that can resolve any name 185 from within its enterprise into a realm. This trusted name service 186 removes the need to use an un-trusted DNS lookup for name resolution. 188 For example, consider the following configuration, where lines 189 indicate trust relationships: 191 MS.COM 192 / \ 193 / \ 194 OFFICE.MS.COM NTDEV.MS.COM 196 In this configuration, all users in the MS.COM enterprise could have 197 a principal name such as alice@MS.COM, with the same realm portion. 198 In addition, servers at MS.COM should be able to have DNS host names 199 from any DNS domain independent of what Kerberos realm their 200 principals reside in. 202 5. Client Name Canonicalization 204 A client account may have multiple principal names. More useful, 205 though, is a globally unique name that allows unification of email 206 and security principal names. For example, all users at MS may have 207 a client principal name of the form "joe@MS.COM" even though the 208 principals are contained in multiple realms. This global name is 209 again an alias for the true client principal name, which indicates 210 what realm contains the principal. Thus, accounts "alice" in the 211 realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as "alice@ 212 MS.COM" and "bob@MS.COM". 214 This utilizes a new client principal name type, as the AS-REQ message 215 only contains a single realm field, and the realm portion of this 216 name doesn't correspond to any Kerberos realm. Thus, the entire name 217 "alice@MS.COM" is transmitted as a single component in the client 218 name field of the AS-REQ message, with a name type of NT-ENTERPRISE 219 [RFC4120]. The KDC will recognize this name type and then transform 220 the requested name into the true principal name. The true principal 221 name can be using a name type different from the requested name type. 222 Typically the true principal name will be a NT-PRINCIPAL [RFC4120]. 224 If the "canonicalize" KDC option is set, then the KDC MAY change the 225 client principal name and type in the AS response and ticket returned 226 from the name type of the client name in the request. For example 227 the AS request may specify a client name of "bob@MS.COM" as an NT- 228 ENTERPRISE name with the "canonicalize" KDC option set and the KDC 229 will return with a client name of "104567" as a NT-UID. 231 It is assumed that the client discovers whether the KDC supports the 232 NT-ENTERPRISE name type via out of band mechanisms. 234 6. Client Referrals 236 The simplest form of ticket referral is for a user requesting a 237 ticket using an AS-REQ. In this case, the client machine will send 238 the AS-REQ to a convenient trusted realm, for example the realm of 239 the client machine. In the case of the name alice@MS.COM, the client 240 MAY optimistically choose to send the request to MS.COM. The realm 241 in the AS-REQ is always the name of the realm that the request is for 242 as specified in [RFC4120]. 244 The KDC will try to lookup the name in its local account database. 245 If the account is present in the realm of the request, it SHOULD 246 return a KDC reply structure with the appropriate ticket. 248 If the account is not present in the realm specified in the request 249 and the "canonicalize" KDC option is set, the KDC will try to lookup 250 the entire name, alice@MS.COM, using a name service. If this lookup 251 is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN 252 [RFC4120]. If the lookup is successful, it MUST return an error 253 KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm 254 field will contain either the true realm of the client or another 255 realm that MAY have better information about the client's true realm. 256 The client SHALL NOT use a cname returned from a referral until that 257 name is validated. 259 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 260 new AS request with the same client principal name used to generate 261 the first referral to the realm specified by the realm field of the 262 Kerberos error message from the first request. The client SHOULD 263 repeat these steps until it finds the true realm of the client. To 264 avoid infinite referral loops, an implementation should limit the 265 number of referrals. A suggested limit is 5 referrals before giving 266 up. 268 In Microsoft's current implementation through the use of global 269 catalogs any domain in one forest is reachable from any other domain 270 in the same forest or another trusted forest with 3 or less 271 referrals. A forest is a collection of realms with hierarchical 272 trust relationships: there can be multiple trust trees in a forest; 273 each child and parent realm pair and each root realm pair have 274 bidirectional transitive direct rusts between them. 276 The true principal name of the client, returned in AS-REQ, can be 277 validated in a subsequent TGS message exchange where its value is 278 communicated back to the KDC via the authenticator in the PA-TGS-REQ 279 padata [RFC4120]. 281 7. Server Referrals 283 The primary difference in server referrals is that the KDC MUST 284 return a referral TGT rather than an error message as is done in the 285 client referrals. There needs to be a place to include in the reply 286 information about what realm contains the server. This is done by 287 returning information about the server name in the pre-authentication 288 data field of the KDC reply [RFC4120], as specified later in this 289 section. 291 If the KDC resolves the server principal name into a principal in the 292 realm specified by the service realm name, it will return a normal 293 ticket. 295 If the "canonicalize" flag in the KDC options is not set, the KDC 296 MUST only look up the name as a normal principal name in the 297 specified server realm. If the "canonicalize" flag in the KDC 298 options is set and the KDC doesn't find the principal locally, the 299 KDC MAY return a cross-realm ticket granting ticket to the next hop 300 on the trust path towards a realm that may be able to resolve the 301 principal name. The true principal name of the server SHALL be 302 returned in the padata of the reply if it is different from what is 303 specified the request. 305 When a referral TGT is returned, the KDC MUST return the target realm 306 for the referral TGT as an KDC supplied pre-authentication data 307 element in the response. This referral information in pre- 308 authentication data MUST be encrypted using the session key from the 309 reply ticket. The key usage value for the encryption operation used 310 by PA-SERVER-REFERRAL is 26. 312 The pre-authentication data returned by the KDC, which contains the 313 referred realm and the true principal name of server, is encoded in 314 DER as follows. 316 PA-SERVER-REFERRAL 25 318 PA-SERVER-REFERRAL-DATA ::= EncryptedData 319 -- ServerReferralData -- 321 ServerReferralData ::= SEQUENCE { 322 referred-realm [0] Realm OPTIONAL, 323 -- target realm of the referral TGT 324 true-principal-name [1] PrincipalName OPTIONAL, 325 -- true server principal name 326 ... 327 } 329 Clients SHALL NOT accept a reply ticket, whose the server principal 330 name is different from that of the request, if the KDC response does 331 not contain a PA-SERVER-REFERRAL padata entry. 333 The referred-realm field is present if and only if the returned 334 ticket is a referral TGT, not a service ticket for the requested 335 server principal. 337 When a referral TGT is returned and the true-principal-name field is 338 present, the client MUST use that name in the subsequent requests to 339 the server realm when following the referral. 341 Client SHALL NOT accept a true server principal name for a service 342 ticket if the true-principal-name field is not present in the PA- 343 SERVER-REFERRAL data. 345 The client will use this referral information to request a chain of 346 cross-realm ticket granting tickets until it reaches the realm of the 347 server, and can then expect to receive a valid service ticket. 349 However an implementation should limit the number of referrals that 350 it processes to avoid infinite referral loops. A suggested limit is 351 5 referrals before giving up. 353 Here is an example of a client requesting a service ticket for a 354 service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM. 356 +NC = Canonicalize KDCOption set 357 +PA-REFERRAL = returned PA-SERVER-REFERRAL 358 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM 359 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 360 containing MS.COM as the referred realm with no 361 true-principal-name 362 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM 363 S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL 364 containing NTDEV.MS.COM as the referred realm with no 365 true-principal-name 366 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM 367 S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM 369 8. Cross Realm Routing 371 The current Kerberos protocol requires the client to explicitly 372 request a cross-realm TGT for each pair of realms on a referral 373 chain. As a result, the client need to be aware of the trust 374 hierarchy and of any short-cut trusts (those that aren't parent- 375 child trusts). 377 Instead, using the server referral routing mechanism as defined in 378 Section 7, The KDC will determine the best path for the client and 379 return a cross-realm TGT as the referral TGT, and the target realm 380 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 382 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 383 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 384 response does not contain the PA-SERVER-REFERRAL padata. 386 9. Compatibility with Earlier Implementations of Name Canonicalization 388 The Microsoft Windows 2000 and Windows 2003 releases included an 389 earlier form of name-canonicalization [XPR]. Here are the 390 differences: 392 1) The TGS referral data is returned inside of the KDC message as 393 "encrypted pre-authentication data". 395 EncKDCRepPart ::= SEQUENCE { 396 key [0] EncryptionKey, 397 last-req [1] LastReq, 398 nonce [2] UInt32, 399 key-expiration [3] KerberosTime OPTIONAL, 400 flags [4] TicketFlags, 401 authtime [5] KerberosTime, 402 starttime [6] KerberosTime OPTIONAL, 403 endtime [7] KerberosTime, 404 renew-till [8] KerberosTime OPTIONAL, 405 srealm [9] Realm, 406 sname [10] PrincipalName, 407 caddr [11] HostAddresses OPTIONAL, 408 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 409 } 411 2) The preauth data type definition in the encrypted preauth data is 412 as follows: 414 PA-SVR-REFERRAL-INFO 20 416 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 417 referred-name [1] PrincipalName OPTIONAL, 418 referred-realm [0] Realm 419 }} 421 3) When [I-D.ietf-cat-kerberos-pk-init] is used, the NT-ENTERPRISE 422 client name is encoded as a Subject Alternative Name (SAN) 423 extension [RFC3280] in the client's X.509 certificate. The type 424 of the otherName field for this SAN extension is AnotherName 425 [RFC3280]. The type-id field of the type AnotherName is id-ms-sc- 426 logon-upn (1.3.6.1.4.1.311.20.2.3) and the value field of the type 427 AnotherName is a KerberosString [RFC4120]. The value of this 428 KerberosString type is the single component in the name-string 429 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 431 10. Security Considerations 433 For the AS exchange case, it is important that the logon mechanism 434 not trust a name that has not been used to authenticate the user. 435 For example, the name that the user enters as part of a logon 436 exchange may not be the name that the user authenticates as, given 437 that the KDC_ERR_WRONG_REALM error may have been returned. The 438 relevant Kerberos naming information for logon (if any), is the 439 client name and client realm in the service ticket targeted at the 440 workstation that was obtained using the user's initial TGT. 442 How the client name and client realm is mapped into a local account 443 for logon is a local matter, but the client logon mechanism MUST use 444 additional information such as the client realm and/or authorization 445 attributes from the service ticket presented to the workstation by 446 the user, when mapping the logon credentials to a local account on 447 the workstation. 449 11. Acknowledgments 451 The authors wish to thank Ken Raeburn for his comments and 452 suggestions. 454 Sam Hartman, Ken Raeburn, and authors came up with the idea of using 455 the ticket key to encrypt the referral data, which prevents cut and 456 paste attack using the referral data and referral TGTs. 458 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 459 version of this document. 461 12. References 463 12.1. Normative References 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, March 1997. 468 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 469 Kerberos Network Authentication Service (V5)", RFC 4120, 470 July 2005. 472 12.2. Informative References 474 [I-D.ietf-cat-kerberos-pk-init] 475 Tung, B. and L. Zhu, "Public Key Cryptography for Initial 476 Authentication in Kerberos", 477 draft-ietf-cat-kerberos-pk-init-34 (work in progress), 478 February 2006. 480 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 481 X.509 Public Key Infrastructure Certificate and 482 Certificate Revocation List (CRL) Profile", RFC 3280, 483 April 2002. 485 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation 486 of Crossrealm Referral Handling in the MIT Kerberos 487 Client", Network and Distributed System Security 488 Symposium, February 2001. 490 Appendix A. Document history 492 Version -07: Re-issued with new editor. Fixed up some references. 493 Started history. 495 Authors' Addresses 497 Kenneth Raeburn 498 Massachusetts Institute of Technology 499 77 Massachusetts Avenue 500 Cambridge, MA 02139 501 US 503 Email: raeburn@mit.edu 505 Larry Zhu 506 Microsoft Corporation 507 One Microsoft Way 508 Redmond, WA 98052 509 US 511 Email: lzhu@microsoft.com 513 Karthik Jaganathan 514 Microsoft Corporation 515 One Microsoft Way 516 Redmond, WA 98052 517 US 519 Email: karthikj@microsoft.com 521 Intellectual Property Statement 523 The IETF takes no position regarding the validity or scope of any 524 Intellectual Property Rights or other rights that might be claimed to 525 pertain to the implementation or use of the technology described in 526 this document or the extent to which any license under such rights 527 might or might not be available; nor does it represent that it has 528 made any independent effort to identify any such rights. Information 529 on the procedures with respect to rights in RFC documents can be 530 found in BCP 78 and BCP 79. 532 Copies of IPR disclosures made to the IETF Secretariat and any 533 assurances of licenses to be made available, or the result of an 534 attempt made to obtain a general license or permission for the use of 535 such proprietary rights by implementers or users of this 536 specification can be obtained from the IETF on-line IPR repository at 537 http://www.ietf.org/ipr. 539 The IETF invites any interested party to bring to its attention any 540 copyrights, patents or patent applications, or other proprietary 541 rights that may cover technology that may be required to implement 542 this standard. Please address the information to the IETF at 543 ietf-ipr@ietf.org. 545 Disclaimer of Validity 547 This document and the information contained herein are provided on an 548 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 549 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 550 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 551 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 552 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 553 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 555 Copyright Statement 557 Copyright (C) The Internet Society (2006). This document is subject 558 to the rights, licenses and restrictions contained in BCP 78, and 559 except as set forth therein, the authors retain all their rights. 561 Acknowledgment 563 Funding for the RFC Editor function is currently provided by the 564 Internet Society.