1 2 3 4 5 6 7Network Working Group Ken'ichi Kamada 8INTERNET-DRAFT Shoichi Sakane 9Expires: January 10, 2008 Yokogawa Electric Corporation 10 July 9, 2007 11 12 13 Client-Friendly Cross-Realm Model for Kerberos 5 14 draft-kamada-krb-client-friendly-cross-02.txt 15 16 17 18 19Status of this Memo 20 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 30 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 35 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html. 38 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 41 42 This Internet-Draft expires on January 10, 2008. 43 44 45Copyright Notice 46 47 Copyright (C) The IETF Trust (2007). 48 49 50 51 52 53 54 55 56 57 58Kamada and Sakane [Page 1] 59 60Internet-Draft Client-Friendly Cross-Realm July 2007 61 62 63Abstract 64 65 This document proposes a cross-realm traversal model, which is 66 suitable for resource-limited clients, for Kerberos Version 5. This 67 model provides a way to move the cost of consecutive Ticket-Granting 68 Service (TGS) exchanges from clients to Key Distribution Centers 69 (KDCs) and a way to reduce the traversal cost by generating a direct 70 inter-realm relationship between two realms. The document describes 71 behavior of clients and KDCs, but does not specify any wire format, 72 which need to be specified separately. 73 74 75Table of Contents 76 77 1. Introduction ................................................. 3 78 2. Problems on Client Performance ............................... 3 79 2.1. Long Authentication Path ................................ 4 80 2.2. Client-Centric Ticketing ................................ 4 81 3. Proposal of Client-Friendly Cross-Realm Model ................ 4 82 3.1. Temporary Inter-Realm Relationship Generation Mode ...... 5 83 3.2. Attorney Ticketing Mode ................................. 6 84 3.3. Combination of the Two Modes ............................ 7 85 4. Advantage of The Proposed Model for Deployment ............... 8 86 4.1. Compatibility with Traditional Kerberos Deployment ...... 8 87 4.2. Orthogonality of the Two Modes .......................... 8 88 5. Front-End Protocol for Attorney Ticketing Mode ............... 9 89 6. Related Protocols Currently Proposed ......................... 10 90 6.1. PKCROSS ................................................. 10 91 6.2. XTGS .................................................... 10 92 7. Interoperability Considerations .............................. 10 93 8. Security Considerations ...................................... 11 94 8.1. Denial of Service (DoS) ................................. 11 95 8.2. Ticketing Policy ........................................ 11 96 9. IANA Considerations .......................................... 12 97 10. Acknowledgments .............................................. 12 98 11. References ................................................... 12 99 11.1. Normative References ................................... 12 100 11.2. Informative References ................................. 12 101 Authors' Addresses ............................................... 13 102 Full Copyright Statement ......................................... 13 103 Intellectual Property Statement .................................. 13 104 105 106 107 108 109 110 111 112 113 114Kamada and Sakane [Page 2] 115 116Internet-Draft Client-Friendly Cross-Realm July 2007 117 118 1191. Introduction 120 121 Kerberos Version 5 [RFC4120] has a concept of cross-realm 122 authentication so that principals in different realms can 123 authenticate each other. However in the current cross-realm model, 124 each client has to traverse the authentication path, and the burden 125 of the traversal is not negligible for clients with limited 126 resources, e.g., computational speed or power supply [CRPS]. 127 128 In the current cross-realm operation, a client obtains a service 129 ticket for a remote principal in the following steps: 130 131 1) N TGSes to get cross-realm TGTs in order to traverse the 132 intermediate realms, where N is the number of transit, and 133 134 2) One TGS to get the final service ticket. 135 136 That is, the client needs to perform N + 1 transactions to obtain a 137 ticket for the remote service. 138 139 This document proposes a new cross-realm model, which consists of 140 "temporary inter-realm relationship generation mode" and "attorney 141 ticketing mode". The former is intended to reduce transit cost 142 itself, and the latter is to move the cost from clients to KDCs. The 143 document describes behavior of clients and KDCs, but does not specify 144 any wire format, which need to be specified separately. 145 146 Terms defined in section 1.7 of RFC 4120 are used throughout this 147 document. 148 149 1502. Problems on Client Performance 151 152 In the current model of cross-realm operation, a client has to 153 transit all realms on the path to the destination realm. When the 154 source realm and the destination realm have a direct inter-realm 155 relationship, a client is able to obtain a service ticket with two 156 TGS transactions (one for a cross-realm TGT and another for the 157 service ticket). When the realms have a multi-hop relationship, a 158 client must transit the intermediate realms before it obtains the 159 service ticket. That is, the client's task increases in proportion 160 to the distance of the relationship. 161 162 Two issues can be observed here behind the client load, which are 163 described in the following subsections. 164 165 166 167 168 169 170Kamada and Sakane [Page 3] 171 172Internet-Draft Client-Friendly Cross-Realm July 2007 173 174 1752.1. Long Authentication Path 176 177 When a client wants to get a service ticket for a remote realm, it 178 must transit to the remote realm by traversing the intermediate 179 realms on the authentication path to the remote realm. The result of 180 traversal is cached as a cross-realm TGT, but it is nothing more than 181 a per-client optimization. Thus all clients accessing a remote realm 182 must pay the cost separately, even if their resources are limited. 183 For a long authentication path, the cost of the whole system becomes 184 large. 185 1862.2. Client-Centric Ticketing 187 188 In Kerberos, any service tickets or cross-realm TGTs are issued via 189 TGS, where a client present a ticket for the TGS and obtains a next 190 ticket. Currently, all TGS transactions are initiated by the client 191 and it needs to get all necessary cross-realm TGTs iteratively before 192 the final service ticket. This process is a burden to a resource- 193 limited client. 194 195 1963. Proposal of Client-Friendly Cross-Realm Model 197 198 In this section, two modes of operation are introduced, "Temporary 199 Inter-Realm Relationship Generation Mode" and "Attorney Ticketing 200 Mode", to solve the issues described in the previous section. These 201 two modes are designed to be independent, that is, can be used 202 separately or in combination. 203 204 Temporary Inter-Realm Relationship Generation Mode solves the issue 205 of the long authentication path. In this mode, if the source realm 206 and the destination realm do not have a direct inter-realm 207 relationship, the source KDC traverses the authentication path by 208 itself, contacts with the remote KDC, and generates a direct inter- 209 realm relationship between them. After that, the source KDC can 210 issue direct inter-realm TGTs for the destination realm. The purpose 211 of this mode is to reduce the traversal cost itself by caching the 212 result of traversal. 213 214 Attorney Ticketing Mode solves the issue of the client-centric 215 ticketing. Consecutive TGS transactions to get cross-realm TGTs 216 and/or a final service ticket are initiated by a client in the 217 traditional Kerberos, whereas a KDC undertake that process in this 218 mode. The purpose of this mode is to shift the cost of TGSes from a 219 client to a KDC. This does not reduce the cost itself. 220 221 222 223 224 225 226Kamada and Sakane [Page 4] 227 228Internet-Draft Client-Friendly Cross-Realm July 2007 229 230 2313.1. Temporary Inter-Realm Relationship Generation Mode 232 233 Temporary inter-realm relationship generation mode enables a KDC to 234 issue an inter-realm TGT directly to a remote KDC with which the KDC 235 doesn't preshare an inter-realm key. To issue an inter-realm TGT 236 directly, a temporary inter-realm key needs to be provided somehow. 237 To achieve that, the local KDC obtains a special ticket for the 238 remote KDC and uses its session key as an inter-realm key. This 239 methodology was introduced by PKCROSS [PKCROSS]. In this document, 240 that special ticket is called as an "inter-KDC ticket", and an inter- 241 realm TGT generated from an inter-KDC ticket is called as a "direct 242 inter-realm TGT". 243 244 How does the local KDC reach the remote KDC is out of scope of this 245 model, but we can easily come up with 1) traversing a long 246 authentication path if available or 2) using PKINIT. In the context 247 of this model, PKCROSS is interpreted as a combination of this mode 248 and PKINIT. 249 250 This document does not standardize a specific protocol, but an inter- 251 KDC ticket will have the following form: 252 253 - its sname has a special form (PKCROSS proposes 254 "pkcross/realm@REALM", but it would be better to use a more 255 general name than "pkcross"), 256 257 and a direct inter-realm TGT will have the following form: 258 259 - its TicketExtensions field [KRBEXT] contains the inter-KDC ticket, 260 and 261 262 - it is protected by the session key (or the sub-session key) of the 263 inter-KDC ticket. 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282Kamada and Sakane [Page 5] 283 284Internet-Draft Client-Friendly Cross-Realm July 2007 285 286 287 client C KDC-L KDC-I KDC-R 288 -------- ----- ----- ----- 289 290 1. --------TGS-REQ--------> 291 2. [Reach to KDC-R in any way.] 292 [Below is an example of PKCROSS.] 293 ------------PKINIT------------> 294 <----------XTKT(L,R)----------- 295 3. <--TKT(C,R)w/XTKT(L,R)-- 296 4. ----------------------TGS-REQ------------------------> 297 5. <---------------------TKT(C,S)------------------------ 298 299 [Note: TKT(x,y) means a ticket whose cname is x and sname is y. ] 300 [ XTKT is an inter-KDC ticket. See PKCROSS. ] 301 [ The client C and KDC-L belong to the local realm L. ] 302 [ The KDC-I is a KDC of an intermediate realm I. ] 303 [ The KDC-R is a KDC of the remote realm R. ] 304 305 1. The client C sends a normal TGS-REQ to KDC-L, requesting 306 a cross-realm TGT to KDC-R. 307 2. KDC-L reaches KDC-R in any way and obtains a XTKT. 308 There is no standardized way to achieve this step yet. 309 PKCROSS is one candidate. We could also standardize a way 310 in which KDC-L normally transits to KDC-R and obtains an XTKT. 311 3. KDC-L generates a cross-realm TGT that is from C to KDC-R 312 and returns to it to C. 313 4. The same with the traditional cross-realm TGS. 314 5. The same with the traditional cross-realm TGS. 315 316 Figure 1: Message Flow of Temporary Inter-Realm Relationship 317 Generation 318 3193.2. Attorney Ticketing Mode 320 321 Traditionally, a Kerberos client repeats TGS transactions until it 322 gets the final ticket. For example, it has a TGT for its own realm 323 and wants to get a ticket for a service in 3-hop neighbor realm, then 324 it will: 325 326 1) Present the TGT and get a cross-realm TGT for the next realm, 327 328 2) Present the 1st cross-realm TGT and get a cross-realm TGT for the 329 2nd next realm, 330 331 3) Present the 2nd cross-realm TGT and get a cross-realm TGT for the 332 final realm, and 333 334 335 336 337 338Kamada and Sakane [Page 6] 339 340Internet-Draft Client-Friendly Cross-Realm July 2007 341 342 343 4) Present the final cross-realm TGT and get a service ticket. 344 345 Attorney ticketing mode enables the client to delegate the KDC to 346 perform all transactions listed above on behalf of the client. An 347 example message flow is shown in Figure 2. The client entrust the 348 KDC with its TGT (step 1). The KDC "impersonates" the client and 349 performs all necessary TGS transactions (steps 2 to 4), and returns 350 the final ticket to the client (step 5). 351 352 client C KDC-L KDC-I KDC-R 353 -------- ----- ----- ----- 354 355 1. --------TGS-REQ--------> 356 2. TKT(C,I) 357 3. ----TGS-REQ----> 358 <---TKT(C,R)---- 359 4. ------------TGS-REQ-----------> 360 <-----------TKT(C,S)----------- 361 5. <-------TKT(C,S)-------- 362 363 1. The client C sends a special TGS-REQ, which indicates attorney 364 ticketing mode requesting a service ticket for a server S 365 instead of a cross-realm TGT, to KDC-L. 366 2. KDC-L internally generates a cross-realm TGT that is from C 367 to KDC-I, but does not return it to C. 368 3. KDC-L uses the generated cross-realm TGT by itself, and sends 369 a TGS-REQ to KDC-I, which requests a cross-realm TGT from C 370 to KDC-R. 371 4. KDC-L use the obtained cross-realm TGT by itself, and sends 372 a TGS-REQ to KDC-R, which requests a service ticket from C 373 to S. 374 5. KDC-L returns the final service ticket to C. 375 376 Figure 2: Message Flow of Attorney Ticketing Mode 377 3783.3. Combination of the Two Modes 379 380 Figure 3 shows a typical message flow when the temporary inter-realm 381 relationship generation mode and the attorney ticketing mode are used 382 in combination. The figure shows the case of the initial contact, so 383 a transaction to obtain an inter-KDC ticket is shown (step 2), but it 384 is infrequently used because the XTKT is cached. Usually, only two 385 round-trips do all the work. 386 387 388 389 390 391 392 393 394Kamada and Sakane [Page 7] 395 396Internet-Draft Client-Friendly Cross-Realm July 2007 397 398 399 client C KDC-L KDC-I KDC-R 400 -------- ----- ----- ----- 401 402 1. --------TGS-REQ--------> 403 2. [Temporary inter-realm relationship 404 generation mode runs here.] 405 ------------PKINIT------------> 406 <----------XTKT(L,R)----------- 407 3. [Attorney ticketing mode runs here.] 408 TKT(C,R)w/XTKT(L,R) 409 4. ------------TGS-REQ-----------> 410 <-----------TKT(C,S)----------- 411 5. <-------TKT(C,S)-------- 412 413 Figure 3: Message Flow When Temporary Inter-Realm Relationship 414 Generation Mode and Attorney Ticketing Mode 415 Are Combined 416 417 4184. Advantage of The Proposed Model for Deployment 419 4204.1. Compatibility with Traditional Kerberos Deployment 421 422 Temporary inter-realm relationship generation involves only KDCs. 423 From the viewpoint of a client (and a server), it seems that there is 424 a direct inter-realm relationship between two realms. This means 425 that temporary inter-realm relationship generation mode needs to be 426 deployed only in KDCs. This property is advantageous, because it 427 does not affect large installed base of clients. One impeding factor 428 in practice is that some existing implementations cannot handle 429 ticket extensions transparently. This is further discussed in 430 Interoperability Considerations section. 431 432 Attorney ticketing mode involves only a client and its local KDC. 433 From the viewpoint of the remote KDC, TGS-REQs from a KDC as an 434 attorney cannot be distinguished from those from a "genuine" client 435 (except caddr; see Interoperability Considerations section). 436 Resulting service ticket is identical to the traditional one, so the 437 remote server has nothing to do with this mode. In short, attorney 438 ticketing mode can be deployed in local realm, independently of the 439 remote deployment. The merit of this property is large, because 440 remote realms are often in different administration. 441 4424.2. Orthogonality of the Two Modes 443 444 Temporary inter-realm relationship generation mode and attorney 445 ticketing mode are independent concepts. Both can be implemented 446 separately or can be used in combination. When they are combined, 447 448 449 450Kamada and Sakane [Page 8] 451 452Internet-Draft Client-Friendly Cross-Realm July 2007 453 454 455 the load of clients are shifted to KDCs and additional load of KDCs 456 are minimized, thus efficient cross-realm environment is achieved. 457 458 4595. Front-End Protocol for Attorney Ticketing Mode 460 461 This document does not specify wire-level protocol, which will be 462 done in another document. This section provides some candidates for 463 the protocol, which is used to request attorney ticketing mode from a 464 KDC (Figure 4). This protocol can be used for other than attorney 465 ticketing mode, as long as the KDC's behavior for clients is 466 identical to the mode. 467 468 +------+ +-------+ 469 |client|------------>| KDC |-------------> cross-realm cloud 470 +------+ +-------+ Cross-realm 471 Front-end protocol traversal by KDC 472 to request a final (Attorney Ticketing Mode) 473 ticket in one shot 474 or 475 476 -------------> remote KDC (directly) 477 XTGSP 478 479 or 480 481 -------------> 482 Whatever the KDC chooses 483 484 Figure 4: Front-End Protocol for Attorney Ticketing Mode 485 486 Candidate 1: Implicit Signaling 487 488 A client simply requests a final ticket to the local KDC. If the 489 KDC supports this implicit protocol, it will process the request. 490 If not, KDC_ERR_S_PRINCIPAL_UNKNOWN will be returned. A possible 491 drawback is that if a requested final ticket is for a TGS, the KDC 492 does not know whether the client expects normal mode or attorney 493 mode. In addition, implicit signaling can conflict with future 494 extensions. 495 496 Candidate 2: Explicit Signaling 497 498 A flag in KDCOptions or pre-authentication can be used to request 499 attorney mode. 500 [[what happens if not supported?]] 501 502 503 504 505 506Kamada and Sakane [Page 9] 507 508Internet-Draft Client-Friendly Cross-Realm July 2007 509 510 5116. Related Protocols Currently Proposed 512 5136.1. PKCROSS 514 515 PKCROSS will be usable as a protocol for temporary inter-realm 516 relationship generation mode. 517 5186.2. XTGS 519 520 The purpose of XTGS protocol is similar to that of this model, but 521 the behavior is somewhat different [XTGS]. If XTGS is viewed from 522 the perspective of this model, it blends the two modes indivisibly to 523 reduce the number of messages between KDCs as far as possible at the 524 price of the abstraction of cross-realm TGTs and inter-KDC tickets. 525 526 Once a front-end (i.e., between a client and a KDC) protocol to 527 request attorney ticketing mode is standardized, XTGS can be used as 528 an opaque back-end. 529 530 5317. Interoperability Considerations 532 533 User-to-user mode 534 The protocol for the attorney mode should be able to indicate 535 user-to-user authentication. 536 537 The addresses field in TGS-REQ 538 This field is copied into the caddr field in EncTicketPart, so if 539 this field is used in a TGS-REQ, the resulting ticket can be used 540 only from the specified addresses. When the local KDC receives a 541 TGS-REQ requesting attorney mode, it should copy the addresses 542 field only into the final TGS-REQ in the attorney process. It 543 must not copy the field into TGS-REQs to intermediate KDCs, 544 because resulting tickets are to be used by the local KDC instead 545 of the client. 546 547 Opacity of ticket extensions 548 The ticket extensions defined in rfc1510ter [KRBEXT] extends the 549 Ticket ASN.1 type, which is visible to clients. This is not a 550 problem if a client implementation treats a Ticket as an opaque 551 data, and there are such implementations, but unfortunately the 552 major free implementations do not. On the other hand, there is a 553 proposal of etype-based ticket extensions [TKTEXTALT]. It 554 encapsulates cleartext bits in the enc-part component of a Ticket. 555 It should not have any problems of opacity. 556 557 [[negotiation of various parameters]] 558 559 560 561 562Kamada and Sakane [Page 10] 563 564Internet-Draft Client-Friendly Cross-Realm July 2007 565 566 567 [[If there are multiple authentication paths and a client has enough 568 knowledge, it could choose which path to take. With attorney 569 ticketing mode, it cannot because it is up to the KDC to select the 570 path. Is this a problem? With temporary inter-realm relationship 571 generation mode, it can as before.]] 572 573 [[co-existence with the plain Kerberos; attorney ticketing mode 574 client vs. non-attorney KDC; inter-realm generating local KDC vs. 575 non-generating remote KDC]] 576 577 [[anything to do with referral?]] 578 579 [[when a KDC in attorney mode receives a KRB-ERROR?]] 580 581 5828. Security Considerations 583 5848.1. Denial of Service (DoS) 585 586 A KDC that implements attorney ticketing mode needs to initiate 587 multiple TGS-REQ upon a request from a client. This means that the 588 KDC will have some states in it and may suffer from DoS attacks. 589 590 Fortunately, attorney ticketing mode can be requested in TGS-REQ, 591 which is only available to authenticated clients, thus, any untrusted 592 party cannot exploit this statefulness. 593 5948.2. Ticketing Policy 595 596 Attorney ticketing mode changes nothing about the messages sent to 597 the intermediate and remote KDCs. Those KDCs will not notice the 598 difference and their ticketing process have nothing to be changed. 599 600 Temporary inter-realm relationship generation mode dynamically 601 generates new authentication paths. This means that KDCs that are 602 involved in the transit of a client are different from those that 603 would be involved if this mode were not used. 604 605 - Parameters of cross-realm TGTs (lifetime and flags) for a new 606 relationship need to be dynamically transferred (a la PKCROSS). 607 608 - How to handle the transited fields in inter-KDC tickets, direct 609 inter-realm tickets, and service tickets? 610 611 - Where the remote KDC adds AuthorizationData and the end-server 612 checks it: there is no problem because it is a local matter of the 613 remote realm. 614 615 616 617 618Kamada and Sakane [Page 11] 619 620Internet-Draft Client-Friendly Cross-Realm July 2007 621 622 623 - Where an intermediate KDC adds AuthorizationData: traditionally it 624 is added in a cross-realm TGT and propagated to the service 625 ticket; now it will be propagated to the inter-KDC ticket. Should 626 AuthorizationData in an inter-KDC ticket be copied into a cross- 627 realm TGT or not? Even if it is copied, AuthorizationData on 628 inter-KDC ticket cannot represent per-client information, so if it 629 is necessary, temporary inter-realm relationship generation mode 630 must not be used. 631 632 6339. IANA Considerations 634 635 This document has no actions for IANA. 636 637 63810. Acknowledgments 639 640 The authors would like to acknowledge Saber Zrelli, Masahiro 641 Ishiyama, Atsushi Inoue, Kazunori Miyazawa, and Nobuo Okabe for 642 contributions to this document. 643 644 64511. References 646 64711.1. Normative References 648 649 [KRBEXT] Yu, T., "The Kerberos Network Authentication Service 650 (Version 5)", draft-ietf-krb-wg-rfc1510ter-04, Work in 651 Progress, March 2007. 652 653 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 654 Kerberos Network Authentication Service (V5)", RFC 655 4120, July 2005. 656 65711.2. Informative References 658 659 [CRPS] Sakane, S., Zrelli, S., M. Ishiyama, "Problem statement 660 on the cross-realm operation of Kerberos in a specific 661 system", draft-sakane-krb-cross-problem-statement-02, 662 Work in Progress, April 2007. 663 664 [PKCROSS] Hur, M. et al., "Public Key Cryptography for Cross- 665 Realm Authentication in Kerberos", draft-ietf-cat- 666 kerberos-pk-cross-08 (expired), Work in Progress, 667 November 2001. 668 669 [TKTEXTALT] Message-ID: <tslfy54akcb.fsf@mit.edu>. 670 671 672 673 674Kamada and Sakane [Page 12] 675 676Internet-Draft Client-Friendly Cross-Realm July 2007 677 678 679 [XTGS] Zrelli, S. et al., "XTGSP, the Inter-TGS protocol for 680 cross-realm operations in Kerberos", draft-zrelli-krb- 681 xtgsp-01, Work in Progress, March 2007. 682 683Authors' Addresses 684 685 Ken'ichi Kamada 686 Shoichi Sakane 687 Yokogawa Electric Corporation 688 2-9-32 Nakacho, Musashino-shi, 689 Tokyo 180-8750 Japan 690 E-mail: Ken-ichi.Kamada@jp.yokogawa.com, 691 Shouichi.Sakane@jp.yokogawa.com 692 693 694Full Copyright Statement 695 696 Copyright (C) The IETF Trust (2007). 697 698 This document is subject to the rights, licenses and restrictions 699 contained in BCP 78, and except as set forth therein, the authors 700 retain all their rights. 701 702 This document and the information contained herein are provided on an 703 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 704 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 705 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 706 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 707 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 708 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 709 710Intellectual Property Statement 711 712 The IETF takes no position regarding the validity or scope of any 713 Intellectual Property Rights or other rights that might be claimed to 714 pertain to the implementation or use of the technology described in 715 this document or the extent to which any license under such rights 716 might or might not be available; nor does it represent that it has 717 made any independent effort to identify any such rights. Information 718 on the procedures with respect to rights in RFC documents can be 719 found in BCP 78 and BCP 79. 720 721 Copies of IPR disclosures made to the IETF Secretariat and any 722 assurances of licenses to be made available, or the result of an 723 attempt made to obtain a general license or permission for the use of 724 such proprietary rights by implementers or users of this 725 specification can be obtained from the IETF on-line IPR repository at 726 http://www.ietf.org/ipr. 727 728 729 730Kamada and Sakane [Page 13] 731 732Internet-Draft Client-Friendly Cross-Realm July 2007 733 734 735 The IETF invites any interested party to bring to its attention any 736 copyrights, patents or patent applications, or other proprietary 737 rights that may cover technology that may be required to implement 738 this standard. Please address the information to the IETF at ietf- 739 ipr@ietf.org. 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786Kamada and Sakane [Page 14] 787 788