s4:torture: Adapt KDC canon test to Heimdal upstream changes

[samba.git] / third_party / heimdal / doc / standardisation / draft-ietf-krb-wg-cross-problem-statement-04.txt

INTERNET-DRAFT                                                 S. Sakane
Intended Status: Informational                           Ken'ichi Kamada
Expires: January 31, 2010                        Yokogawa Electric Corp.
                                                               S. Zrelli
                                                                   JAIST
                                                             M. Ishiyama
                                                           Toshiba Corp.
                                                           July 30, 2009


       Problem statement on the cross-realm operation of Kerberos
            draft-ietf-krb-wg-cross-problem-statement-04.txt




                          Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft expires in January 31, 2010.


Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).



S.Sakane, et al.                                                [Page 1]
\f
Internet-Draft                                                 July 2009


   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


Abstract

   As industrial automation is moving towards wider adoption of Internet
   standards, the Kerberos authentication protocol represents one of the
   best alternatives for ensuring the confidentiality and the integrity
   of communications in control networks while meeting performance and
   security requirements.

   However, the use of Kerberos cross-realm operations in large scale
   industrial systems may introduce issues that could cause performance
   and reliability problems. This document describes some examples of
   actual large scale industrial systems, and lists requirements and
   restriction regarding authentication operations in such environments.
   The document then describes standing issues in the Kerberos cross-
   realm authentication model that should be fixed before Kerberos can
   be adopted in large scale industrial systems.



Conventions used in this document

   It is assumed that the readers are familiar with the terms and
   concepts described in the Kerberos Version 5 [RFC4120].
























S.Sakane, et al.                                                [Page 2]
\f
Internet-Draft                                                 July 2009


Table of Contents

    1. Introduction .................................................  4
    2. Kerberos system ..............................................  4
       2.1. Kerberos basic operation ................................  4
       2.2. Cross-realm operation ...................................  5
    3. Applying Cross-Realm Kerberos in Complex Environments ........  6
    4. Requirements .................................................  7
    5. Issues .......................................................  8
       5.1. Unreliability of authentication chain ...................  8
       5.2. Possibility of MITM in case of the indirect trust model .  9
       5.3. Scalability of the direct trust model ...................  9
       5.4. Exposure to DoS Attacks .................................  9
       5.5. Client's performance .................................... 10
       5.6. Pre-authentication problem in roaming scenarios ......... 10
    6. Implementation consideration ................................. 11
    7. IANA Considerations .......................................... 11
    8. Security Considerations ...................................... 11
    9. Acknowledgments .............................................. 11
   10. References ................................................... 11
       10.1. Normative References ................................... 11
       10.2. Informative References ................................. 12
   Authors' Addresses ............................................... 12




























S.Sakane, et al.                                                [Page 3]
\f
Internet-Draft                                                 July 2009


1.  Introduction

   Kerberos Version 5 is a widely deployed mechanism that enables a
   server to authenticate a client's access.  Each client belongs to a
   managed domain called realm.  Kerberos supports authentication when a
   client and a server belong to different realms.  This is called
   cross-realm operation.

   Meanwhile, there are lots of manners of operation in actual systems,
   where Kerberos could be applied.  Large systems or distributed
   systems are typically split into several managed domains.  For
   example, systems could be split into multiple domains for
   geographical reasons, or to implement different management policies.
   Even in such systems, a common authentication mechanism for the
   different managed domains is required.  When the cross-realm
   operation of Kerberos is applied to such systems, some issues come
   out.

   This document briefly describes the Kerberos Version 5 system and its
   cross-realm mode of operation.  Then, it describes two actual systems
   that Kerberos could be applied to.  and describes seven requirements
   of those systems in term both of management and operation.  Finally,
   it lists six issues of the cross-realm operation when it is applied
   to those system.

   Note that this document might not describe all of the issues of
   cross-realm operation.  New issues might be found in the future.  It
   also does not propose any solution to solve the issues.  Furthermore,
   publication of this document does not mean that each of the issues
   have to be solved by the IETF members.  Hence, in further step, we
   will analyze the issues, define problems and explore the solutions.
   These works will be described in another document.

   This document is assumed that the readers are familiar with the terms
   and concepts described in the Kerberos Version 5 [RFC4120].


