1 2 3 4 5 6 7INTERNET-DRAFT S. Sakane 8Intended Status: Informational Ken'ichi Kamada 9Expires: January 31, 2010 Yokogawa Electric Corp. 10 S. Zrelli 11 JAIST 12 M. Ishiyama 13 Toshiba Corp. 14 July 30, 2009 15 16 17 Problem statement on the cross-realm operation of Kerberos 18 draft-ietf-krb-wg-cross-problem-statement-04.txt 19 20 21 22 23 Status of this Memo 24 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 27 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 32 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 37 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 40 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 43 44 This Internet-Draft expires in January 31, 2010. 45 46 47Copyright Notice 48 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 51 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 56 57 58S.Sakane, et al. [Page 1] 59 60Internet-Draft July 2009 61 62 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. 65 66 67Abstract 68 69 As industrial automation is moving towards wider adoption of Internet 70 standards, the Kerberos authentication protocol represents one of the 71 best alternatives for ensuring the confidentiality and the integrity 72 of communications in control networks while meeting performance and 73 security requirements. 74 75 However, the use of Kerberos cross-realm operations in large scale 76 industrial systems may introduce issues that could cause performance 77 and reliability problems. This document describes some examples of 78 actual large scale industrial systems, and lists requirements and 79 restriction regarding authentication operations in such environments. 80 The document then describes standing issues in the Kerberos cross- 81 realm authentication model that should be fixed before Kerberos can 82 be adopted in large scale industrial systems. 83 84 85 86Conventions used in this document 87 88 It is assumed that the readers are familiar with the terms and 89 concepts described in the Kerberos Version 5 [RFC4120]. 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 2009 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. Applying Cross-Realm Kerberos in Complex Environments ........ 6 126 4. Requirements ................................................. 7 127 5. Issues ....................................................... 8 128 5.1. Unreliability of authentication chain ................... 8 129 5.2. Possibility of MITM in case of the indirect trust model . 9 130 5.3. Scalability of the direct trust model ................... 9 131 5.4. Exposure to DoS Attacks ................................. 9 132 5.5. Client's performance .................................... 10 133 5.6. Pre-authentication problem in roaming scenarios ......... 10 134 6. Implementation consideration ................................. 11 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 ................................. 12 141 Authors' Addresses ............................................... 12 142 143 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 2009 173 174 1751. Introduction 176 177 Kerberos Version 5 is a widely deployed mechanism that enables a 178 server to authenticate a client's access. Each client belongs to a 179 managed domain called realm. Kerberos supports authentication when a 180 client and a server belong to different realms. This is called 181 cross-realm operation. 182 183 Meanwhile, there are lots of manners of operation in actual systems, 184 where Kerberos could be applied. Large systems or distributed 185 systems are typically split into several managed domains. For 186 example, systems could be split into multiple domains for 187 geographical reasons, or to implement different management policies. 188 Even in such systems, a common authentication mechanism for the 189 different managed domains is required. When the cross-realm 190 operation of Kerberos is applied to such systems, some issues come 191 out. 192 193 This document briefly describes the Kerberos Version 5 system and its 194 cross-realm mode of operation. Then, it describes two actual systems 195 that Kerberos could be applied to. and describes seven requirements 196 of those systems in term both of management and operation. Finally, 197 it lists six issues of the cross-realm operation when it is applied 198 to those system. 199 200 Note that this document might not describe all of the issues of 201 cross-realm operation. New issues might be found in the future. It 202 also does not propose any solution to solve the issues. Furthermore, 203 publication of this document does not mean that each of the issues 204 have to be solved by the IETF members. Hence, in further step, we 205 will analyze the issues, define problems and explore the solutions. 206 These works will be described in another document. 207 208 This document is assumed that the readers are familiar with the terms 209 and concepts described in the Kerberos Version 5 [RFC4120]. 210 211 2122. Kerberos system 213 214 2152.1. Kerberos basic operation 216 217 Kerberos [RFC4120] is a widely deployed authentication system. The 218 authentication process in Kerberos involves principals and a Key 219 Distribution Center (KDC). The principals can be users or services. 220 Each KDC maintains a database of principals and shares a secret key 221 with each registered principal. 222 223 224 225 226S.Sakane, et al. [Page 4] 227 228Internet-Draft July 2009 229 230 231 The authentication process allows a user to acquire the needed 232 credentials from the KDC. These credentials allow services to 233 authenticate the users before granting them access to the resources. 234 An important part of the credentials are called Tickets. There are 235 two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket. 236 The TGT is obtained periodically from the KDC and has a limited limit 237 after which it expires and the user must renew it. The TGT is used 238 to obtain the other kind of tickets, Service Tickets. The user 239 obtains a TGT from the Authentication Service (AS), a logical 240 component of the KDC. The process of obtaining a TGT is referred to 241 as 'AS exchange'. When a TGT request is issued by an user, the AS 242 responds by sending a reply packet containing the credentials which 243 consists of the TGT along with a random key called 'TGS Session Key'. 244 The TGT contains a set of information encrypted using a secret key 245 associated with a special service referred to as TGS (Ticket Granting 246 Service). The TGS session key is encrypted using the user's key so 247 that the user can obtain the TGS session key only if she knows the 248 secret key shared with the KDC. The TGT then is used to obtain 249 Service Tickets from the Ticket Granting Service (TGS)- the second 250 component of the KDC. The process of obtaining service tickets is 251 referred to as 'TGS exchange'. The request for a service ticket 252 consists on a packet containing a TGT and an 'Authenticator'. The 253 Authenticator is encrypted using the TGS session key and contains the 254 identity of the user as well as time stamps (for protection against 255 replay attacks). After decrypting the TGT (which was encrypted by 256 the AS using the TGS's secret key), the TGS extracts the TGS session 257 key. Using that session key, it decrypts the Authenticator and 258 authenticates the user. Then, the TGS issues credentials requested 259 by the user. These credentials consist on a service ticket and a 260 session key that will be used to authenticate the user with the 261 desired application service. 262 263 2642.2. Cross-realm operation 265 266 The Kerberos protocol provides cross-realm authentication 267 capabilities. This allows users to obtain service tickets to access 268 services in foreign realms. In order to access such services, the 269 users first contact their home KDC asking for a TGT that will be used 270 with the TGS of the foreign realm. If there is a direct trust 271 relationship between the home realm and the foreign realm, namely 272 both realms share keys (this is called inter-realm keys), the home 273 KDC delivers the requested TGT. 274 275 However, if the home realm does not share inter-realm keys with the 276 foreign realm the home KDC will provide a TGT that can be used with 277 an intermediary foreign realm that is likely to be sharing inter- 278 realm keys with the target realm. The client can use this 279 280 281 282S.Sakane, et al. [Page 5] 283 284Internet-Draft July 2009 285 286 287 'intermediary TGT' to communicate with the intermediary KDC which 288 will iterate the actions taken by the home KDC. If the intermediary 289 KDC does not share inter-realm keys with the target foreign realm it 290 will point the user to another intermediary KDC (just as in the first 291 exchange between the user and its home KDC). However, in the other 292 case (when it shares inter-realm keys with the target realm), the 293 intermediary KDC will issue a TGT that can be used with the KDC of 294 the target realm. This is so-called indirect trust model. After 295 obtaining a TGT for the desired foreign realm, the client uses it to 296 obtain service tickets from the TGS of the foreign realm. Finally, 297 the user access the service using the service ticket. 298 299 When the realms belong to the same institution, a chain of trust can 300 be determined by the client or the KDC by following the DNS domain 301 hierarchy and supposing that the parent domains share keys with all 302 its child sub-domains. However, because the inter-realm trust model 303 is not necessarily constructing the hierarchic approach anytime, the 304 trust path must be specified manually. When intermediary realms are 305 involved, the success of the cross-realm operation completely depends 306 on the realms that are part of the authentication path. 307 308 3093. Applying Cross-Realm Kerberos in Complex Environments 310 311 In order to help understanding both requirements and restriction, 312 this section describes scale and operation of two actual systems that 313 could be supported by cross-realm Kerberos. The two systems would be 314 most naturally implemented using different models, which will imply 315 different requirements for cross-realm Kerberos. 316 317 We refer to actual petrochemical enterprise [SHELLCHEM], and show two 318 examples among its plants. The enterprise produces bulk 319 petrochemicals and their delivery to large industrial customers. 320 There are 43 typical plants of the enterprise all over the world. 321 They are managed by the operation sites placed in 35 countries. This 322 section shows two examples of them. 323 324 One is an example of a centralized system [CSPC]. CSPC is operated 325 by a joint enterprise of two companies. This system is one of the 326 largest systems of this enterprise in the world. This is placed in 327 the area of 3.4 square kilo meters in the north coast of Daya Bay, 328 Guangdong, which is at the southeast of China. 3,000 network 329 segments are established in the system. 16,000 control devices are 330 connected to the local area network. These devices belong to 331 different 9 sub systems, A control device has some control points, 332 which are controlled and monitored by other devices remotely. There 333 are 200,000 control points in all. They are controlled by 3 334 different control center. 335 336 337 338S.Sakane, et al. [Page 6] 339 340Internet-Draft July 2009 341 342 343 Another example is a distributed system [NAM]. The NAM (Nederlandse 344 Aardolie Maatschappij) is operated by a partnership company of two 345 enterprises that represent the oil company. This system is 346 constituted by some plants that are geographically distributed within 347 the range of 863 square kilometers in the northern part of 348 Netherlands. 26 plants, each is named "cluster", are scattered in 349 the area. They are connected each other by a private ATM WAN. Each 350 cluster has approximately 500-1,000 control devices. These devices 351 are managed by each local control center in each cluster. In the 352 entire system of the NAM, there are one million control points. 353 354 In the both of the systems, the end devices are basically connected 355 to a local network by a twisted pair cable, which is a low band-width 356 of 32 kbps. Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS- 357 M16C], are employed by many control devices. Furthermore, to 358 suppress power consumption, these CPU may be lowered the number of 359 clocks. Because there is a requirement of the explosion-proof. The 360 requirement restricts the amount of total energy in the device. 361 362 A device on the network collects data from other devices which are 363 monitoring condition of the system. The device uses the data to make 364 a decision how to control another devices. And then the device gives 365 more than one instruction that controls other devices. If it took 366 time for data to reach, they could not be associated. The travel 367 time of data from the device to the other device is demanded within 1 368 second at least. 369 370 A part of the operation, like control of these system, maintenance, 371 and the environmental monitoring, is consigned to an external 372 organization. Agents who are consigned walk around the plant to get 373 their information, or watch the plant from a remote site. 374 375 3764. Requirements 377 378 This section lists the requirements derived from the previous 379 section. R-1, R-2, R-3 and R-4 are related to the management of the 380 divided system. R-5, R-6 and R-7 are related to the restriction to 381 such industrial network. 382 383 384 R-1 It is necessary to partition a management domain into some 385 domains. Or it is necessary to delegate a management authority 386 to another independent management domain. 387 388 R-2 It is necessary to allow different independent management 389 domains to coexist on the same network because two or more 390 organizations need to enter into the system and to management 391 392 393 394S.Sakane, et al. [Page 7] 395 396Internet-Draft July 2009 397 398 399 it. 400 401 R-3 It is necessary that a device controls other devices that belong 402 to a different domain. 403 404 R-4 It is necessary to consider that a device is not always 405 geographically or network topologically close to the other 406 devices even when the devices belong to a same management 407 domain. 408 409 R-5 It is demanded to reduce the management cost as much as 410 possible. 411 412 R-6 It is necessary to consider the processing performance of the 413 device. And, it is necessary to suppress the power consumption 414 of the device. 415 416 R-7 It is necessary to consider bandwidth of the communication. 417 418 4195. Issues 420 421 This section lists the issues in the cross-realm operation when we 422 apply the Kerberos version 5 into the system described in the section 423 3, and consider the system applied the Kerberos with the requirements 424 described in the section 4. 425 426 4275.1. Unreliability of authentication chain 428 429 When the relationship of trust is constructed like a chain or 430 hierarchical, the authentication path is not dependable since it 431 strongly depends on intermediary realms that might not be under the 432 same authority. If any of the realms in the authentication path is 433 not available, then the principals of the end-realms can not perform 434 the cross-realm operation. 435 436 The end-point realms do not have full control and responsibility of 437 the success of the operations even if their respective KDCs are fully 438 functional. Dependability of a system decreases if the system relies 439 on uncontrolled components. We can not be sure at 100% about the 440 result of the authentication since we do not know how is it going in 441 intermediary realms. 442 443 This issue will happen as a by-product of a result meeting the 444 requirements R-1 and R-2. 445 446 447 448 449 450S.Sakane, et al. [Page 8] 451 452Internet-Draft July 2009 453 454 4555.2. Possibility of MITM in case of the indirect trust model 456 457 Every KDC in the authentication path knows the shared secret between 458 the client and the remaining KDCs in the authentication path. This 459 allows a malicious KDC to perform MITM attacks on communications 460 between the client and any KDC in the remaining authentication chain. 461 A malicious KDC also may learn the service session key that is used 462 to protect the communication between the client and the actual 463 application service, and performs a MITM attack between them. 464 465 In [SPECCROSS], the authors have analyzed the cross-realm operations 466 in Kerberos and provided formal proof of the issue discussed in this 467 section. 468 469 This issue will happen as a by-product of a result meeting the 470 requirements R-1 and R-2. 471 472 4735.3. Scalability of the direct trust model 474 475 In the direct relationship of trust between each realm, the realms 476 involved in the cross-realm operation share keys and their respective 477 TGS principals are registered in each other's KDC. When direct trust 478 relationships are used, the KDC of each realm must maintain keys with 479 all foreign realms. This can become a cumbersome task when the 480 number of realms increase. This also increases maintenance cost. 481 482 This issue will happen as a by-product of a result meeting the 483 requirements R-1, R-2 and R-5. 484 485 4865.4. Exposure to DoS Attacks 487 488 One of the assumption made when allowing the cross-realm operation in 489 Kerberos is that users can communicate with KDCs located in remote 490 realms. This practice introduces security threats because KDCs are 491 open to the public network. Administrators may think of restricting 492 the access to the KDC to the trusted realms only. However, this 493 approach is not scalable and does not really protect the KDC. 494 Indeed, when the remote realms have several IP prefixes (e.g. control 495 centers or outsourcing companies, located world wide), then the 496 administrator of the local KDC must collect the list of prefixes that 497 belong to these organization. The filtering rules must then 498 explicitly allow the incoming traffic from any host that belongs to 499 one of these prefixes. This makes the administrator's tasks more 500 complicated and prone to human errors. And also, the maintenance 501 cost increases. On the other hand, when ranges of external IP 502 addresses are allowed to communicate with the KDC, the risk of 503 504 505 506S.Sakane, et al. [Page 9] 507 508Internet-Draft July 2009 509 510 511 becoming target to attacks from remote malicious users increases. 512 513 This issue will happen as a by-product of a result meeting the 514 requirements R-3, R-4 and R-5. 515 516 5175.5. Client's performance 518 519 In the cross-realm operation, Kerberos clients have to perform TGS 520 exchanges with all the KDCs in the trust path, including the home KDC 521 and the target KDC. TGS exchange requires cryptographic operations. 522 This exchange demands important processing time especially when the 523 client has limited computational capabilities. The overhead of these 524 cross-realm exchanges grows into unacceptable delays. 525 526 We ported the MIT Kerberos library (version 1.2.4), implemented a 527 Kerberos client on our original board with H8 (16-bit, 20MHz), and 528 measured the process time of each Kerberos message [KRBIMPL]. It 529 takes 195 milliseconds to perform a TGS exchange with the on-board 530 H/W crypto engine. Indeed, this result seems reasonable to the 531 requirement of the response time for the control network. However, 532 we did not modify the clock speed of the H8 during our measurement. 533 The processing time must be slower in a actual environment because H8 534 is used with lowered clock speed in such system. Also, the delays 535 can grow to unacceptable delays when the number of intermediary 536 realms increases. 537 538 This issue will happen as a by-product of a result meeting the 539 requirements R-1, R-2, R-6 and R-7. 540 541 5425.6. Pre-authentication problem in roaming scenarios 543 544 In roaming scenarios, the client needs to contact her home KDC to 545 obtain a cross-realm TGT for the local (or visited) realm. However, 546 the policy of the network access providers or the gateway in the 547 local network usually does not allow clients to communicate with 548 hosts in the Internet unless they provide valid authentication 549 credentials. In this manner, the client encounters a chicken-and-egg 550 problem where two resources are interdependent; the Internet 551 connection is needed to contact the home KDC and for obtaining 552 credentials, and on the other hand, the Internet connection is only 553 granted for clients who have valid credentials. As a result, the 554 Kerberos protocol can not be used as it is for authenticating roaming 555 clients requesting network access. 556 557 This issue will happen as a result meeting the requirements R-3 and 558 R-4. 559 560 561 562S.Sakane, et al. [Page 10] 563 564Internet-Draft July 2009 565 566 5676. Implementation consideration 568 569 This document just describes issues of the cross-realm operation. 570 However, there are important matters to be considered, when we solve 571 these issues and implement solution. Solution must not introduce new 572 problem. It should use existing components or protocols as much as 573 possible, and it should not introduce any definition of new 574 component. It should not require new changes to existing deployed 575 clients, and it should not influence the client code-base as much as 576 possible. Because a KDC is a significant server of the Kerberos 577 system. New burden should not be introduced into a KDC as much as 578 possible. You must not forget that there would be a trade-off matter 579 anytime. So an implementation may not solve all of the problems 580 stated in this document. 581 582 5837. IANA Considerations 584 585 This document makes no request of IANA. 586 587 5888. Security Considerations 589 590 This document clarifies the issues of the cross-realm operation of 591 the Kerberos V system, which include security issues to be 592 considered. See Section 5.1, 5.2, 5.3 and 5.4 for further details. 593 594 5959. Acknowledgments 596 597 The authors are grateful to Nobuo Okabe, Kazunori Miyazawa, and 598 Atsushi Inoue. They gave us lots of comments and suggestions to this 599 document from the early stage. Nicolas Williams, Chaskiel Grundman 600 and Love Hornquist Astrand gave valuable suggestions and corrections. 601 Finally, the authors thank to Jeffrey Hutzelman. He gave us a lot of 602 suggestions for completion of this document. 603 604 60510. References 606 607 60810.1. Normative References 609 610 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 611 Kerberos Network Authentication Service (V5)", RFC 612 4120, July 2005. 613 614 615 616 617 618S.Sakane, et al. [Page 11] 619 620Internet-Draft July 2009 621 622 62310.2. Informative References 624 625 [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id= 626 531,00.html 627 628 [KRBIMPL] "A Prototype of a Secure Autonomous Bootstrap Mechanism 629 for Control Networks", Nobuo Okabe, Shoichi Sakane, 630 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki, 631 SAINT, pp. 56-62, IEEE Computer Society, 2006. 632 633 [NAM] http://www.nam.nl/ 634 635 [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing. 636 jsp&fp=/products/mpumcu/h8_family/ 637 638 [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi 639 ng.jsp&fp=/products/mpumcu/m16c_family/ 640 641 [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html 642 643 [SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C. 644 Walstad, "Specifying Kerberos 5 Cross-Realm 645 Authentication", Fifth Workshop on Issues in the Theory 646 of Security, Jan 2005. 647 648Authors' Addresses 649 650 Shoichi Sakane 651 Ken'ichi Kamada 652 Yokogawa Electric Corporation 653 2-9-32 Nakacho, Musashino-shi, 654 Tokyo 180-8750 Japan 655 E-mail: Shouichi.Sakane@jp.yokogawa.com, 656 Ken-ichi.Kamada@jp.yokogawa.com 657 658 659 Saber Zrelli 660 Japan Advanced Institute of Science and Technology 661 1-1 Asahidai, Nomi, 662 Ishikawa 923-1292 Japan 663 E-mail: zrelli@jaist.ac.jp 664 665 666 667 668 669 670 671 672 673 674S.Sakane, et al. [Page 12] 675 676Internet-Draft July 2009 677 678 679 Masahiro Ishiyama 680 Toshiba Corporation 681 1, komukai-toshiba-cho, Saiwai-ku, 682 Kawasaki 212-8582 Japan 683 E-mail: masahiro@isl.rdc.toshiba.co.jp 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 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