7 INTERNET-DRAFT S. Sakane
8 Intended Status: Informational Ken'ichi Kamada
9 Expires: January 31, 2010 Yokogawa Electric Corp.
17 Problem statement on the cross-realm operation of Kerberos
18 draft-ietf-krb-wg-cross-problem-statement-04.txt
25 This Internet-Draft is submitted to IETF in full conformance with the
26 provisions of BCP 78 and BCP 79.
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-
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."
38 The list of current Internet-Drafts can be accessed at
39 http://www.ietf.org/1id-abstracts.html
41 The list of Internet-Draft Shadow Directories can be accessed at
42 http://www.ietf.org/shadow.html
44 This Internet-Draft expires in January 31, 2010.
49 Copyright (c) 2009 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
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).
58 S.Sakane, et al. [Page 1]
60 Internet-Draft July 2009
63 Please review these documents carefully, as they describe your rights
64 and restrictions with respect to this document.
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.
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.
86 Conventions used in this document
88 It is assumed that the readers are familiar with the terms and
89 concepts described in the Kerberos Version 5 [RFC4120].
114 S.Sakane, et al. [Page 2]
116 Internet-Draft July 2009
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
170 S.Sakane, et al. [Page 3]
172 Internet-Draft July 2009
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.
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
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
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.
208 This document is assumed that the readers are familiar with the terms
209 and concepts described in the Kerberos Version 5 [RFC4120].
215 2.1. Kerberos basic operation
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.
226 S.Sakane, et al. [Page 4]
228 Internet-Draft July 2009
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.
264 2.2. Cross-realm operation
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.
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
282 S.Sakane, et al. [Page 5]
284 Internet-Draft July 2009
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.
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.
309 3. Applying Cross-Realm Kerberos in Complex Environments
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.
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.
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.
338 S.Sakane, et al. [Page 6]
340 Internet-Draft July 2009
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.
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.
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
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.
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.
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.
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
394 S.Sakane, et al. [Page 7]
396 Internet-Draft July 2009
401 R-3 It is necessary that a device controls other devices that belong
402 to a different domain.
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
409 R-5 It is demanded to reduce the management cost as much as
412 R-6 It is necessary to consider the processing performance of the
413 device. And, it is necessary to suppress the power consumption
416 R-7 It is necessary to consider bandwidth of the communication.
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.
427 5.1. Unreliability of authentication chain
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.
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
443 This issue will happen as a by-product of a result meeting the
444 requirements R-1 and R-2.
450 S.Sakane, et al. [Page 8]
452 Internet-Draft July 2009
455 5.2. Possibility of MITM in case of the indirect trust model
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.
465 In [SPECCROSS], the authors have analyzed the cross-realm operations
466 in Kerberos and provided formal proof of the issue discussed in this
469 This issue will happen as a by-product of a result meeting the
470 requirements R-1 and R-2.
473 5.3. Scalability of the direct trust model
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.
482 This issue will happen as a by-product of a result meeting the
483 requirements R-1, R-2 and R-5.
486 5.4. Exposure to DoS Attacks
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
506 S.Sakane, et al. [Page 9]
508 Internet-Draft July 2009
511 becoming target to attacks from remote malicious users increases.
513 This issue will happen as a by-product of a result meeting the
514 requirements R-3, R-4 and R-5.
517 5.5. Client's performance
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.
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
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.
542 5.6. Pre-authentication problem in roaming scenarios
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.
557 This issue will happen as a result meeting the requirements R-3 and
562 S.Sakane, et al. [Page 10]
564 Internet-Draft July 2009
567 6. Implementation consideration
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.
583 7. IANA Considerations
585 This document makes no request of IANA.
588 8. Security Considerations
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.
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.
608 10.1. Normative References
610 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
611 Kerberos Network Authentication Service (V5)", RFC
618 S.Sakane, et al. [Page 11]
620 Internet-Draft July 2009
623 10.2. Informative References
625 [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id=
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.
633 [NAM] http://www.nam.nl/
635 [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
636 jsp&fp=/products/mpumcu/h8_family/
638 [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
639 ng.jsp&fp=/products/mpumcu/m16c_family/
641 [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html
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.
652 Yokogawa Electric Corporation
653 2-9-32 Nakacho, Musashino-shi,
655 E-mail: Shouichi.Sakane@jp.yokogawa.com,
656 Ken-ichi.Kamada@jp.yokogawa.com
660 Japan Advanced Institute of Science and Technology
662 Ishikawa 923-1292 Japan
663 E-mail: zrelli@jaist.ac.jp
674 S.Sakane, et al. [Page 12]
676 Internet-Draft July 2009
681 1, komukai-toshiba-cho, Saiwai-ku,
682 Kawasaki 212-8582 Japan
683 E-mail: masahiro@isl.rdc.toshiba.co.jp
730 S.Sakane, et al. [Page 13]