7 INTERNET-DRAFT S. Sakane
8 Expires: October 29, 2007 Yokogawa Electric Corp.
16 Problem statement on the cross-realm operation
17 of Kerberos in a specific system
18 draft-sakane-krb-cross-problem-statement-02.txt
25 By submitting this Internet-Draft, each author represents that any
26 applicable patent or other IPR claims of which he or she is aware
27 have been or will be disclosed, and any of which he or she becomes
28 aware will be disclosed, in accordance with Section 6 of BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF), its areas, and its working groups. Note that
32 other groups may also distribute working documents as Internet-
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 The list of current Internet-Drafts can be accessed at
41 http://www.ietf.org/1id-abstracts.html
43 The list of Internet-Draft Shadow Directories can be accessed at
44 http://www.ietf.org/shadow.html
46 This Internet-Draft expires in October 29, 2007.
51 Copyright (C) The IETF Trust (2007).
58 S.Sakane, et al. [Page 1]
60 Internet-Draft April 2007
65 There are some issues when the cross-realm operation of the Kerberos
66 Version 5 [RFC4120] is employed into the specific systems. This
67 document describes some manners of the real example, and lists
68 requirements of the operation in such real system. Then it clarifies
69 issues when we apply the cross-realm operation to such specific
74 Conventions used in this document
76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
78 document are to be interpreted as described in RFC 2119 [RFC2119].
80 It is assumed that the readers are familiar with the terms and
81 concepts described in the Kerberos Version 5 [RFC4120].
114 S.Sakane, et al. [Page 2]
116 Internet-Draft April 2007
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. The status of the industrial system .......................... 6
126 4. Requirements ................................................. 7
127 5. Issues ....................................................... 8
128 5.1. Unreliability of authentication chain ................... 8
129 5.2. No PFS in case of the indirect trust model .............. 8
130 5.3. Scalability of the direct trust model ................... 9
131 5.4. Exposure to DoS Attacks ................................. 9
132 5.5. Client's performance .................................... 9
133 5.6. Pre-authentication problem in roaming scenarios ......... 10
134 6. Implementation consideration ................................. 10
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 ................................. 11
141 Authors' Addresses ............................................... 12
142 Full Copyright Statement ......................................... 12
143 Intellectual Property Statement .................................. 13
170 S.Sakane, et al. [Page 3]
172 Internet-Draft April 2007
177 The Kerberos Version 5 is a widely deployed mechanism that a server
178 can authenticate a client access. Each client belongs to a managed
179 domain called realm. Kerberos supports the authentication in case of
180 situation that a client and a server belong to different realms.
181 This is called the cross-realm operation.
183 Meanwhile, there are lots of manners of operation in the real system,
184 where Kerberos could be applied. Sometimes, there are several
185 managed domain in such system. and it requires the authentication
186 mechanism over the different managed domains. When the cross-realm
187 operation of Kerberos is applied to such specific systems, some
190 This document briefly describes the Kerberos Version 5 system and the
191 cross-realm operation. Then, it describes two real systems that can
192 be applied the Kerberos system, and describes nine requirements of
193 those systems in term both of management and operation. Finally, it
194 lists six issues of the cross-realm operation when it is applied to
197 Note that it might not describe whole of issues of the cross-realm
198 operation. It also does not propose any solution to solve issues
199 described in this document. In further step, we have to analyze, and
200 compare candidates of solutions. This work will be in another
203 This document is assumed that the readers are familiar with the terms
204 and concepts described in the Kerberos Version 5 [RFC4120].
210 2.1. Kerberos basic operation
212 Kerberos [RFC4120] is a widely deployed authentication system. The
213 authentication process in Kerberos involves principals and a Key
214 Distribution Center (KDC). The principals can be users or services.
215 Each KDC maintains a principals database and shares a secret key with
216 each registered principal.
218 The authentication process allows a user to acquire the needed
219 credentials from the KDC. These credentials allow services to
220 authenticate the users before granting them access to the resources.
221 An important part of the credentials are called Tickets. There are
222 two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket.
226 S.Sakane, et al. [Page 4]
228 Internet-Draft April 2007
231 The TGT is obtained periodically from the KDC and has a limited limit
232 after which it expires and the user must renew it. The TGT is used
233 to obtain the other kind of tickets, Service Tickets. The user
234 obtains a TGT from the Authentication Service (AS), a logical
235 component of the KDC. The process of obtaining a TGT is referred to
236 as 'AS exchange'. When a TGT request is issued by an user, the AS
237 responds by sending a reply packet containing the credentials which
238 consists of the TGT along with a random key called 'TGS Session Key'.
239 The TGT contains a set of information encrypted using a secret key
240 associated with a special service referred to as TGS (Ticket Granting
241 Service). The TGS session key is encrypted using the user's key so
242 that the user can obtain the TGS session key only if she knows the
243 secret key shared with the KDC. The TGT then is used to obtain
244 Service Tickets from the Ticket Granting Service (TGS)- the second
245 component of the KDC. The process of obtaining service tickets is
246 referred to as 'TGS exchange'. The request for a service ticket
247 consists on a packet containing a TGT and an 'Authenticator'. The
248 Authenticator is encrypted using the TGS session key and contains the
249 identity of the user as well as time stamps (for protection against
250 replay attacks). After decrypting the TGT (which was encrypted by
251 the AS using the TGS's secret key), the TGS extracts the TGS session
252 key. Using that session key, it decrypts the Authenticator and
253 authenticates the user. Then, the TGS issues credentials requested
254 by the user. These credentials consist on a service ticket and a
255 session key that will be used to authenticate the user with the
256 desired application service.
259 2.2. Cross-realm operation
261 The Kerberos protocol provides the cross-realm authentication
262 capabilities. This allows users to obtain service tickets to access
263 services in foreign realms. In order to access such services, the
264 users first contact their home KDC asking for a TGT that will be used
265 with the TGS of the foreign realm. If the home realm and the foreign
266 realm share keys and have an established trust relationship, the home
267 KDC delivers the requested TGT.
269 However, if the home realm does not share cross-realm keys with the
270 foreign realm, the home KDC will provide a TGT that can be used with
271 an intermediary foreign realm that is likely to be sharing cross-
272 realm keys with the target realm. The client can use this
273 'intermediary TGT' to communicate with the intermediary KDC which
274 will iterate the actions taken by the home KDC: If the intermediary
275 KDC does not share cross-realm keys with the target foreign realm it
276 will point the user to another intermediary KDC (just as in the first
277 exchange between the user and its home KDC). However, in the other
278 case (when it shares cross- realm keys with the target realm), the
282 S.Sakane, et al. [Page 5]
284 Internet-Draft April 2007
287 intermediary KDC will issue a TGT that can be used with the KDC of
288 the target realm. After obtaining a TGT for the desired foreign
289 realm, the client uses it to obtain service tickets from the TGS of
290 the foreign realm. Finally, the user access the service using the
293 When the realms belong to the same institution, a chain of trust can
294 be determined by the client or the KDC by following the DNS domain
295 hierarchy and supposing that the parent domains share keys with all
296 its child sub-domains. However, because the inter-realm trust model
297 is not necessarily constructing the hierarchic approach anytime, the
298 trust path must be specified manually. When intermediary realms are
299 involved, the success of the cross-realm operation completely depends
300 on the realms that are part of the authentication path.
303 3. The status of the industrial system
305 This section describes the state in the industrial environment on
306 which we focuses. It would be easier to understand the requirement
307 and the restriction described after.
309 First, to understand the scale of the environment, we refers to a
310 petrochemical company, Shell Petrochemical Company Limited.
311 [SHELLCHEM]. It produces bulk petrochemicals and their delivery to
312 large industrial customers. There are 43 typical plants of the
313 company all over the world. They are managed by the operation sites
314 placed in 35 countries. This section shows two examples of them.
316 One is the CSPC [CSPC], an example of the centralized plant. The
317 CSPC is a joint enterprise of CNOOC and Shell. This plant is one of
318 the hugest systems of a petrochemical industry in the world. This is
319 placed in the area of 3.4 square kilo meters in the north coast of
320 Daya Bay, Guangdong, which is at the southeast of China. 3,000
321 network segments are established in the system. 16,000 control
322 devices are connected to the local area network. These devices
323 belong to different 9 sub systems, A control device has some control
324 points, which are controlled and monitored by other devices remotely.
325 There are 200,000 control points in all. They are controlled by 3
326 different control center.
328 Another example is the NAM (Nederlandse Aardolie Maatschappij), an
329 example of the distributed plant system. The NAM is a partnership
330 enterprise of Shell and Exxon Mobil Corporation. It is a plant
331 system group that geographically distributes to scatter in the area
332 of 863 square kilo meters of Netherlands. 26 plants, each is named
333 "cluster", are scattered in the area. They are connected each other
334 by a private ATM WAN. Each cluster has approximately 500-1,000
338 S.Sakane, et al. [Page 6]
340 Internet-Draft April 2007
343 control devices. These devices are managed by each local control
344 center in each cluster. In the entire system of the NAM, there are
345 one million control points.
347 In the both of the systems, the end devices are basically connected
348 to a local network by a twisted pair cable, which is a low band-width
349 of 32 kbps. Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS-
350 M16C], are employed by many control devices. Furthermore, to
351 suppress power consumption, these CPU may be lowered the number of
352 clocks. Because there is a requirement of the explosion-proof. The
353 requirement restricts the amount of total energy in the device.
355 A device on the network collects data from other devices which are
356 monitoring condition of the system. The device uses the data to make
357 a decision how to control another devices. And then the device gives
358 more than one instruction that controls other devices. If it took
359 time for data to reach, they could not be associated. The travel
360 time of data from the device to the other device is demanded within 1
363 A part of the operation, like control of these system, maintenance,
364 and the environmental monitoring, is consigned to an external
365 organization. Agents who are consigned walk around the plant to get
366 their information, or watch the plant from a remote site.
371 This section listed requirements derived from the previous section.
372 R-1, R-2, R-3 and R-4 are related to the management of the divided
373 system. R-5, R-6 and R-7 are related to the restriction to the
377 R-1 It is necessary to partition a management domain into some
378 domains. Or it is necessary to delegate a management authority
379 to another independent management domain.
381 R-2 It is necessary to allow different independent management
382 domains to coexist on the same network because two or more
383 organizations need to enter into the system and to management
386 R-3 It is necessary that a device controls other devices that belong
387 to a different domain.
389 R-4 It is necessary to consider that a device is not always
390 geographically or network topologically close to the other
394 S.Sakane, et al. [Page 7]
396 Internet-Draft April 2007
399 devices even when the devices belong to a same management
402 R-5 It is demanded to reduce the management cost as much as
405 R-6 It is necessary to consider the processing performance of the
406 device. And, it is necessary to suppress the power consumption
409 R-7 It is necessary to consider bandwidth of the communication.
414 This section lists the issues in the cross-realm operation when we
415 apply the Kerberos version 5 into the system described in the section
416 3, and consider the system applied the Kerberos with the requirements
417 described in the section 4.
420 5.1. Unreliability of authentication chain
422 When the relationship of trust is constructed like a chain or
423 hierarchical, the authentication path is not dependable since it
424 strongly depends on intermediary realms that might not be under the
425 same authority. If any of the realms in the authentication path is
426 not available, then the principals of the end-realms can not perform
427 the cross-realm operation.
429 The end-point realms do not have full control and responsibility of
430 the success of the operations even if their respective KDCs are fully
431 functional. Dependability of a system decreases if the system relies
432 on uncontrolled components. We can not be sure at 100% about the
433 result of the authentication since we do not know how is it going in
436 This issue will happen as a by-product of a result meeting the
437 requirements R-1 and R-2.
440 5.2. No PFS in case of the indirect trust model
442 In [SPECCROSS], any KDC in the authentication path can learn the
443 session key that will be used between the client and the desired
444 service. This means that any intermediary realm is able to spoof the
445 identity either of the service or the client as well as to eavesdrop
446 on the communication between the client and the server.
450 S.Sakane, et al. [Page 8]
452 Internet-Draft April 2007
455 This issue will happen as a by-product of a result meeting the
456 requirements R-1 and R-2.
459 5.3. Scalability of the direct trust model
461 In the direct relationship of trust between each realm, the realms
462 involved in the cross-realm operation share keys and their respective
463 TGS principals are registered in each other's KDC. When direct trust
464 relationships are used, the KDC of each realm must maintain keys with
465 all foreign realms. This can become a cumbersome task when the
466 number of realms increase. This also increases maintenance cost.
468 This issue will happen as a by-product of a result meeting the
469 requirements R-1, R-2 and R-5.
472 5.4. Exposure to DoS Attacks
474 One of the assumption made when allowing the cross-realm operation in
475 Kerberos is that users can communicate with KDCs located in remote
476 realms. This practice introduces security threats because KDCs are
477 open to the public network. Administrators may think of restricting
478 the access to the KDC to the trusted realms only. However, this
479 approach is not scalable and does not really protect the KDC.
480 Indeed, when the remote realms have several IP prefixes (e.g. control
481 centers or outsourcing companies, located world wide), then the
482 administrator of the local KDC must collect the list of prefixes that
483 belong to these organization. The filtering rules must then
484 explicitly allow the incoming traffic from any host that belongs to
485 one of these prefixes. This makes the administrator's tasks more
486 complicated and prone to human errors. And also, the maintenance
487 cost increases. On the other hand, when ranges of external IP
488 addresses are allowed to communicate with the KDC, the risk of
489 becoming target to attacks from remote malicious users increases.
492 5.5. Client's performance
494 In the cross-realm operation, Kerberos clients have to perform TGS
495 exchanges with all the KDCs in the trust path, including the home KDC
496 and the target KDC. TGS exchange requires cryptographic operations.
497 This exchange demands important processing time especially when the
498 client has limited computational capabilities. The overhead of these
499 cross-realm exchanges grows into unacceptable delays.
501 We ported the MIT Kerberos library (version 1.2.4), implemented a
502 Kerberos client on our original board with H8 (16-bit, 20MHz), and
506 S.Sakane, et al. [Page 9]
508 Internet-Draft April 2007
511 measured the process time of each Kerberos message [KRBIMPL]. It
512 takes 195 milliseconds to perform a TGS exchange with the on-board
513 H/W crypto engine. Indeed, this result seems reasonable to the
514 requirement of the response time for the control network. However,
515 we did not modify the clock speed of the H8 during our measurement.
516 The processing time must be slower in a real environment because H8
517 is used with lowered clock speed in such system. Also, the delays
518 can grow to unacceptable delays when the number of intermediary
521 This issue will happen as a by-product of a result meeting the
522 requirements R-1, R-2, R-6 and R-7.
525 5.6. Pre-authentication problem in roaming scenarios
527 In roaming scenarios, the client needs to contact her home KDC to
528 obtain a cross-realm TGT for the local (or visited) realm. However,
529 the policy of the network access providers or the gateway in the
530 local network usually does not allow clients to communicate with
531 hosts in the Internet unless they provide valid authentication
532 credentials. In this manner, the client encounters a chicken-and-egg
533 problem where two resources are interdependent; the Internet
534 connection is needed to contact the home KDC and for obtaining
535 credentials, and on the other hand, the Internet connection is only
536 granted for clients who have valid credentials. As a result, the
537 Kerberos protocol can not be used as it is for authenticating roaming
538 clients requesting network access.
540 This issue will happen as a result meeting the requirements R-3 and
544 6. Implementation consideration
546 This document just describes issues of the cross-realm operation in
547 the specific systems. However, there are important matters to be
548 considered, when we solve these issues and implement solution.
549 Solution must not introduce new problem. Solution should use
550 existing components or protocols as much as possible, should not
551 introduce any definition of new component. Solution must not require
552 a KDC to have any additional process. You must not forget that there
553 would be a trade-off matter anytime. So an implementation may not
554 solve all of the problems stated in this document.
562 S.Sakane, et al. [Page 10]
564 Internet-Draft April 2007
567 7. IANA Considerations
569 This document makes no request of IANA.
572 8. Security Considerations
574 This document just clarifies some issues of the cross-realm operation
575 of the Kerberos V system. There is especially not describing
576 security. Some troubles might be caused to your system by malicious
577 user who misuses the description of this document if it dares to say.
582 The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa,
583 Ken'ichi Kamada and Atsushi Inoue. They gave us lots of comments and
584 input for this document.
590 10.1. Normative References
592 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
593 Kerberos Network Authentication Service (V5)", RFC
597 10.2. Informative References
599 [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id=
602 [KRBIMPL] "A Prototype of a Secure Autonomous Bootstrap Mechanism
603 for Control Networks", Nobuo Okabe, Shoichi Sakane,
604 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki,
605 SAINT, pp. 56-62, IEEE Computer Society, 2006.
607 [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
608 jsp&fp=/products/mpumcu/h8_family/
610 [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
611 ng.jsp&fp=/products/mpumcu/m16c_family/
613 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
614 Requirement Levels", RFC 2119, March 1997.
618 S.Sakane, et al. [Page 11]
620 Internet-Draft April 2007
623 [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html
625 [SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C.
626 Walstad, "Specifying Kerberos 5 Cross-Realm
627 Authentication", Fifth Workshop on Issues in the Theory
628 of Security, Jan 2005.
633 Yokogawa Electric Corporation
634 2-9-32 Nakacho, Musashino-shi,
636 E-mail: Shouichi.Sakane@jp.yokogawa.com,
640 Japan Advanced Institute of Science and Technology
642 Ishikawa 923-1292 Japan
643 E-mail: zrelli@jaist.ac.jp
648 1, komukai-toshiba-cho, Saiwai-ku,
649 Kawasaki 212-8582 Japan
650 E-mail: masahiro@isl.rdc.toshiba.co.jp
653 Full Copyright Statement
655 Copyright (C) The IETF Trust (2007).
657 This document is subject to the rights, licenses and restrictions
658 contained in BCP 78, and except as set forth therein, the authors
659 retain all their rights.
661 This document and the information contained herein are provided on an
662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
664 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
665 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
666 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
674 S.Sakane, et al. [Page 12]
676 Internet-Draft April 2007
679 Intellectual Property Statement
681 The IETF takes no position regarding the validity or scope of any
682 Intellectual Property Rights or other rights that might be claimed to
683 pertain to the implementation or use of the technology described in
684 this document or the extent to which any license under such rights
685 might or might not be available; nor does it represent that it has
686 made any independent effort to identify any such rights. Information
687 on the procedures with respect to rights in RFC documents can be
688 found in BCP 78 and BCP 79.
690 Copies of IPR disclosures made to the IETF Secretariat and any
691 assurances of licenses to be made available, or the result of an
692 attempt made to obtain a general license or permission for the use of
693 such proprietary rights by implementers or users of this
694 specification can be obtained from the IETF on-line IPR repository at
695 http://www.ietf.org/ipr.
697 The IETF invites any interested party to bring to its attention any
698 copyrights, patents or patent applications, or other proprietary
699 rights that may cover technology that may be required to implement
700 this standard. Please address the information to the IETF at ietf-
730 S.Sakane, et al. [Page 13]