2.  Kerberos system


2.1.  Kerberos basic operation

   Kerberos [RFC4120] is a widely deployed authentication system.  The
   authentication process in Kerberos involves principals and a Key
   Distribution Center (KDC).  The principals can be users or services.
   Each KDC maintains a database of principals and shares a secret key
   with each registered principal.




S.Sakane, et al.                                                [Page 4]
\f
Internet-Draft                                                 July 2009


   The authentication process allows a user to acquire the needed
   credentials from the KDC.  These credentials allow services to
   authenticate the users before granting them access to the resources.
   An important part of the credentials are called Tickets.  There are
   two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket.
   The TGT is obtained periodically from the KDC and has a limited limit
   after which it expires and the user must renew it.  The TGT is used
   to obtain the other kind of tickets, Service Tickets.  The user
   obtains a TGT from the Authentication Service (AS), a logical
   component of the KDC.  The process of obtaining a TGT is referred to
   as 'AS exchange'.  When a TGT request is issued by an user, the AS
   responds by sending a reply packet containing the credentials which
   consists of the TGT along with a random key called 'TGS Session Key'.
   The TGT contains a set of information encrypted using a secret key
   associated with a special service referred to as TGS (Ticket Granting
   Service).  The TGS session key is encrypted using the user's key so
   that the user can obtain the TGS session key only if she knows the
   secret key shared with the KDC.  The TGT then is used to obtain
   Service Tickets from the Ticket Granting Service (TGS)- the second
   component of the KDC.  The process of obtaining service tickets is
   referred to as 'TGS exchange'.  The request for a service ticket
   consists on a packet containing a TGT and an 'Authenticator'.  The
   Authenticator is encrypted using the TGS session key and contains the
   identity of the user as well as time stamps (for protection against
   replay attacks).  After decrypting the TGT (which was encrypted by
   the AS using the TGS's secret key), the TGS extracts the TGS session
   key.  Using that session key, it decrypts the Authenticator and
   authenticates the user.  Then, the TGS issues credentials requested
   by the user.  These credentials consist on a service ticket and a
   session key that will be used to authenticate the user with the
   desired application service.


2.2.  Cross-realm operation

   The Kerberos protocol provides cross-realm authentication
   capabilities.  This allows users to obtain service tickets to access
   services in foreign realms.  In order to access such services, the
   users first contact their home KDC asking for a TGT that will be used
   with the TGS of the foreign realm.  If there is a direct trust
   relationship between the home realm and the foreign realm, namely
   both realms share keys (this is called inter-realm keys), the home
   KDC delivers the requested TGT.

   However, if the home realm does not share inter-realm keys with the
   foreign realm the home KDC will provide a TGT that can be used with
   an intermediary foreign realm that is likely to be sharing inter-
   realm keys with the target realm.  The client can use this



S.Sakane, et al.                                                [Page 5]
\f
Internet-Draft                                                 July 2009


   'intermediary TGT' to communicate with the intermediary KDC which
   will iterate the actions taken by the home KDC.  If the intermediary
   KDC does not share inter-realm keys with the target foreign realm it
   will point the user to another intermediary KDC (just as in the first
   exchange between the user and its home KDC).  However, in the other
   case (when it shares inter-realm keys with the target realm), the
   intermediary KDC will issue a TGT that can be used with the KDC of
   the target realm.  This is so-called indirect trust model.  After
   obtaining a TGT for the desired foreign realm, the client uses it to
   obtain service tickets from the TGS of the foreign realm.  Finally,
   the user access the service using the service ticket.

   When the realms belong to the same institution, a chain of trust can
   be determined by the client or the KDC by following the DNS domain
   hierarchy and supposing that the parent domains share keys with all
   its child sub-domains.  However, because the inter-realm trust model
   is not necessarily constructing the hierarchic approach anytime, the
   trust path must be specified manually.  When intermediary realms are
   involved, the success of the cross-realm operation completely depends
   on the realms that are part of the authentication path.


3.  Applying Cross-Realm Kerberos in Complex Environments

   In order to help understanding both requirements and restriction,
   this section describes scale and operation of two actual systems that
   could be supported by cross-realm Kerberos.  The two systems would be
   most naturally implemented using different models, which will imply
   different requirements for cross-realm Kerberos.

   We refer to actual petrochemical enterprise [SHELLCHEM], and show two
   examples among its plants.  The enterprise produces bulk
   petrochemicals and their delivery to large industrial customers.
   There are 43 typical plants of the enterprise all over the world.
   They are managed by the operation sites placed in 35 countries.  This
   section shows two examples of them.

   One is an example of a centralized system [CSPC].  CSPC is operated
   by a joint enterprise of two companies.  This system is one of the
   largest systems of this enterprise in the world.  This is placed in
   the area of 3.4 square kilo meters in the north coast of Daya Bay,
   Guangdong, which is at the southeast of China.  3,000 network
   segments are established in the system.  16,000 control devices are
   connected to the local area network.  These devices belong to
   different 9 sub systems, A control device has some control points,
   which are controlled and monitored by other devices remotely.  There
   are 200,000 control points in all.  They are controlled by 3
   different control center.



S.Sakane, et al.                                                [Page 6]
\f
Internet-Draft                                                 July 2009


   Another example is a distributed system [NAM].  The NAM (Nederlandse
   Aardolie Maatschappij) is operated by a partnership company of two
   enterprises that represent the oil company.  This system is
   constituted by some plants that are geographically distributed within
   the range of 863 square kilometers in the northern part of
   Netherlands.  26 plants, each is named "cluster", are scattered in
   the area.  They are connected each other by a private ATM WAN.  Each
   cluster has approximately 500-1,000 control devices.  These devices
   are managed by each local control center in each cluster.  In the
   entire system of the NAM, there are one million control points.

   In the both of the systems, the end devices are basically connected
   to a local network by a twisted pair cable, which is a low band-width
   of 32 kbps.  Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS-
   M16C], are employed by many control devices.  Furthermore, to
   suppress power consumption, these CPU may be lowered the number of
   clocks.  Because there is a requirement of the explosion-proof.  The
   requirement restricts the amount of total energy in the device.

   A device on the network collects data from other devices which are
   monitoring condition of the system.  The device uses the data to make
   a decision how to control another devices.  And then the device gives
   more than one instruction that controls other devices.  If it took
   time for data to reach, they could not be associated.  The travel
   time of data from the device to the other device is demanded within 1
   second at least.

   A part of the operation, like control of these system, maintenance,
   and the environmental monitoring, is consigned to an external
   organization.  Agents who are consigned walk around the plant to get
   their information, or watch the plant from a remote site.


