idnits 2.17.1 draft-ietf-krb-wg-cross-problem-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2009) is 5382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Sakane 3 Intended Status: Informational Ken'ichi Kamada 4 Expires: January 31, 2010 Yokogawa Electric Corp. 5 S. Zrelli 6 JAIST 7 M. Ishiyama 8 Toshiba Corp. 9 July 30, 2009 11 Problem statement on the cross-realm operation of Kerberos 12 draft-ietf-krb-wg-cross-problem-statement-04.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft expires in January 31, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 As industrial automation is moving towards wider adoption of Internet 51 standards, the Kerberos authentication protocol represents one of the 52 best alternatives for ensuring the confidentiality and the integrity 53 of communications in control networks while meeting performance and 54 security requirements. 56 However, the use of Kerberos cross-realm operations in large scale 57 industrial systems may introduce issues that could cause performance 58 and reliability problems. This document describes some examples of 59 actual large scale industrial systems, and lists requirements and 60 restriction regarding authentication operations in such environments. 61 The document then describes standing issues in the Kerberos cross- 62 realm authentication model that should be fixed before Kerberos can 63 be adopted in large scale industrial systems. 65 Conventions used in this document 67 It is assumed that the readers are familiar with the terms and 68 concepts described in the Kerberos Version 5 [RFC4120]. 70 Table of Contents 72 1. Introduction ................................................. 4 73 2. Kerberos system .............................................. 4 74 2.1. Kerberos basic operation ................................ 4 75 2.2. Cross-realm operation ................................... 5 76 3. Applying Cross-Realm Kerberos in Complex Environments ........ 6 77 4. Requirements ................................................. 7 78 5. Issues ....................................................... 8 79 5.1. Unreliability of authentication chain ................... 8 80 5.2. Possibility of MITM in case of the indirect trust model . 9 81 5.3. Scalability of the direct trust model ................... 9 82 5.4. Exposure to DoS Attacks ................................. 9 83 5.5. Client's performance .................................... 10 84 5.6. Pre-authentication problem in roaming scenarios ......... 10 85 6. Implementation consideration ................................. 11 86 7. IANA Considerations .......................................... 11 87 8. Security Considerations ...................................... 11 88 9. Acknowledgments .............................................. 11 89 10. References ................................................... 11 90 10.1. Normative References ................................... 11 91 10.2. Informative References ................................. 12 92 Authors' Addresses ............................................... 12 94 1. Introduction 96 Kerberos Version 5 is a widely deployed mechanism that enables a 97 server to authenticate a client's access. Each client belongs to a 98 managed domain called realm. Kerberos supports authentication when a 99 client and a server belong to different realms. This is called 100 cross-realm operation. 102 Meanwhile, there are lots of manners of operation in actual systems, 103 where Kerberos could be applied. Large systems or distributed 104 systems are typically split into several managed domains. For 105 example, systems could be split into multiple domains for 106 geographical reasons, or to implement different management policies. 107 Even in such systems, a common authentication mechanism for the 108 different managed domains is required. When the cross-realm 109 operation of Kerberos is applied to such systems, some issues come 110 out. 112 This document briefly describes the Kerberos Version 5 system and its 113 cross-realm mode of operation. Then, it describes two actual systems 114 that Kerberos could be applied to. and describes seven requirements 115 of those systems in term both of management and operation. Finally, 116 it lists six issues of the cross-realm operation when it is applied 117 to those system. 119 Note that this document might not describe all of the issues of 120 cross-realm operation. New issues might be found in the future. It 121 also does not propose any solution to solve the issues. Furthermore, 122 publication of this document does not mean that each of the issues 123 have to be solved by the IETF members. Hence, in further step, we 124 will analyze the issues, define problems and explore the solutions. 125 These works will be described in another document. 127 This document is assumed that the readers are familiar with the terms 128 and concepts described in the Kerberos Version 5 [RFC4120]. 130 2. Kerberos system 132 2.1. Kerberos basic operation 134 Kerberos [RFC4120] is a widely deployed authentication system. The 135 authentication process in Kerberos involves principals and a Key 136 Distribution Center (KDC). The principals can be users or services. 137 Each KDC maintains a database of principals and shares a secret key 138 with each registered principal. 140 The authentication process allows a user to acquire the needed 141 credentials from the KDC. These credentials allow services to 142 authenticate the users before granting them access to the resources. 143 An important part of the credentials are called Tickets. There are 144 two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket. 145 The TGT is obtained periodically from the KDC and has a limited limit 146 after which it expires and the user must renew it. The TGT is used 147 to obtain the other kind of tickets, Service Tickets. The user 148 obtains a TGT from the Authentication Service (AS), a logical 149 component of the KDC. The process of obtaining a TGT is referred to 150 as 'AS exchange'. When a TGT request is issued by an user, the AS 151 responds by sending a reply packet containing the credentials which 152 consists of the TGT along with a random key called 'TGS Session Key'. 153 The TGT contains a set of information encrypted using a secret key 154 associated with a special service referred to as TGS (Ticket Granting 155 Service). The TGS session key is encrypted using the user's key so 156 that the user can obtain the TGS session key only if she knows the 157 secret key shared with the KDC. The TGT then is used to obtain 158 Service Tickets from the Ticket Granting Service (TGS)- the second 159 component of the KDC. The process of obtaining service tickets is 160 referred to as 'TGS exchange'. The request for a service ticket 161 consists on a packet containing a TGT and an 'Authenticator'. The 162 Authenticator is encrypted using the TGS session key and contains the 163 identity of the user as well as time stamps (for protection against 164 replay attacks). After decrypting the TGT (which was encrypted by 165 the AS using the TGS's secret key), the TGS extracts the TGS session 166 key. Using that session key, it decrypts the Authenticator and 167 authenticates the user. Then, the TGS issues credentials requested 168 by the user. These credentials consist on a service ticket and a 169 session key that will be used to authenticate the user with the 170 desired application service. 172 2.2. Cross-realm operation 174 The Kerberos protocol provides cross-realm authentication 175 capabilities. This allows users to obtain service tickets to access 176 services in foreign realms. In order to access such services, the 177 users first contact their home KDC asking for a TGT that will be used 178 with the TGS of the foreign realm. If there is a direct trust 179 relationship between the home realm and the foreign realm, namely 180 both realms share keys (this is called inter-realm keys), the home 181 KDC delivers the requested TGT. 183 However, if the home realm does not share inter-realm keys with the 184 foreign realm the home KDC will provide a TGT that can be used with 185 an intermediary foreign realm that is likely to be sharing inter- 186 realm keys with the target realm. The client can use this 187 'intermediary TGT' to communicate with the intermediary KDC which 188 will iterate the actions taken by the home KDC. If the intermediary 189 KDC does not share inter-realm keys with the target foreign realm it 190 will point the user to another intermediary KDC (just as in the first 191 exchange between the user and its home KDC). However, in the other 192 case (when it shares inter-realm keys with the target realm), the 193 intermediary KDC will issue a TGT that can be used with the KDC of 194 the target realm. This is so-called indirect trust model. After 195 obtaining a TGT for the desired foreign realm, the client uses it to 196 obtain service tickets from the TGS of the foreign realm. Finally, 197 the user access the service using the service ticket. 199 When the realms belong to the same institution, a chain of trust can 200 be determined by the client or the KDC by following the DNS domain 201 hierarchy and supposing that the parent domains share keys with all 202 its child sub-domains. However, because the inter-realm trust model 203 is not necessarily constructing the hierarchic approach anytime, the 204 trust path must be specified manually. When intermediary realms are 205 involved, the success of the cross-realm operation completely depends 206 on the realms that are part of the authentication path. 208 3. Applying Cross-Realm Kerberos in Complex Environments 210 In order to help understanding both requirements and restriction, 211 this section describes scale and operation of two actual systems that 212 could be supported by cross-realm Kerberos. The two systems would be 213 most naturally implemented using different models, which will imply 214 different requirements for cross-realm Kerberos. 216 We refer to actual petrochemical enterprise [SHELLCHEM], and show two 217 examples among its plants. The enterprise produces bulk 218 petrochemicals and their delivery to large industrial customers. 219 There are 43 typical plants of the enterprise all over the world. 220 They are managed by the operation sites placed in 35 countries. This 221 section shows two examples of them. 223 One is an example of a centralized system [CSPC]. CSPC is operated 224 by a joint enterprise of two companies. This system is one of the 225 largest systems of this enterprise in the world. This is placed in 226 the area of 3.4 square kilo meters in the north coast of Daya Bay, 227 Guangdong, which is at the southeast of China. 3,000 network 228 segments are established in the system. 16,000 control devices are 229 connected to the local area network. These devices belong to 230 different 9 sub systems, A control device has some control points, 231 which are controlled and monitored by other devices remotely. There 232 are 200,000 control points in all. They are controlled by 3 233 different control center. 235 Another example is a distributed system [NAM]. The NAM (Nederlandse 236 Aardolie Maatschappij) is operated by a partnership company of two 237 enterprises that represent the oil company. This system is 238 constituted by some plants that are geographically distributed within 239 the range of 863 square kilometers in the northern part of 240 Netherlands. 26 plants, each is named "cluster", are scattered in 241 the area. They are connected each other by a private ATM WAN. Each 242 cluster has approximately 500-1,000 control devices. These devices 243 are managed by each local control center in each cluster. In the 244 entire system of the NAM, there are one million control points. 246 In the both of the systems, the end devices are basically connected 247 to a local network by a twisted pair cable, which is a low band-width 248 of 32 kbps. Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS- 249 M16C], are employed by many control devices. Furthermore, to 250 suppress power consumption, these CPU may be lowered the number of 251 clocks. Because there is a requirement of the explosion-proof. The 252 requirement restricts the amount of total energy in the device. 254 A device on the network collects data from other devices which are 255 monitoring condition of the system. The device uses the data to make 256 a decision how to control another devices. And then the device gives 257 more than one instruction that controls other devices. If it took 258 time for data to reach, they could not be associated. The travel 259 time of data from the device to the other device is demanded within 1 260 second at least. 262 A part of the operation, like control of these system, maintenance, 263 and the environmental monitoring, is consigned to an external 264 organization. Agents who are consigned walk around the plant to get 265 their information, or watch the plant from a remote site. 267 4. Requirements 269 This section lists the requirements derived from the previous 270 section. R-1, R-2, R-3 and R-4 are related to the management of the 271 divided system. R-5, R-6 and R-7 are related to the restriction to 272 such industrial network. 274 R-1 It is necessary to partition a management domain into some 275 domains. Or it is necessary to delegate a management authority 276 to another independent management domain. 278 R-2 It is necessary to allow different independent management 279 domains to coexist on the same network because two or more 280 organizations need to enter into the system and to management 281 it. 283 R-3 It is necessary that a device controls other devices that belong 284 to a different domain. 286 R-4 It is necessary to consider that a device is not always 287 geographically or network topologically close to the other 288 devices even when the devices belong to a same management 289 domain. 291 R-5 It is demanded to reduce the management cost as much as 292 possible. 294 R-6 It is necessary to consider the processing performance of the 295 device. And, it is necessary to suppress the power consumption 296 of the device. 298 R-7 It is necessary to consider bandwidth of the communication. 300 5. Issues 302 This section lists the issues in the cross-realm operation when we 303 apply the Kerberos version 5 into the system described in the section 304 3, and consider the system applied the Kerberos with the requirements 305 described in the section 4. 307 5.1. Unreliability of authentication chain 309 When the relationship of trust is constructed like a chain or 310 hierarchical, the authentication path is not dependable since it 311 strongly depends on intermediary realms that might not be under the 312 same authority. If any of the realms in the authentication path is 313 not available, then the principals of the end-realms can not perform 314 the cross-realm operation. 316 The end-point realms do not have full control and responsibility of 317 the success of the operations even if their respective KDCs are fully 318 functional. Dependability of a system decreases if the system relies 319 on uncontrolled components. We can not be sure at 100% about the 320 result of the authentication since we do not know how is it going in 321 intermediary realms. 323 This issue will happen as a by-product of a result meeting the 324 requirements R-1 and R-2. 326 5.2. Possibility of MITM in case of the indirect trust model 328 Every KDC in the authentication path knows the shared secret between 329 the client and the remaining KDCs in the authentication path. This 330 allows a malicious KDC to perform MITM attacks on communications 331 between the client and any KDC in the remaining authentication chain. 332 A malicious KDC also may learn the service session key that is used 333 to protect the communication between the client and the actual 334 application service, and performs a MITM attack between them. 336 In [SPECCROSS], the authors have analyzed the cross-realm operations 337 in Kerberos and provided formal proof of the issue discussed in this 338 section. 340 This issue will happen as a by-product of a result meeting the 341 requirements R-1 and R-2. 343 5.3. Scalability of the direct trust model 345 In the direct relationship of trust between each realm, the realms 346 involved in the cross-realm operation share keys and their respective 347 TGS principals are registered in each other's KDC. When direct trust 348 relationships are used, the KDC of each realm must maintain keys with 349 all foreign realms. This can become a cumbersome task when the 350 number of realms increase. This also increases maintenance cost. 352 This issue will happen as a by-product of a result meeting the 353 requirements R-1, R-2 and R-5. 355 5.4. Exposure to DoS Attacks 357 One of the assumption made when allowing the cross-realm operation in 358 Kerberos is that users can communicate with KDCs located in remote 359 realms. This practice introduces security threats because KDCs are 360 open to the public network. Administrators may think of restricting 361 the access to the KDC to the trusted realms only. However, this 362 approach is not scalable and does not really protect the KDC. 363 Indeed, when the remote realms have several IP prefixes (e.g. control 364 centers or outsourcing companies, located world wide), then the 365 administrator of the local KDC must collect the list of prefixes that 366 belong to these organization. The filtering rules must then 367 explicitly allow the incoming traffic from any host that belongs to 368 one of these prefixes. This makes the administrator's tasks more 369 complicated and prone to human errors. And also, the maintenance 370 cost increases. On the other hand, when ranges of external IP 371 addresses are allowed to communicate with the KDC, the risk of 372 becoming target to attacks from remote malicious users increases. 374 This issue will happen as a by-product of a result meeting the 375 requirements R-3, R-4 and R-5. 377 5.5. Client's performance 379 In the cross-realm operation, Kerberos clients have to perform TGS 380 exchanges with all the KDCs in the trust path, including the home KDC 381 and the target KDC. TGS exchange requires cryptographic operations. 382 This exchange demands important processing time especially when the 383 client has limited computational capabilities. The overhead of these 384 cross-realm exchanges grows into unacceptable delays. 386 We ported the MIT Kerberos library (version 1.2.4), implemented a 387 Kerberos client on our original board with H8 (16-bit, 20MHz), and 388 measured the process time of each Kerberos message [KRBIMPL]. It 389 takes 195 milliseconds to perform a TGS exchange with the on-board 390 H/W crypto engine. Indeed, this result seems reasonable to the 391 requirement of the response time for the control network. However, 392 we did not modify the clock speed of the H8 during our measurement. 393 The processing time must be slower in a actual environment because H8 394 is used with lowered clock speed in such system. Also, the delays 395 can grow to unacceptable delays when the number of intermediary 396 realms increases. 398 This issue will happen as a by-product of a result meeting the 399 requirements R-1, R-2, R-6 and R-7. 401 5.6. Pre-authentication problem in roaming scenarios 403 In roaming scenarios, the client needs to contact her home KDC to 404 obtain a cross-realm TGT for the local (or visited) realm. However, 405 the policy of the network access providers or the gateway in the 406 local network usually does not allow clients to communicate with 407 hosts in the Internet unless they provide valid authentication 408 credentials. In this manner, the client encounters a chicken-and-egg 409 problem where two resources are interdependent; the Internet 410 connection is needed to contact the home KDC and for obtaining 411 credentials, and on the other hand, the Internet connection is only 412 granted for clients who have valid credentials. As a result, the 413 Kerberos protocol can not be used as it is for authenticating roaming 414 clients requesting network access. 416 This issue will happen as a result meeting the requirements R-3 and 417 R-4. 419 6. Implementation consideration 421 This document just describes issues of the cross-realm operation. 422 However, there are important matters to be considered, when we solve 423 these issues and implement solution. Solution must not introduce new 424 problem. It should use existing components or protocols as much as 425 possible, and it should not introduce any definition of new 426 component. It should not require new changes to existing deployed 427 clients, and it should not influence the client code-base as much as 428 possible. Because a KDC is a significant server of the Kerberos 429 system. New burden should not be introduced into a KDC as much as 430 possible. You must not forget that there would be a trade-off matter 431 anytime. So an implementation may not solve all of the problems 432 stated in this document. 434 7. IANA Considerations 436 This document makes no request of IANA. 438 8. Security Considerations 440 This document clarifies the issues of the cross-realm operation of 441 the Kerberos V system, which include security issues to be 442 considered. See Section 5.1, 5.2, 5.3 and 5.4 for further details. 444 9. Acknowledgments 446 The authors are grateful to Nobuo Okabe, Kazunori Miyazawa, and 447 Atsushi Inoue. They gave us lots of comments and suggestions to this 448 document from the early stage. Nicolas Williams, Chaskiel Grundman 449 and Love Hornquist Astrand gave valuable suggestions and corrections. 450 Finally, the authors thank to Jeffrey Hutzelman. He gave us a lot of 451 suggestions for completion of this document. 453 10. References 455 10.1. Normative References 457 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 458 Kerberos Network Authentication Service (V5)", RFC 459 4120, July 2005. 461 10.2. Informative References 463 [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id= 464 531,00.html 466 [KRBIMPL] "A Prototype of a Secure Autonomous Bootstrap Mechanism 467 for Control Networks", Nobuo Okabe, Shoichi Sakane, 468 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki, 469 SAINT, pp. 56-62, IEEE Computer Society, 2006. 471 [NAM] http://www.nam.nl/ 473 [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing. 474 jsp&fp=/products/mpumcu/h8_family/ 476 [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi 477 ng.jsp&fp=/products/mpumcu/m16c_family/ 479 [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html 481 [SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C. 482 Walstad, "Specifying Kerberos 5 Cross-Realm 483 Authentication", Fifth Workshop on Issues in the Theory 484 of Security, Jan 2005. 486 Authors' Addresses 488 Shoichi Sakane 489 Ken'ichi Kamada 490 Yokogawa Electric Corporation 491 2-9-32 Nakacho, Musashino-shi, 492 Tokyo 180-8750 Japan 493 E-mail: Shouichi.Sakane@jp.yokogawa.com, 494 Ken-ichi.Kamada@jp.yokogawa.com 496 Saber Zrelli 497 Japan Advanced Institute of Science and Technology 498 1-1 Asahidai, Nomi, 499 Ishikawa 923-1292 Japan 500 E-mail: zrelli@jaist.ac.jp 501 Masahiro Ishiyama 502 Toshiba Corporation 503 1, komukai-toshiba-cho, Saiwai-ku, 504 Kawasaki 212-8582 Japan 505 E-mail: masahiro@isl.rdc.toshiba.co.jp