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