4.  Requirements

   This section lists the requirements derived from the previous
   section.  R-1, R-2, R-3 and R-4 are related to the management of the
   divided system.  R-5, R-6 and R-7 are related to the restriction to
   such industrial network.


   R-1  It is necessary to partition a management domain into some
        domains.  Or it is necessary to delegate a management authority
        to another independent management domain.

   R-2  It is necessary to allow different independent management
        domains to coexist on the same network because two or more
        organizations need to enter into the system and to management



S.Sakane, et al.                                                [Page 7]
\f
Internet-Draft                                                 July 2009


        it.

   R-3  It is necessary that a device controls other devices that belong
        to a different domain.

   R-4  It is necessary to consider that a device is not always
        geographically or network topologically close to the other
        devices even when the devices belong to a same management
        domain.

   R-5  It is demanded to reduce the management cost as much as
        possible.

   R-6  It is necessary to consider the processing performance of the
        device.  And, it is necessary to suppress the power consumption
        of the device.

   R-7  It is necessary to consider bandwidth of the communication.


5.  Issues

   This section lists the issues in the cross-realm operation when we
   apply the Kerberos version 5 into the system described in the section
   3, and consider the system applied the Kerberos with the requirements
   described in the section 4.


5.1.  Unreliability of authentication chain

   When the relationship of trust is constructed like a chain or
   hierarchical, the authentication path is not dependable since it
   strongly depends on intermediary realms that might not be under the
   same authority.  If any of the realms in the authentication path is
   not available, then the principals of the end-realms can not perform
   the cross-realm operation.

   The end-point realms do not have full control and responsibility of
   the success of the operations even if their respective KDCs are fully
   functional.  Dependability of a system decreases if the system relies
   on uncontrolled components.  We can not be sure at 100% about the
   result of the authentication since we do not know how is it going in
   intermediary realms.

   This issue will happen as a by-product of a result meeting the
   requirements R-1 and R-2.





