1 2 3 4 5 6 7INTERNET-DRAFT S. Sakane 8Expires: April 29, 2007 Yokogawa Electric Corp. 9 S. Zrelli 10 JAIST 11 M. Ishiyama 12 Toshiba Corp. 13 October 26, 2006 14 15 16 Problem statement on the cross-realm operation 17 of Kerberos in a specific system 18 draft-sakane-krb-cross-problem-statement-01.txt 19 20 21 22 23Status of this Memo 24 25 By submitting this Internet-Draft, each author represents that any 26 applicable patent or other IPR claims of which he or she is aware 27 have been or will be disclosed, and any of which he or she becomes 28 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 34 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress". 39 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 42 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 46 This Internet-Draft expires in April 29, 2007. 47 48 49Copyright Notice 50 51 Copyright (C) The Internet Society (2006). 52 53 54 55 56 57 58S.Sakane, et al. [Page 1] 59 60Internet-Draft October 2006 61 62 63Abstract 64 65 There are some issues when the cross-realm operation of the Kerberos 66 Version 5 [RFC4120] is employed into the specific systems. This 67 document describes some manners of the real example, and lists 68 requirements of the operation in such real system. Then it clarifies 69 issues when we apply the cross-realm operation to such specific 70 system. 71 72 73 74Conventions used in this document 75 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 80 It is assumed that the readers are familiar with the terms and 81 concepts described in the Kerberos Version 5 [RFC4120]. 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114S.Sakane, et al. [Page 2] 115 116Internet-Draft October 2006 117 118 119Table of Contents 120 121 1. Introduction ................................................. 4 122 2. Kerberos system .............................................. 4 123 2.1. Kerberos basic operation ................................ 4 124 2.2. Cross-realm operation ................................... 5 125 3. Manner of operations in the real environment ................. 6 126 4. Requirement .................................................. 7 127 5. Issues ....................................................... 8 128 5.1. Scalability of the direct trust model ................... 8 129 5.2. Exposure to DoS Attacks ................................. 8 130 5.3. No PFS in case of the indirect trust model .............. 9 131 5.4. Unreliability of authentication chain ................... 9 132 5.5. Client's performance .................................... 9 133 5.6. Pre-authentication problem in roaming scenarios ......... 10 134 6. Implementation consideration ................................. 10 135 7. IANA Considerations .......................................... 11 136 8. Security Considerations ...................................... 11 137 9. Acknowledgments .............................................. 11 138 10. References ................................................... 11 139 10.1. Normative References ................................... 11 140 10.2. Informative References ................................. 11 141 Authors' Addresses ............................................... 12 142 Full Copyright Statement ......................................... 12 143 Intellectual Property Statement .................................. 13 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170S.Sakane, et al. [Page 3] 171 172Internet-Draft October 2006 173 174 1751. Introduction 176 177 The Kerberos Version 5 is a widely deployed mechanism that a server 178 can authenticate a client access. Each client belongs to a managed 179 domain called realm. Kerberos supports the authentication in case of 180 situation that a client and a server belong to different realms. 181 This is called the cross-realm operation. 182 183 Meanwhile, there are lots of manners of operation in the real system, 184 where Kerberos could be applied. Sometimes, there are several 185 managed domain in such system. and it requires the authentication 186 mechanism over the different managed domains. When the cross-realm 187 operation of Kerberos is applied to such specific systems, some 188 issues come out. 189 190 This document briefly describes the Kerberos Version 5 system and the 191 cross-realm operation. Then, it describes two real systems that can 192 be applied the Kerberos system, and describes nine requirements of 193 those systems in term both of management and operation. Finally, it 194 lists six issues of the cross-realm operation when it is applied to 195 those system. 196 197 Note that it might not describe whole of issues of the cross-realm 198 operation. It also does not propose any solution to solve issues 199 described in this document. In further step, we have to analyze, and 200 compare candidates of solutions. This work will be in another 201 document. 202 203 This document is assumed that the readers are familiar with the terms 204 and concepts described in the Kerberos Version 5 [RFC4120]. 205 206 2072. Kerberos system 208 209 2102.1. Kerberos basic operation 211 212 Kerberos [RFC4120] is a widely deployed authentication system. The 213 authentication process in Kerberos involves principals and a Key 214 Distribution Center (KDC). The principals can be users or services. 215 Each KDC maintains a principals database and shares a secret key with 216 each registered principal. 217 218 The authentication process allows a user to acquire the needed 219 credentials from the KDC. These credentials allow services to 220 authenticate the users before granting them access to the resources. 221 An important part of the credentials are called Tickets. There are 222 two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket. 223 224 225 226S.Sakane, et al. [Page 4] 227 228Internet-Draft October 2006 229 230 231 The TGT is obtained periodically from the KDC and has a limited limit 232 after which it expires and the user must renew it. The TGT is used 233 to obtain the other kind of tickets, Service Tickets. The user 234 obtains a TGT from the Authentication Service (AS), a logical 235 component of the KDC. The process of obtaining a TGT is referred to 236 as 'AS exchange'. When a TGT request is issued by an user, the AS 237 responds by sending a reply packet containing the credentials which 238 consists of the TGT along with a random key called 'TGS Session Key'. 239 The TGT contains a set of information encrypted using a secret key 240 associated with a special service referred to as TGS (Ticket Granting 241 Service). The TGS session key is encrypted using the user's key so 242 that the user can obtain the TGS session key only if she knows the 243 secret key shared with the KDC. The TGT then is used to obtain 244 Service Tickets from the Ticket Granting Service (TGS)- the second 245 component of the KDC. The process of obtaining service tickets is 246 referred to as 'TGS exchange'. The request for a service ticket 247 consists on a packet containing a TGT and an 'Authenticator'. The 248 Authenticator is encrypted using the TGS session key and contains the 249 identity of the user as well as time stamps (for protection against 250 replay attacks). After decrypting the TGT (which was encrypted by 251 the AS using the TGS's secret key), the TGS extracts the TGS session 252 key. Using that session key, it decrypts the Authenticator and 253 authenticates the user. Then, the TGS issues credentials requested 254 by the user. These credentials consist on a service ticket and a 255 session key that will be used to authenticate the user with the 256 desired application service. 257 258 2592.2. Cross-realm operation 260 261 The Kerberos protocol provides the cross-realm authentication 262 capabilities. This allows users to obtain service tickets to access 263 services in foreign realms. In order to access such services, the 264 users first contact their home KDC asking for a TGT that will be used 265 with the TGS of the foreign realm. If the home realm and the foreign 266 realm share keys and have an established trust relationship, the home 267 KDC delivers the requested TGT. 268 269 However, if the home realm does not share cross-realm keys with the 270 foreign realm, the home KDC will provide a TGT that can be used with 271 an intermediary foreign realm that is likely to be sharing cross- 272 realm keys with the target realm. The client can use this 273 'intermediary TGT' to communicate with the intermediary KDC which 274 will iterate the actions taken by the home KDC: If the intermediary 275 KDC does not share cross-realm keys with the target foreign realm it 276 will point the user to another intermediary KDC (just as in the first 277 exchange between the user and its home KDC). However, in the other 278 case (when it shares cross- realm keys with the target realm), the 279 280 281 282S.Sakane, et al. [Page 5] 283 284Internet-Draft October 2006 285 286 287 intermediary KDC will issue a TGT that can be used with the KDC of 288 the target realm. After obtaining a TGT for the desired foreign 289 realm, the client uses it to obtain service tickets from the TGS of 290 the foreign realm. Finally, the user access the service using the 291 service ticket. 292 293 When the realms belong to the same institution, a chain of trust can 294 be determined by the client or the KDC by following the DNS domain 295 hierarchy and supposing that the parent domains share keys with all 296 its child sub-domains. However, because the inter-realm trust model 297 is not necessarily constructing the hierarchic approach anytime, the 298 trust path must be specified manually. When intermediary realms are 299 involved, the success of the cross-realm operation completely depends 300 on the realms that are part of the authentication path. 301 302 3033. Manner of operations in the real environment 304 305 This section describes examples of operation in the real environment. 306 And it also describes its requirement in term of both management and 307 operation. These requirements make the issues easier understanding. 308 We refers to the world's largest petrochemical company [SHELLCHEM]. 309 It produces bulk petrochemicals and their delivery to large 310 industrial customers. There are 43 typical plants of the company all 311 over the world. They are managed by the operation sites placed in 35 312 countries. This section shows two examples of them. 313 314 One is the CSPC (CNOOC and Shell Petrochemical Company Limited) 315 [CSPC], an example of the centralized plant. The CSPC is a joint 316 enterprise of CNOOC and SHELL. Its plant is one of the hugest 317 systems of a petrochemical industry placed in the area of 3.4 square 318 meters in the north coast of Daya Bay, Guangdong, which is at the 319 southeast of China. 3,000 network segments are established in the 320 system. 16,000 control devices are connected to the local area 321 network. These devices belong to different 9 sub systems, A control 322 device has some control points, which are controlled and monitored by 323 other devices remotely. There are 200,000 control points in all. 324 They are controlled by 3 different control center. 325 326 Another is the NAM (Nederlandse Aardolie Maatschappij), an example of 327 the distributed plant system. The NAM is a partnership enterprise of 328 Shell and Exxon. It is a plant system group that geographically 329 distributes to scatter in the area of 863 square meters of 330 Netherlands. 26 plants, each is named "cluster", are scattered in 331 the area. They are connected each other by a private ATM WAN. Each 332 cluster has approximately 500-1,000 control devices. These devices 333 are managed by each local control center in each cluster. In the 334 entire system of the NAM, there are one million control points. 335 336 337 338S.Sakane, et al. [Page 6] 339 340Internet-Draft October 2006 341 342 343 The end control devices in the both of the systems are basically 344 connected to a local network by a twisted pair cable, which is a low 345 band-width of 32 kbps. Every system supposes that no ad-hoc device 346 is never connected to the system since they are well designed before 347 they are implemented. Low clock CPU, for example H8 [RNSS-H8] and 348 M16C [RNSS-M16C], are employed by many control devices. Furthermore, 349 to suppress power consumption, these CPU may be lowered the number of 350 clocks. A controller in this system collects condition of device 351 from multiple control devices, and the system uses them to make a 352 decision how to control devices. If it took time for data to reach, 353 they could not be associated. The travel time of data from the 354 device to the controller is demanded within 1 second. A part of the 355 operation, like control of these system, maintenance, and the 356 environmental monitoring, is consigned to an external organization. 357 Agents who are consigned walk around the plant to get their 358 information, or watch the plant from a remote site. Currently, each 359 plant is independently operated. However, it is not impossible to 360 monitor and control all of plants distributed in the world. 361 362 3634. Requirement 364 365 This section listed requirements derived from the previous section. 366 There are seven requirements in term of management domain separation. 367 368 A-1 It is necessary to allow different independent management 369 domains to coexist because two or more organizations enter to 370 the system. 371 372 A-2 It is necessary to allow a management domain to delegate its 373 management authority to its sub domains or another management 374 domain because the plants are distributed to the wide area. 375 376 A-3 It is necessary that a device controls other devices that belong 377 to a same domain from remote because the plants are distributed 378 to the wide area. 379 380 A-4 It is necessary that a device controls other devices that belong 381 to a different domain from local. 382 383 A-5 It is necessary that a device controls other devices that belong 384 to a different domain from remote. 385 386 A-6 It is necessary for the agents who are consigned to watch and 387 control the device at the plant, which is different domain from 388 the agents' one. 389 390 Because of above requirements, the cross-realm operation of Kerberos 391 392 393 394S.Sakane, et al. [Page 7] 395 396Internet-Draft October 2006 397 398 399 seems suitable for this system. The requirements derived from other 400 viewpoints is listed as follows. 401 402 B-1 It is demanded to reduce the management cost as much as 403 possible. 404 405 B-2 The communication for observing and controlling devices must 406 have confidentiality and integrity. And, it is necessary to 407 think about the threat of other security like the DoS attack. 408 409 B-3 It is necessary to consider the processing performance of the 410 device. And, it is necessary to suppress the power consumption 411 of the device. 412 413 B-4 It is necessary to consider bandwidth of the communication. 414 415 4165. Issues 417 418 This section lists the issues in the cross-realm operation when we 419 consider the above requirements. 420 421 4225.1. Scalability of the direct trust model 423 424 In the direct relationship of trust between each realm, the realms 425 involved in the cross-realm operation share keys and their respective 426 TGS principals are registered in each other's KDC. When direct trust 427 relationships are used, the KDC of each realm must maintain keys with 428 all foreign realms. This can become a cumbersome task when the 429 number of realms increase. This also increases maintenance cost. 430 431 This issue will happen as a by-product of a result meeting the 432 requirements A-1 and A-2, and is related to B-1. 433 434 4355.2. Exposure to DoS Attacks 436 437 One of the assumption made when allowing the cross-realm operation in 438 Kerberos is that users can communicate with KDCs located in remote 439 realms. This practice introduces security threats because KDCs are 440 open to the public network. Administrators may think of restricting 441 the access to the KDC to the trusted realms only. However, this 442 approach is not scalable and does not really protect the KDC. 443 Indeed, when the remote realms have several IP prefixes (e.g. control 444 centers or outsourcing companies, located world wide), then the 445 administrator of the local KDC must collect the list of prefixes that 446 belong to these organization. The filtering rules must then 447 448 449 450S.Sakane, et al. [Page 8] 451 452Internet-Draft October 2006 453 454 455 explicitly allow the incoming traffic from any host that belongs to 456 one of these prefixes. This makes the administrator's tasks more 457 complicated and prone to human errors. And also, the maintenance 458 cost increases. On the other hand, when ranges of external IP 459 addresses are allowed to communicate with the KDC, the risk of 460 becoming target to attacks from remote malicious users increases. 461 462 This issue will happen as a result meeting the requirements A-3, A-4 463 and A-5. And it is related to B-1 and B-2. 464 465 4665.3. No PFS in case of the indirect trust model 467 468 In [SPECCROSS], any KDC in the authentication path can learn the 469 session key that will be used between the client and the desired 470 service. This means that any intermediary realm is able to spoof the 471 identity either of the service or the client as well as to eavesdrop 472 on the communication between the client and the server. 473 474 This issue will happen as a by-product of a result meeting the 475 requirements A-1 and A-2, and is related to B-2. 476 477 4785.4. Unreliability of authentication chain 479 480 When the relationship of trust is constructed like a chain or 481 hierarchical, the authentication path is not dependable since it 482 strongly depends on intermediary realms that might not be under the 483 same authority. If any of the realms in the authentication path is 484 not available, then the principals of the end-realms can not perform 485 the cross-realm operation. 486 487 The end-point realms do not have full control and responsibility of 488 the success of the operations even if their respective KDCs are fully 489 functional. Dependability of a system decreases if the system relies 490 on uncontrolled components. We can not be sure at 100% about the 491 result of the authentication since we do not know how is it going in 492 intermediary realms. 493 494 This issue will happen as a by-product of a result meeting the 495 requirements A-1 and A-2, and is related to B-2. 496 497 4985.5. Client's performance 499 500 In the cross-realm operation, Kerberos clients have to perform TGS 501 exchanges with all the KDCs in the trust path, including the home KDC 502 and the target KDC. TGS exchange requires cryptographic operations. 503 504 505 506S.Sakane, et al. [Page 9] 507 508Internet-Draft October 2006 509 510 511 This exchange demands important processing time especially when the 512 client has limited computational capabilities. The overhead of these 513 cross-realm exchanges grows into unacceptable delays. 514 515 We ported the MIT Kerberos library (version 1.2.4), implemented a 516 Kerberos client on our original board with H8 (16-bit, 20MHz), and 517 measured the process time of each Kerberos message. It takes 195 518 milliseconds to perform a TGS exchange with the on-board H/W crypto 519 engine. Indeed, this result seems reasonable to the requirement of 520 the response time for the control network. However, we did not 521 modify the clock speed of the H8 during our measurement. The 522 processing time must be slower in a real environment because H8 is 523 used with lowered clock speed in such system. Also, the delays can 524 grow to unacceptable delays when the number of intermediary realms 525 increases. 526 527 This issue will happen as a by-product of a result meeting the 528 requirements A-1 and A-2, and is related to B-3. 529 530 5315.6. Pre-authentication problem in roaming scenarios 532 533 In roaming scenarios, the client needs to contact her home KDC to 534 obtain a cross-realm TGT for the local (or visited) realm. However, 535 the policy of the network access providers or the gateway in the 536 local network usually does not allow clients to communicate with 537 hosts in the Internet unless they provide valid authentication 538 credentials. In this manner, the client encounters a chicken-and-egg 539 problem where two resources are interdependent; the Internet 540 connection is needed to contact the home KDC and for obtaining 541 credentials, and on the other hand, the Internet connection is only 542 granted for clients who have valid credentials. As a result, the 543 Kerberos protocol can not be used as it is for authenticating roaming 544 clients requesting network access. 545 546 This issue will happen as a result meeting the requirements A-6. 547 548 5496. Implementation consideration 550 551 This document just describes issues of the cross-realm operation in 552 the specific systems. However, there are important matters to be 553 considered, when we solve these issues and implement solution. 554 Solution must not introduce new problem. Solution should use 555 existing components or protocols as much as possible, should not 556 introduce any definition of new component. Solution must not require 557 a KDC to have any additional process. You must not forget that there 558 would be a trade-off matter anytime. So an implementation may not 559 560 561 562S.Sakane, et al. [Page 10] 563 564Internet-Draft October 2006 565 566 567 solve all of the problems stated in this document. 568 569 5707. IANA Considerations 571 572 This document makes no request of IANA. 573 574 5758. Security Considerations 576 577 This document just clarifies some issues of the cross-realm operation 578 of the Kerberos V system. There is especially not describing 579 security. Some troubles might be caused to your system by malicious 580 user who misuses the description of this document if it dares to say. 581 582 5839. Acknowledgments 584 585 The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa, 586 Ken'ichi Kamada and Atsushi Inoue. They gave us lots of comments and 587 input for this document. 588 589 59010. References 591 592 59310.1. Normative References 594 595 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 596 Kerberos Network Authentication Service (V5)", RFC 597 4120, July 2005. 598 599 60010.2. Informative References 601 602 [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id= 603 531,00.html 604 605 [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing. 606 jsp&fp=/products/mpumcu/h8_family/ 607 608 [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi 609 ng.jsp&fp=/products/mpumcu/m16c_family/ 610 611 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 612 Requirement Levels", RFC 2119, March 1997. 613 614 615 616 617 618S.Sakane, et al. [Page 11] 619 620Internet-Draft October 2006 621 622 623 [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html 624 625 [SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C. 626 Walstad, "Specifying Kerberos 5 Cross-Realm 627 Authentication", Fifth Workshop on Issues in the Theory 628 of Security, Jan 2005. 629 630Authors' Addresses 631 632 Shoichi Sakane 633 Yokogawa Electric Corporation 634 2-9-32 Nakacho, Musashino-shi, 635 Tokyo 180-8750 Japan 636 E-mail: Shouichi.Sakane@jp.yokogawa.com, 637 638 639 Saber Zrelli 640 Japan Advanced Institute of Science and Technology 641 1-1 Asahidai, Nomi, 642 Ishikawa 923-1292 Japan 643 E-mail: zrelli@jaist.ac.jp 644 645 646 Masahiro Ishiyama 647 Toshiba Corporation 648 1, komukai-toshiba-cho, Saiwai-ku, 649 Kawasaki 212-8582 Japan 650 E-mail: masahiro@isl.rdc.toshiba.co.jp 651 652 653Full Copyright Statement 654 655 Copyright (C) The Internet Society (2006). 656 657 This document is subject to the rights, licenses and restrictions 658 contained in BCP 78, and except as set forth therein, the authors 659 retain all their rights. 660 661 This document and the information contained herein are provided on an 662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 664 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 665 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 666 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 668 669 670 671 672 673 674S.Sakane, et al. [Page 12] 675 676Internet-Draft October 2006 677 678 679Intellectual Property Statement 680 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; nor does it represent that it has 686 made any independent effort to identify any such rights. Information 687 on the procedures with respect to rights in RFC documents can be 688 found in BCP 78 and BCP 79. 689 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the use of 693 such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR repository at 695 http://www.ietf.org/ipr. 696 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights that may cover technology that may be required to implement 700 this standard. Please address the information to the IETF at ietf- 701 ipr@ietf.org. 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730S.Sakane, et al. [Page 13] 731 732