idnits 2.17.1 draft-ietf-krb-wg-cross-problem-statement-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 529. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4120]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (December 17, 2007) is 5968 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 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: June 19, 2008 Yokogawa Electric Corp. 5 S. Zrelli 6 JAIST 7 M. Ishiyama 8 Toshiba Corp. 9 December 17, 2007 11 Problem statement on the cross-realm operation of Kerberos 12 draft-ietf-krb-wg-cross-problem-statement-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft expires in June 19, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 There are some issues when the cross-realm operation of the Kerberos 46 Version 5 [RFC4120] is employed into actual specific systems. This 47 document describes some examples of actual systems, and lists 48 requirements and restriction of the operation in such system. Then 49 it describes issues when we apply the cross-realm operation to such 50 system. 52 Conventions used in this document 54 It is assumed that the readers are familiar with the terms and 55 concepts described in the Kerberos Version 5 [RFC4120]. 57 Table of Contents 59 1. Introduction ................................................. 4 60 2. Kerberos system .............................................. 4 61 2.1. Kerberos basic operation ................................ 4 62 2.2. Cross-realm operation ................................... 5 63 3. Example of actual environment ................................ 6 64 4. Requirements ................................................. 7 65 5. Issues ....................................................... 8 66 5.1. Unreliability of authentication chain ................... 8 67 5.2. Possibility of MITM in case of the indirect trust model . 9 68 5.3. Scalability of the direct trust model ................... 9 69 5.4. Exposure to DoS Attacks ................................. 9 70 5.5. Client's performance .................................... 10 71 5.6. Pre-authentication problem in roaming scenarios ......... 10 72 6. Implementation consideration ................................. 11 73 7. IANA Considerations .......................................... 11 74 8. Security Considerations ...................................... 11 75 9. Acknowledgments .............................................. 11 76 10. References ................................................... 11 77 10.1. Normative References ................................... 11 78 10.2. Informative References ................................. 12 79 Authors' Addresses ............................................... 12 80 Full Copyright Statement ......................................... 13 81 Intellectual Property Statement .................................. 13 83 1. Introduction 85 Kerberos Version 5 is a widely deployed mechanism that enables a 86 server to authenticate a client's access. Each client belongs to a 87 managed domain called realm. Kerberos supports authentication when a 88 client and a server belong to different realms. This is called 89 cross-realm operation. 91 Meanwhile, there are lots of manners of operation in actual systems, 92 where Kerberos could be applied. Large systems or distributed 93 systems are typically split into several managed domains. For 94 example, systems could be split into multiple domains for 95 geographical reasons, or to implement different management policies. 96 Even in such systems, a common authentication mechanism for the 97 different managed domains is required. When the cross-realm 98 operation of Kerberos is applied to such systems, some issues come 99 out. 101 This document briefly describes the Kerberos Version 5 system and its 102 cross-realm mode of operation. Then, it describes two actual systems 103 that Kerberos could be applied to. and describes seven requirements 104 of those systems in term both of management and operation. Finally, 105 it lists six issues of the cross-realm operation when it is applied 106 to those system. 108 Note that this document might not describe all of the issues of 109 cross-realm operation. New issues might be found in the future. It 110 also does not propose any solution to solve the issues. Furthermore, 111 publication of this document does not mean that each of the issues 112 have to be solved by the IETF members. Hence, in further step, we 113 will analyze the issues, define problems and explore the solutions. 114 These works will be described in another document. 116 This document is assumed that the readers are familiar with the terms 117 and concepts described in the Kerberos Version 5 [RFC4120]. 119 2. Kerberos system 121 2.1. Kerberos basic operation 123 Kerberos [RFC4120] is a widely deployed authentication system. The 124 authentication process in Kerberos involves principals and a Key 125 Distribution Center (KDC). The principals can be users or services. 126 Each KDC maintains a database of principals and shares a secret key 127 with each registered principal. 129 The authentication process allows a user to acquire the needed 130 credentials from the KDC. These credentials allow services to 131 authenticate the users before granting them access to the resources. 132 An important part of the credentials are called Tickets. There are 133 two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket. 134 The TGT is obtained periodically from the KDC and has a limited limit 135 after which it expires and the user must renew it. The TGT is used 136 to obtain the other kind of tickets, Service Tickets. The user 137 obtains a TGT from the Authentication Service (AS), a logical 138 component of the KDC. The process of obtaining a TGT is referred to 139 as 'AS exchange'. When a TGT request is issued by an user, the AS 140 responds by sending a reply packet containing the credentials which 141 consists of the TGT along with a random key called 'TGS Session Key'. 142 The TGT contains a set of information encrypted using a secret key 143 associated with a special service referred to as TGS (Ticket Granting 144 Service). The TGS session key is encrypted using the user's key so 145 that the user can obtain the TGS session key only if she knows the 146 secret key shared with the KDC. The TGT then is used to obtain 147 Service Tickets from the Ticket Granting Service (TGS)- the second 148 component of the KDC. The process of obtaining service tickets is 149 referred to as 'TGS exchange'. The request for a service ticket 150 consists on a packet containing a TGT and an 'Authenticator'. The 151 Authenticator is encrypted using the TGS session key and contains the 152 identity of the user as well as time stamps (for protection against 153 replay attacks). After decrypting the TGT (which was encrypted by 154 the AS using the TGS's secret key), the TGS extracts the TGS session 155 key. Using that session key, it decrypts the Authenticator and 156 authenticates the user. Then, the TGS issues credentials requested 157 by the user. These credentials consist on a service ticket and a 158 session key that will be used to authenticate the user with the 159 desired application service. 161 2.2. Cross-realm operation 163 The Kerberos protocol provides cross-realm authentication 164 capabilities. This allows users to obtain service tickets to access 165 services in foreign realms. In order to access such services, the 166 users first contact their home KDC asking for a TGT that will be used 167 with the TGS of the foreign realm. If the home realm and the foreign 168 realm share keys and have an established trust relationship, the home 169 KDC delivers the requested TGT. 171 However, if the home realm does not share inter-realm keys with the 172 foreign realm, the home KDC will provide a TGT that can be used with 173 an intermediary foreign realm that is likely to be sharing inter- 174 realm keys with the target realm. The client can use this 175 'intermediary TGT' to communicate with the intermediary KDC which 176 will iterate the actions taken by the home KDC. If the intermediary 177 KDC does not share inter-realm keys with the target foreign realm it 178 will point the user to another intermediary KDC (just as in the first 179 exchange between the user and its home KDC). However, in the other 180 case (when it shares inter-realm keys with the target realm), the 181 intermediary KDC will issue a TGT that can be used with the KDC of 182 the target realm. After obtaining a TGT for the desired foreign 183 realm, the client uses it to obtain service tickets from the TGS of 184 the foreign realm. Finally, the user access the service using the 185 service ticket. 187 When the realms belong to the same institution, a chain of trust can 188 be determined by the client or the KDC by following the DNS domain 189 hierarchy and supposing that the parent domains share keys with all 190 its child sub-domains. However, because the inter-realm trust model 191 is not necessarily constructing the hierarchic approach anytime, the 192 trust path must be specified manually. When intermediary realms are 193 involved, the success of the cross-realm operation completely depends 194 on the realms that are part of the authentication path. 196 3. Example of actual environment 198 In order to help understanding both requirements and restriction, 199 this section describes scale and operation of actual systems, where 200 it is possible to apply Kerberos. 202 We refer to actual petrochemical enterprise [SHELLCHEM], and show two 203 examples among its plants. The enterprise produces bulk 204 petrochemicals and their delivery to large industrial customers. 205 There are 43 typical plants of the enterprise all over the world. 206 They are managed by the operation sites placed in 35 countries. This 207 section shows two examples of them. 209 One is an example of a centralized system [CSPC]. CSPC is operated 210 by a joint enterprise of two companies. This system is one of the 211 largest systems of this enterprise in the world. This is placed in 212 the area of 3.4 square kilo meters in the north coast of Daya Bay, 213 Guangdong, which is at the southeast of China. 3,000 network 214 segments are established in the system. 16,000 control devices are 215 connected to the local area network. These devices belong to 216 different 9 sub systems, A control device has some control points, 217 which are controlled and monitored by other devices remotely. There 218 are 200,000 control points in all. They are controlled by 3 219 different control center. 221 Another example is a distributed system [NAM]. The NAM (Nederlandse 222 Aardolie Maatschappij) is operated by a partnership company of two 223 enterprises that represent the oil company. This system is 224 constituted by some plants that are geographically distributed within 225 the range of 863 square kilometers in the northern part of 226 Netherlands. 26 plants, each is named "cluster", are scattered in 227 the area. They are connected each other by a private ATM WAN. Each 228 cluster has approximately 500-1,000 control devices. These devices 229 are managed by each local control center in each cluster. In the 230 entire system of the NAM, there are one million control points. 232 In the both of the systems, the end devices are basically connected 233 to a local network by a twisted pair cable, which is a low band-width 234 of 32 kbps. Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS- 235 M16C], are employed by many control devices. Furthermore, to 236 suppress power consumption, these CPU may be lowered the number of 237 clocks. Because there is a requirement of the explosion-proof. The 238 requirement restricts the amount of total energy in the device. 240 A device on the network collects data from other devices which are 241 monitoring condition of the system. The device uses the data to make 242 a decision how to control another devices. And then the device gives 243 more than one instruction that controls other devices. If it took 244 time for data to reach, they could not be associated. The travel 245 time of data from the device to the other device is demanded within 1 246 second at least. 248 A part of the operation, like control of these system, maintenance, 249 and the environmental monitoring, is consigned to an external 250 organization. Agents who are consigned walk around the plant to get 251 their information, or watch the plant from a remote site. 253 4. Requirements 255 This section lists the requirements derived from the previous 256 section. R-1, R-2, R-3 and R-4 are related to the management of the 257 divided system. R-5, R-6 and R-7 are related to the restriction to 258 such industrial network. 260 R-1 It is necessary to partition a management domain into some 261 domains. Or it is necessary to delegate a management authority 262 to another independent management domain. 264 R-2 It is necessary to allow different independent management 265 domains to coexist on the same network because two or more 266 organizations need to enter into the system and to management 267 it. 269 R-3 It is necessary that a device controls other devices that belong 270 to a different domain. 272 R-4 It is necessary to consider that a device is not always 273 geographically or network topologically close to the other 274 devices even when the devices belong to a same management 275 domain. 277 R-5 It is demanded to reduce the management cost as much as 278 possible. 280 R-6 It is necessary to consider the processing performance of the 281 device. And, it is necessary to suppress the power consumption 282 of the device. 284 R-7 It is necessary to consider bandwidth of the communication. 286 5. Issues 288 This section lists the issues in the cross-realm operation when we 289 apply the Kerberos version 5 into the system described in the section 290 3, and consider the system applied the Kerberos with the requirements 291 described in the section 4. 293 5.1. Unreliability of authentication chain 295 When the relationship of trust is constructed like a chain or 296 hierarchical, the authentication path is not dependable since it 297 strongly depends on intermediary realms that might not be under the 298 same authority. If any of the realms in the authentication path is 299 not available, then the principals of the end-realms can not perform 300 the cross-realm operation. 302 The end-point realms do not have full control and responsibility of 303 the success of the operations even if their respective KDCs are fully 304 functional. Dependability of a system decreases if the system relies 305 on uncontrolled components. We can not be sure at 100% about the 306 result of the authentication since we do not know how is it going in 307 intermediary realms. 309 This issue will happen as a by-product of a result meeting the 310 requirements R-1 and R-2. 312 5.2. Possibility of MITM in case of the indirect trust model 314 Every KDC in the authentication path knows the shared secret between 315 the client and the remaining KDCs in the authentication path. This 316 allows a malicious KDC to perform MITM attacks on communications 317 between the client and any KDC in the remaining authentication chain. 318 A malicious KDC also may learn the service session key that is used 319 to protect the communication between the client and the actual 320 application service, and performs a MITM attack between them. 322 In [SPECCROSS], the authors have analyzed the cross-realm operations 323 in Kerberos and provided formal proof of the issue discussed in this 324 section. 326 This issue will happen as a by-product of a result meeting the 327 requirements R-1 and R-2. 329 5.3. Scalability of the direct trust model 331 In the direct relationship of trust between each realm, the realms 332 involved in the cross-realm operation share keys and their respective 333 TGS principals are registered in each other's KDC. When direct trust 334 relationships are used, the KDC of each realm must maintain keys with 335 all foreign realms. This can become a cumbersome task when the 336 number of realms increase. This also increases maintenance cost. 338 This issue will happen as a by-product of a result meeting the 339 requirements R-1, R-2 and R-5. 341 5.4. Exposure to DoS Attacks 343 One of the assumption made when allowing the cross-realm operation in 344 Kerberos is that users can communicate with KDCs located in remote 345 realms. This practice introduces security threats because KDCs are 346 open to the public network. Administrators may think of restricting 347 the access to the KDC to the trusted realms only. However, this 348 approach is not scalable and does not really protect the KDC. 349 Indeed, when the remote realms have several IP prefixes (e.g. control 350 centers or outsourcing companies, located world wide), then the 351 administrator of the local KDC must collect the list of prefixes that 352 belong to these organization. The filtering rules must then 353 explicitly allow the incoming traffic from any host that belongs to 354 one of these prefixes. This makes the administrator's tasks more 355 complicated and prone to human errors. And also, the maintenance 356 cost increases. On the other hand, when ranges of external IP 357 addresses are allowed to communicate with the KDC, the risk of 358 becoming target to attacks from remote malicious users increases. 360 5.5. Client's performance 362 In the cross-realm operation, Kerberos clients have to perform TGS 363 exchanges with all the KDCs in the trust path, including the home KDC 364 and the target KDC. TGS exchange requires cryptographic operations. 365 This exchange demands important processing time especially when the 366 client has limited computational capabilities. The overhead of these 367 cross-realm exchanges grows into unacceptable delays. 369 We ported the MIT Kerberos library (version 1.2.4), implemented a 370 Kerberos client on our original board with H8 (16-bit, 20MHz), and 371 measured the process time of each Kerberos message [KRBIMPL]. It 372 takes 195 milliseconds to perform a TGS exchange with the on-board 373 H/W crypto engine. Indeed, this result seems reasonable to the 374 requirement of the response time for the control network. However, 375 we did not modify the clock speed of the H8 during our measurement. 376 The processing time must be slower in a actual environment because H8 377 is used with lowered clock speed in such system. Also, the delays 378 can grow to unacceptable delays when the number of intermediary 379 realms increases. 381 This issue will happen as a by-product of a result meeting the 382 requirements R-1, R-2, R-6 and R-7. 384 5.6. Pre-authentication problem in roaming scenarios 386 In roaming scenarios, the client needs to contact her home KDC to 387 obtain a cross-realm TGT for the local (or visited) realm. However, 388 the policy of the network access providers or the gateway in the 389 local network usually does not allow clients to communicate with 390 hosts in the Internet unless they provide valid authentication 391 credentials. In this manner, the client encounters a chicken-and-egg 392 problem where two resources are interdependent; the Internet 393 connection is needed to contact the home KDC and for obtaining 394 credentials, and on the other hand, the Internet connection is only 395 granted for clients who have valid credentials. As a result, the 396 Kerberos protocol can not be used as it is for authenticating roaming 397 clients requesting network access. 399 This issue will happen as a result meeting the requirements R-3 and 400 R-4. 402 6. Implementation consideration 404 This document just describes issues of the cross-realm operation. 405 However, there are important matters to be considered, when we solve 406 these issues and implement solution. Solution must not introduce new 407 problem. It should use existing components or protocols as much as 408 possible, and it should not introduce any definition of new 409 component. It should not require new changes to existing deployed 410 clients, and it should not influence the client code-base as much as 411 possible. Because a KDC is a significant server of the Kerberos 412 system. new burden should not be introduced into a KDC as much as 413 possible. You must not forget that there would be a trade-off matter 414 anytime. So an implementation may not solve all of the problems 415 stated in this document. 417 7. IANA Considerations 419 This document makes no request of IANA. 421 8. Security Considerations 423 This document just clarifies some issues of the cross-realm operation 424 of the Kerberos V system. There is especially not describing 425 security. Some troubles might be caused to your system by malicious 426 user who misuses the description of this document if it dares to say. 428 9. Acknowledgments 430 The authors are grateful to Nobuo Okabe, Kazunori Miyazawa, and 431 Atsushi Inoue. They gave us lots of comments and suggestions to this 432 document from the early stage. Nicolas Williams, Chaskiel Grundman 433 and Love Hornquist Astrand gave valuable suggestions and corrections. 434 Finally, the authors thank to Jeffrey Hutzelman. He gave us a lot of 435 suggestions for completion of this document. 437 10. References 439 10.1. Normative References 441 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 442 Kerberos Network Authentication Service (V5)", RFC 443 4120, July 2005. 445 10.2. Informative References 447 [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id= 448 531,00.html 450 [KRBIMPL] "A Prototype of a Secure Autonomous Bootstrap Mechanism 451 for Control Networks", Nobuo Okabe, Shoichi Sakane, 452 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki, 453 SAINT, pp. 56-62, IEEE Computer Society, 2006. 455 [NAM] http://www.nam.nl/ 457 [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing. 458 jsp&fp=/products/mpumcu/h8_family/ 460 [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi 461 ng.jsp&fp=/products/mpumcu/m16c_family/ 463 [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html 465 [SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C. 466 Walstad, "Specifying Kerberos 5 Cross-Realm 467 Authentication", Fifth Workshop on Issues in the Theory 468 of Security, Jan 2005. 470 Authors' Addresses 472 Shoichi Sakane 473 Ken'ichi Kamada 474 Yokogawa Electric Corporation 475 2-9-32 Nakacho, Musashino-shi, 476 Tokyo 180-8750 Japan 477 E-mail: Shouichi.Sakane@jp.yokogawa.com, 478 Ken-ichi.Kamada@jp.yokogawa.com 480 Saber Zrelli 481 Japan Advanced Institute of Science and Technology 482 1-1 Asahidai, Nomi, 483 Ishikawa 923-1292 Japan 484 E-mail: zrelli@jaist.ac.jp 485 Masahiro Ishiyama 486 Toshiba Corporation 487 1, komukai-toshiba-cho, Saiwai-ku, 488 Kawasaki 212-8582 Japan 489 E-mail: masahiro@isl.rdc.toshiba.co.jp 491 Full Copyright Statement 493 Copyright (C) The IETF Trust (2007). 495 This document is subject to the rights, licenses and restrictions 496 contained in BCP 78, and except as set forth therein, the authors 497 retain all their rights. 499 This document and the information contained herein are provided on an 500 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 501 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 502 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 503 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 504 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 505 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 507 Intellectual Property Statement 509 The IETF takes no position regarding the validity or scope of any 510 Intellectual Property Rights or other rights that might be claimed to 511 pertain to the implementation or use of the technology described in 512 this document or the extent to which any license under such rights 513 might or might not be available; nor does it represent that it has 514 made any independent effort to identify any such rights. Information 515 on the procedures with respect to rights in RFC documents can be 516 found in BCP 78 and BCP 79. 518 Copies of IPR disclosures made to the IETF Secretariat and any 519 assurances of licenses to be made available, or the result of an 520 attempt made to obtain a general license or permission for the use of 521 such proprietary rights by implementers or users of this 522 specification can be obtained from the IETF on-line IPR repository at 523 http://www.ietf.org/ipr. 525 The IETF invites any interested party to bring to its attention any 526 copyrights, patents or patent applications, or other proprietary 527 rights that may cover technology that may be required to implement 528 this standard. Please address the information to the IETF at ietf- 529 ipr@ietf.org.