1 2 3 4 5 6 7INTERNET-DRAFT S. Sakane 8Intended Status: Informational Yokogawa Electric Corp. 9Expires: January 10, 2008 S. Zrelli 10 JAIST 11 M. Ishiyama 12 Toshiba Corp. 13 July 9, 2007 14 15 16 Problem statement on the cross-realm operation 17 of Kerberos in a specific system 18 draft-sakane-krb-cross-problem-statement-03.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/1id-abstracts.html 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 January 10, 2008. 47 48 49Copyright Notice 50 51 Copyright (C) The IETF Trust (2007). 52 53 54 55 56 57 58S.Sakane, et al. [Page 1] 59 60Internet-Draft July 2007 61 62 63Abstract 64 65 There are some issues when the cross-realm operation of the Kerberos 66 Version 5 [RFC4120] is employed into actual specific systems. This 67 document describes some examples of actual systems, and lists 68 requirements and restriction of the operation in such system. Then 69 it describes issues when we apply the cross-realm operation to such 70 system. 71 72 73 74Conventions used in this document 75 76 It is assumed that the readers are familiar with the terms and 77 concepts described in the Kerberos Version 5 [RFC4120]. 78 79 80 81 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 July 2007 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. Example of actual environment ................................ 6 126 4. Requirements ................................................. 7 127 5. Issues ....................................................... 8 128 5.1. Unreliability of authentication chain ................... 8 129 5.2. No PFS in case of the indirect trust model .............. 8 130 5.3. Scalability of the direct trust model ................... 9 131 5.4. Exposure to DoS Attacks ................................. 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 July 2007 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 actual systems, 184 where Kerberos could be applied. Large system or distributed system 185 are typically split into several managed domain. The reason is, for 186 example, geographical reason or different management policy. Even in 187 such system, an authentication mechanism over the different managed 188 domains is required. When the cross-realm operation of Kerberos is 189 applied to such systems, some issues come out. 190 191 This document briefly describes the Kerberos Version 5 system and the 192 cross-realm operation. Then, it describes two actual systems that 193 could be applied the Kerberos system, and describes seven 194 requirements of those systems in term both of management and 195 operation. Finally, it lists six issues of the cross-realm operation 196 when it is applied to those system. 197 198 Note that this document might not describe whole of issues of the 199 cross-realm operation. It also does not propose any solution to 200 solve issues which described in this document. In further step, we 201 have to analyze the issues, define problems and explore the 202 solutions. This work will be in another document. 203 204 This document is assumed that the readers are familiar with the terms 205 and concepts described in the Kerberos Version 5 [RFC4120]. 206 207 2082. Kerberos system 209 210 2112.1. Kerberos basic operation 212 213 Kerberos [RFC4120] is a widely deployed authentication system. The 214 authentication process in Kerberos involves principals and a Key 215 Distribution Center (KDC). The principals can be users or services. 216 Each KDC maintains a principals database and shares a secret key with 217 each registered principal. 218 219 The authentication process allows a user to acquire the needed 220 credentials from the KDC. These credentials allow services to 221 authenticate the users before granting them access to the resources. 222 An important part of the credentials are called Tickets. There are 223 224 225 226S.Sakane, et al. [Page 4] 227 228Internet-Draft July 2007 229 230 231 two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket. 232 The TGT is obtained periodically from the KDC and has a limited limit 233 after which it expires and the user must renew it. The TGT is used 234 to obtain the other kind of tickets, Service Tickets. The user 235 obtains a TGT from the Authentication Service (AS), a logical 236 component of the KDC. The process of obtaining a TGT is referred to 237 as 'AS exchange'. When a TGT request is issued by an user, the AS 238 responds by sending a reply packet containing the credentials which 239 consists of the TGT along with a random key called 'TGS Session Key'. 240 The TGT contains a set of information encrypted using a secret key 241 associated with a special service referred to as TGS (Ticket Granting 242 Service). The TGS session key is encrypted using the user's key so 243 that the user can obtain the TGS session key only if she knows the 244 secret key shared with the KDC. The TGT then is used to obtain 245 Service Tickets from the Ticket Granting Service (TGS)- the second 246 component of the KDC. The process of obtaining service tickets is 247 referred to as 'TGS exchange'. The request for a service ticket 248 consists on a packet containing a TGT and an 'Authenticator'. The 249 Authenticator is encrypted using the TGS session key and contains the 250 identity of the user as well as time stamps (for protection against 251 replay attacks). After decrypting the TGT (which was encrypted by 252 the AS using the TGS's secret key), the TGS extracts the TGS session 253 key. Using that session key, it decrypts the Authenticator and 254 authenticates the user. Then, the TGS issues credentials requested 255 by the user. These credentials consist on a service ticket and a 256 session key that will be used to authenticate the user with the 257 desired application service. 258 259 2602.2. Cross-realm operation 261 262 The Kerberos protocol provides the cross-realm authentication 263 capabilities. This allows users to obtain service tickets to access 264 services in foreign realms. In order to access such services, the 265 users first contact their home KDC asking for a TGT that will be used 266 with the TGS of the foreign realm. If the home realm and the foreign 267 realm share keys and have an established trust relationship, the home 268 KDC delivers the requested TGT. 269 270 However, if the home realm does not share inter-realm keys with the 271 foreign realm, the home KDC will provide a TGT that can be used with 272 an intermediary foreign realm that is likely to be sharing inter- 273 realm keys with the target realm. The client can use this 274 'intermediary TGT' to communicate with the intermediary KDC which 275 will iterate the actions taken by the home KDC. If the intermediary 276 KDC does not share inter-realm keys with the target foreign realm it 277 will point the user to another intermediary KDC (just as in the first 278 exchange between the user and its home KDC). However, in the other 279 280 281 282S.Sakane, et al. [Page 5] 283 284Internet-Draft July 2007 285 286 287 case (when it shares inter-realm keys with the target realm), the 288 intermediary KDC will issue a TGT that can be used with the KDC of 289 the target realm. After obtaining a TGT for the desired foreign 290 realm, the client uses it to obtain service tickets from the TGS of 291 the foreign realm. Finally, the user access the service using the 292 service ticket. 293 294 When the realms belong to the same institution, a chain of trust can 295 be determined by the client or the KDC by following the DNS domain 296 hierarchy and supposing that the parent domains share keys with all 297 its child sub-domains. However, because the inter-realm trust model 298 is not necessarily constructing the hierarchic approach anytime, the 299 trust path must be specified manually. When intermediary realms are 300 involved, the success of the cross-realm operation completely depends 301 on the realms that are part of the authentication path. 302 303 3043. Example of actual environment 305 306 In order to help understanding both requirements and restriction, 307 this section describes scale and operation of actual systems, where 308 it is possible to apply Kerberos. 309 310 We refer to actual petrochemical enterprise [SHELLCHEM], and show two 311 examples among its plants. The enterprise produces bulk 312 petrochemicals and their delivery to large industrial customers. 313 There are 43 typical plants of the enterprise all over the world. 314 They are managed by the operation sites placed in 35 countries. This 315 section shows two examples of them. 316 317 One is an example of a centralized system [CSPC]. CSPC is operated 318 by a joint enterprise of two companies. This system is one of the 319 largest systems of this enterprise in the world. This is placed in 320 the area of 3.4 square kilo meters in the north coast of Daya Bay, 321 Guangdong, which is at the southeast of China. 3,000 network 322 segments are established in the system. 16,000 control devices are 323 connected to the local area network. These devices belong to 324 different 9 sub systems, A control device has some control points, 325 which are controlled and monitored by other devices remotely. There 326 are 200,000 control points in all. They are controlled by 3 327 different control center. 328 329 Another example is a distributed system [NAM]. The NAM (Nederlandse 330 Aardolie Maatschappij) is operated by a partnership company of two 331 enterprises that represent the oil company. This system is 332 constituted by some plants that are geographically distributed within 333 the range of 863 square kilometers in the northern part of 334 Netherlands. 26 plants, each is named "cluster", are scattered in 335 336 337 338S.Sakane, et al. [Page 6] 339 340Internet-Draft July 2007 341 342 343 the area. They are connected each other by a private ATM WAN. Each 344 cluster has approximately 500-1,000 control devices. These devices 345 are managed by each local control center in each cluster. In the 346 entire system of the NAM, there are one million control points. 347 348 In the both of the systems, the end devices are basically connected 349 to a local network by a twisted pair cable, which is a low band-width 350 of 32 kbps. Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS- 351 M16C], are employed by many control devices. Furthermore, to 352 suppress power consumption, these CPU may be lowered the number of 353 clocks. Because there is a requirement of the explosion-proof. The 354 requirement restricts the amount of total energy in the device. 355 356 A device on the network collects data from other devices which are 357 monitoring condition of the system. The device uses the data to make 358 a decision how to control another devices. And then the device gives 359 more than one instruction that controls other devices. If it took 360 time for data to reach, they could not be associated. The travel 361 time of data from the device to the other device is demanded within 1 362 second at least. 363 364 A part of the operation, like control of these system, maintenance, 365 and the environmental monitoring, is consigned to an external 366 organization. Agents who are consigned walk around the plant to get 367 their information, or watch the plant from a remote site. 368 369 3704. Requirements 371 372 This section lists the requirements derived from the previous 373 section. R-1, R-2, R-3 and R-4 are related to the management of the 374 divided system. R-5, R-6 and R-7 are related to the restriction to 375 such industrial network. 376 377 378 R-1 It is necessary to partition a management domain into some 379 domains. Or it is necessary to delegate a management authority 380 to another independent management domain. 381 382 R-2 It is necessary to allow different independent management 383 domains to coexist on the same network because two or more 384 organizations need to enter into the system and to management 385 it. 386 387 R-3 It is necessary that a device controls other devices that belong 388 to a different domain. 389 390 391 392 393 394S.Sakane, et al. [Page 7] 395 396Internet-Draft July 2007 397 398 399 R-4 It is necessary to consider that a device is not always 400 geographically or network topologically close to the other 401 devices even when the devices belong to a same management 402 domain. 403 404 R-5 It is demanded to reduce the management cost as much as 405 possible. 406 407 R-6 It is necessary to consider the processing performance of the 408 device. And, it is necessary to suppress the power consumption 409 of the device. 410 411 R-7 It is necessary to consider bandwidth of the communication. 412 413 4145. Issues 415 416 This section lists the issues in the cross-realm operation when we 417 apply the Kerberos version 5 into the system described in the section 418 3, and consider the system applied the Kerberos with the requirements 419 described in the section 4. 420 421 4225.1. Unreliability of authentication chain 423 424 When the relationship of trust is constructed like a chain or 425 hierarchical, the authentication path is not dependable since it 426 strongly depends on intermediary realms that might not be under the 427 same authority. If any of the realms in the authentication path is 428 not available, then the principals of the end-realms can not perform 429 the cross-realm operation. 430 431 The end-point realms do not have full control and responsibility of 432 the success of the operations even if their respective KDCs are fully 433 functional. Dependability of a system decreases if the system relies 434 on uncontrolled components. We can not be sure at 100% about the 435 result of the authentication since we do not know how is it going in 436 intermediary realms. 437 438 This issue will happen as a by-product of a result meeting the 439 requirements R-1 and R-2. 440 441 4425.2. No PFS in case of the indirect trust model 443 444 In [SPECCROSS], any KDC in the authentication path can learn the 445 session key that will be used between the client and the desired 446 service. This means that any intermediary realm is able to spoof the 447 448 449 450S.Sakane, et al. [Page 8] 451 452Internet-Draft July 2007 453 454 455 identity either of the service or the client as well as to eavesdrop 456 on the communication between the client and the server. 457 458 This issue will happen as a by-product of a result meeting the 459 requirements R-1 and R-2. 460 461 4625.3. Scalability of the direct trust model 463 464 In the direct relationship of trust between each realm, the realms 465 involved in the cross-realm operation share keys and their respective 466 TGS principals are registered in each other's KDC. When direct trust 467 relationships are used, the KDC of each realm must maintain keys with 468 all foreign realms. This can become a cumbersome task when the 469 number of realms increase. This also increases maintenance cost. 470 471 This issue will happen as a by-product of a result meeting the 472 requirements R-1, R-2 and R-5. 473 474 4755.4. Exposure to DoS Attacks 476 477 One of the assumption made when allowing the cross-realm operation in 478 Kerberos is that users can communicate with KDCs located in remote 479 realms. This practice introduces security threats because KDCs are 480 open to the public network. Administrators may think of restricting 481 the access to the KDC to the trusted realms only. However, this 482 approach is not scalable and does not really protect the KDC. 483 Indeed, when the remote realms have several IP prefixes (e.g. control 484 centers or outsourcing companies, located world wide), then the 485 administrator of the local KDC must collect the list of prefixes that 486 belong to these organization. The filtering rules must then 487 explicitly allow the incoming traffic from any host that belongs to 488 one of these prefixes. This makes the administrator's tasks more 489 complicated and prone to human errors. And also, the maintenance 490 cost increases. On the other hand, when ranges of external IP 491 addresses are allowed to communicate with the KDC, the risk of 492 becoming target to attacks from remote malicious users increases. 493 494 4955.5. Client's performance 496 497 In the cross-realm operation, Kerberos clients have to perform TGS 498 exchanges with all the KDCs in the trust path, including the home KDC 499 and the target KDC. TGS exchange requires cryptographic operations. 500 This exchange demands important processing time especially when the 501 client has limited computational capabilities. The overhead of these 502 cross-realm exchanges grows into unacceptable delays. 503 504 505 506S.Sakane, et al. [Page 9] 507 508Internet-Draft July 2007 509 510 511 We ported the MIT Kerberos library (version 1.2.4), implemented a 512 Kerberos client on our original board with H8 (16-bit, 20MHz), and 513 measured the process time of each Kerberos message [KRBIMPL]. It 514 takes 195 milliseconds to perform a TGS exchange with the on-board 515 H/W crypto engine. Indeed, this result seems reasonable to the 516 requirement of the response time for the control network. However, 517 we did not modify the clock speed of the H8 during our measurement. 518 The processing time must be slower in a actual environment because H8 519 is used with lowered clock speed in such system. Also, the delays 520 can grow to unacceptable delays when the number of intermediary 521 realms increases. 522 523 This issue will happen as a by-product of a result meeting the 524 requirements R-1, R-2, R-6 and R-7. 525 526 5275.6. Pre-authentication problem in roaming scenarios 528 529 In roaming scenarios, the client needs to contact her home KDC to 530 obtain a cross-realm TGT for the local (or visited) realm. However, 531 the policy of the network access providers or the gateway in the 532 local network usually does not allow clients to communicate with 533 hosts in the Internet unless they provide valid authentication 534 credentials. In this manner, the client encounters a chicken-and-egg 535 problem where two resources are interdependent; the Internet 536 connection is needed to contact the home KDC and for obtaining 537 credentials, and on the other hand, the Internet connection is only 538 granted for clients who have valid credentials. As a result, the 539 Kerberos protocol can not be used as it is for authenticating roaming 540 clients requesting network access. 541 542 This issue will happen as a result meeting the requirements R-3 and 543 R-4. 544 545 5466. Implementation consideration 547 548 This document just describes issues of the cross-realm operation. 549 However, there are important matters to be considered, when we solve 550 these issues and implement solution. Solution must not introduce new 551 problem. Solution should use existing components or protocols as 552 much as possible, should not introduce any definition of new 553 component. Solution must not require a KDC to have any additional 554 process. You must not forget that there would be a trade-off matter 555 anytime. So an implementation may not solve all of the problems 556 stated in this document. 557 558 559 560 561 562S.Sakane, et al. [Page 10] 563 564Internet-Draft July 2007 565 566 5677. IANA Considerations 568 569 This document makes no request of IANA. 570 571 5728. Security Considerations 573 574 This document just clarifies some issues of the cross-realm operation 575 of the Kerberos V system. There is especially not describing 576 security. Some troubles might be caused to your system by malicious 577 user who misuses the description of this document if it dares to say. 578 579 5809. Acknowledgments 581 582 The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa, 583 Ken'ichi Kamada and Atsushi Inoue. They gave us lots of comments and 584 input for this document. 585 586 58710. References 588 589 59010.1. Normative References 591 592 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 593 Kerberos Network Authentication Service (V5)", RFC 594 4120, July 2005. 595 596 59710.2. Informative References 598 599 [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id= 600 531,00.html 601 602 [KRBIMPL] "A Prototype of a Secure Autonomous Bootstrap Mechanism 603 for Control Networks", Nobuo Okabe, Shoichi Sakane, 604 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki, 605 SAINT, pp. 56-62, IEEE Computer Society, 2006. 606 607 [NAM] http://www.nam.nl/ 608 609 [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing. 610 jsp&fp=/products/mpumcu/h8_family/ 611 612 [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi 613 ng.jsp&fp=/products/mpumcu/m16c_family/ 614 615 616 617 618S.Sakane, et al. [Page 11] 619 620Internet-Draft July 2007 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 IETF Trust (2007). 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, THE IETF TRUST AND 664 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 665 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 666 THE 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 July 2007 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