S.Sakane, et al.                                                [Page 8]
\f
Internet-Draft                                                 July 2009


5.2.  Possibility of MITM in case of the indirect trust model

   Every KDC in the authentication path knows the shared secret between
   the client and the remaining KDCs in the authentication path.  This
   allows a malicious KDC to perform MITM attacks on communications
   between the client and any KDC in the remaining authentication chain.
   A malicious KDC also may learn the service session key that is used
   to protect the communication between the client and the actual
   application service, and performs a MITM attack between them.

   In [SPECCROSS], the authors have analyzed the cross-realm operations
   in Kerberos and provided formal proof of the issue discussed in this
   section.

   This issue will happen as a by-product of a result meeting the
   requirements R-1 and R-2.


5.3.  Scalability of the direct trust model

   In the direct relationship of trust between each realm, the realms
   involved in the cross-realm operation share keys and their respective
   TGS principals are registered in each other's KDC.  When direct trust
   relationships are used, the KDC of each realm must maintain keys with
   all foreign realms.  This can become a cumbersome task when the
   number of realms increase.  This also increases maintenance cost.

   This issue will happen as a by-product of a result meeting the
   requirements R-1, R-2 and R-5.


5.4.  Exposure to DoS Attacks

   One of the assumption made when allowing the cross-realm operation in
   Kerberos is that users can communicate with KDCs located in remote
   realms.  This practice introduces security threats because KDCs are
   open to the public network.  Administrators may think of restricting
   the access to the KDC to the trusted realms only.  However, this
   approach is not scalable and does not really protect the KDC.
   Indeed, when the remote realms have several IP prefixes (e.g. control
   centers or outsourcing companies, located world wide), then the
   administrator of the local KDC must collect the list of prefixes that
   belong to these organization.  The filtering rules must then
   explicitly allow the incoming traffic from any host that belongs to
   one of these prefixes.  This makes the administrator's tasks more
   complicated and prone to human errors.  And also, the maintenance
   cost increases.  On the other hand, when ranges of external IP
   addresses are allowed to communicate with the KDC, the risk of



S.Sakane, et al.                                                [Page 9]
\f
Internet-Draft                                                 July 2009


   becoming target to attacks from remote malicious users increases.

   This issue will happen as a by-product of a result meeting the
   requirements R-3, R-4 and R-5.


5.5.  Client's performance

   In the cross-realm operation, Kerberos clients have to perform TGS
   exchanges with all the KDCs in the trust path, including the home KDC
   and the target KDC.  TGS exchange requires cryptographic operations.
   This exchange demands important processing time especially when the
   client has limited computational capabilities.  The overhead of these
   cross-realm exchanges grows into unacceptable delays.

   We ported the MIT Kerberos library (version 1.2.4), implemented a
   Kerberos client on our original board with H8 (16-bit, 20MHz), and
   measured the process time of each Kerberos message [KRBIMPL].  It
   takes 195 milliseconds to perform a TGS exchange with the on-board
   H/W crypto engine.  Indeed, this result seems reasonable to the
   requirement of the response time for the control network.  However,
   we did not modify the clock speed of the H8 during our measurement.
   The processing time must be slower in a actual environment because H8
   is used with lowered clock speed in such system.  Also, the delays
   can grow to unacceptable delays when the number of intermediary
   realms increases.

   This issue will happen as a by-product of a result meeting the
   requirements R-1, R-2, R-6 and R-7.


5.6.  Pre-authentication problem in roaming scenarios

   In roaming scenarios, the client needs to contact her home KDC to
   obtain a cross-realm TGT for the local (or visited) realm.  However,
   the policy of the network access providers or the gateway in the
   local network usually does not allow clients to communicate with
   hosts in the Internet unless they provide valid authentication
   credentials.  In this manner, the client encounters a chicken-and-egg
   problem where two resources are interdependent; the Internet
   connection is needed to contact the home KDC and for obtaining
   credentials, and on the other hand, the Internet connection is only
   granted for clients who have valid credentials.  As a result, the
   Kerberos protocol can not be used as it is for authenticating roaming
   clients requesting network access.

   This issue will happen as a result meeting the requirements R-3 and
   R-4.



S.Sakane, et al.                                               [Page 10]
\f
Internet-Draft                                                 July 2009


6.  Implementation consideration

   This document just describes issues of the cross-realm operation.
   However, there are important matters to be considered, when we solve
   these issues and implement solution.  Solution must not introduce new
   problem.  It should use existing components or protocols as much as
   possible, and it should not introduce any definition of new
   component.  It should not require new changes to existing deployed
   clients, and it should not influence the client code-base as much as
   possible.  Because a KDC is a significant server of the Kerberos
   system.  New burden should not be introduced into a KDC as much as
   possible.  You must not forget that there would be a trade-off matter
   anytime.  So an implementation may not solve all of the problems
   stated in this document.


7.  IANA Considerations

   This document makes no request of IANA.


8.  Security Considerations

   This document clarifies the issues of the cross-realm operation of
   the Kerberos V system, which include security issues to be
   considered.  See Section 5.1, 5.2, 5.3 and 5.4 for further details.


9.  Acknowledgments

   The authors are grateful to Nobuo Okabe, Kazunori Miyazawa, and
   Atsushi Inoue.  They gave us lots of comments and suggestions to this
   document from the early stage.  Nicolas Williams, Chaskiel Grundman
   and Love Hornquist Astrand gave valuable suggestions and corrections.
   Finally, the authors thank to Jeffrey Hutzelman.  He gave us a lot of
   suggestions for completion of this document.


10.  References


10.1.  Normative References

   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
                 Kerberos Network Authentication Service (V5)", RFC
                 4120, July 2005.





S.Sakane, et al.                                               [Page 11]
\f
Internet-Draft                                                 July 2009


10.2.  Informative References

   [CSPC]        http://www.shellchemicals.com/news/1,1098,72-news_id=
                 531,00.html

   [KRBIMPL]     "A Prototype of a Secure Autonomous Bootstrap Mechanism
                 for Control Networks", Nobuo Okabe, Shoichi Sakane,
                 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki,
                 SAINT, pp. 56-62, IEEE Computer Society, 2006.

   [NAM]         http://www.nam.nl/

   [RNSS-H8]     http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
                 jsp&fp=/products/mpumcu/h8_family/

   [RNSS-M16C]   http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
                 ng.jsp&fp=/products/mpumcu/m16c_family/

   [SHELLCHEM]   http://www.shellchemicals.com/home/1,1098,-1,00.html

   [SPECCROSS]   I. Cervesato and A. Jaggard and A. Scedrov and C.
                 Walstad, "Specifying Kerberos 5 Cross-Realm
                 Authentication", Fifth Workshop on Issues in the Theory
                 of Security, Jan 2005.

Authors' Addresses

   Shoichi Sakane
   Ken'ichi Kamada
   Yokogawa Electric Corporation
   2-9-32 Nakacho, Musashino-shi,
   Tokyo  180-8750 Japan
   E-mail: Shouichi.Sakane@jp.yokogawa.com,
           Ken-ichi.Kamada@jp.yokogawa.com


   Saber Zrelli
   Japan Advanced Institute of Science and Technology
   1-1 Asahidai, Nomi,
   Ishikawa  923-1292 Japan
   E-mail: zrelli@jaist.ac.jp










S.Sakane, et al.                                               [Page 12]
\f
Internet-Draft                                                 July 2009


   Masahiro Ishiyama
   Toshiba Corporation
   1, komukai-toshiba-cho, Saiwai-ku,
   Kawasaki  212-8582 Japan
   E-mail: masahiro@isl.rdc.toshiba.co.jp














































S.Sakane, et al.                                               [Page 13]
\f