Reorder configuration file reading.

[shishi.git] / doc / specifications / draft-sakane-krb-cross-problem-statement-00.txt

INTERNET-DRAFT                                                  S.Sakane
Expires: April 16, 2007                                          N.Okabe
                                                              K.Miyazawa
                                                 Yokogawa Electric Corp.
                                                                S.Zrelli
                                                                   JAIST
                                                             M. Ishiyama
                                                           Toshiba Corp.
                                                        October 13, 2006


             Problem statement on the cross-realm operation
                    of Kerberos in a specific system
            draft-sakane-krb-cross-problem-statement-00.txt




Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt

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

   This Internet-Draft expires in April 16, 2007.


Copyright Notice

   Copyright (C) The Internet Society (2006).




S.Sakane, et al.                                                [Page 1]
\f
Internet-Draft                                              October 2006


Abstract

   There are some issues when the cross-realm operation of the Kerberos
   Version 5 [RFC4120] is employed into the specific systems.  This
   document describes some manners of the real example, and lists
   requirements of the operation in such real system.  Then it clarifies
   issues when we apply the cross-realm operation to such specific
   system.



Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   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                                              October 2006


Table of Contents

    1. Introduction .................................................  4
    2. Kerberos system ..............................................  4
       2.1. Kerberos basic operation ................................  4
       2.2. Cross-realm operation ...................................  5
    3. Manner of operations in the real environment .................  6
    4. Requirement ..................................................  7
    5. Issues .......................................................  8
       5.1. Scalability of the direct trust model ...................  8
       5.2. Exposure to DoS Attacks .................................  8
       5.3. No PFS in case of the indirect trust model ..............  9
       5.4. Unreliability of authentication chain ...................  9
       5.5. Client's performance .................................... 10
       5.6. Pre-authentication problem in roaming scenarios ......... 10
    6. Implementation consideration ................................. 10
    7. IANA Considerations .......................................... 11
    8. Security Considerations ...................................... 11
    9. Acknowledgments .............................................. 11
   10. References ................................................... 11
       10.1. Normative References ................................... 11
       10.2. Informative References ................................. 11
   Authors' Addresses ............................................... 12
   Full Copyright Statement ......................................... 13
   Intellectual Property Statement .................................. 13


























S.Sakane, et al.                                                [Page 3]
\f
Internet-Draft                                              October 2006


1.  Introduction

   The Kerberos Version 5 is a widely deployed mechanism that a server
   can authenticate a client access.  Each client belongs to a managed
   domain called realm.  Kerberos supports the authentication in case of
   situation that a client and a server belong to different realms.
   This is called the cross-realm operation.

   Meanwhile, there are lots of manners of operation in the real system,
   where Kerberos could be applied.  Sometimes, there are several
   managed domain in such system.  and it requires the authentication
   mechanism over the different managed domains.  When the cross-realm
   operation of Kerberos is applied to such specific systems, some
   issues come out.

   This document briefly describes the Kerberos Version 5 system and the
   cross-realm operation.  Then, it describes some manners of the real
   system, and describes its requirements in term of management and
   operation in order to understand issues.  Finally, it lists the
   issues of the cross-realm operation.

   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 principals database and shares a secret key with
   each registered principal.

   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



S.Sakane, et al.                                                [Page 4]
\f
Internet-Draft                                              October 2006


   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 the 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 the home realm and the foreign
   realm share keys and have an established trust relationship, the home
   KDC delivers the requested TGT.

   However, if the home realm does not share cross-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 cross-
   realm keys with the target realm.  The client can use this
   '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 cross-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 cross- realm keys with the target realm), the
   intermediary KDC will issue a TGT that can be used with the KDC of
   the target realm.  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



S.Sakane, et al.                                                [Page 5]
\f
Internet-Draft                                              October 2006


   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.  Manner of operations in the real environment

   This section describes examples of operation in the real environment.
   And it also describes its requirement in term of both management and
   operation.  These requirements make the issues easier understanding.
   We refers to the world's largest petrochemical company [SHELLCHEM].
   It produces bulk petrochemicals and their delivery to large
   industrial customers.  There are 43 typical plants of the company all
   over the world.  They are managed by the operation sites placed in 35
   countries.  This section shows two examples of them.

   One is the CSPC (CNOOC and Shell Petrochemical Company Limited)
   [CSPC], an example of the centralized plant.  The CSPC is a joint
   enterprise of CNOOC and SHELL.  Its plant is one of the hugest
   systems of a petrochemical industry placed in the area of 3.4 square
   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.

   Another is the NAM (Nederlandse Aardolie Maatschappij), an example of
   the distributed plant system.  The NAM is a partnership enterprise of
   Shell and Exxon.  It is a plant system group that geographically
   distributes to scatter in the area of 863 square meters 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.

   The end control devices in the both of the systems are basically
   connected to a local network by a twisted pair cable, which is a low



S.Sakane, et al.                                                [Page 6]
\f
Internet-Draft                                              October 2006


   band-width of 32 kbps.  Every system supposes that no ad-hoc device
   is never connected to the system since they are well designed before
   they are implemented.  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.  A part of the operation, like control of these system,
   maintenance, and the environmental monitoring, is consigned to an
   external organization.  Agants who are consigned walk around the
   plant to get their information, or watch the plant from a remote
   site.  Currently, each plant is independently operated.  However, it
   is not impossible to monitor and control all of plants distributed in
   the world.



4.  Requirement

   This section listed requirements derived from the previous section.
   There are seven requirements in term of management domain separation.


   A-1
      It is necessary to allow different independent management domains
      to coexist because two or more organizations enter to the system.

   A-2
      It is necessary to allow a management domain to delegate its
      management authority to its subdomains or another management
      domain because the plants are distributed to the wide area.

   A-3
      It is necessary to observe and to control the device from
      remoteness because the plants are distributed to the wide area.
      Each realm may connect with a private WAN, or with the Internet.

   A-4
      The device must be observed, and be controlled from another
      management domain.

   A-5
      Agents who are consigned must observe and control the device from
      remoteness.

   A-6
      Agents who are consigned must also observe and control the device
      at the plant, which is different domain from the agents' one.





S.Sakane, et al.                                                [Page 7]
\f
Internet-Draft                                              October 2006


   Because of above requirements, the cross-realm operation of Kerberos
   seems suitable for this system.  The requirements derived from other
   viewpoints is listed as follows.


   B-1
      It is demanded to reduce the management cost as much as possible.

   B-2
      The communication for observing and controlling devices must have
      confidentiality and integrity.  And, it is necessary to think
      about the threat of other security like the DoS attack.

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

   B-4
      It is necessary to consider bandwidth of the communication.



5.  Issues

   This section lists the issues when we consider the above
   requirements.


5.1.  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 A-1 and A-2, and is related to B-1.



5.2.  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



S.Sakane, et al.                                                [Page 8]
\f
Internet-Draft                                              October 2006


   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
   becoming target to attacks from remote malicious users increases.

   This issue will happen as a result meeting the requirements A-3, A-4
   and A-5.  And it is related to B-1 and B-2.



5.3.  No PFS in case of the indirect trust model

   In [SPECCROSS], any KDC in the authentication path can learn the
   session key that will be used between the client and the desired
   service.  This means that any intermediary realm is able to spoof the
   identity either of the service or the client as well as to eavesdrop
   on the communication between the client and the server.

   This issue will happen as a by-product of a result meeting the
   requirements A-1 and A-2, and is related to B-2.



5.4.  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.




S.Sakane, et al.                                                [Page 9]
\f
Internet-Draft                                              October 2006


   This issue will happen as a by-product of a result meeting the
   requirements A-1 and A-2, and is related to B-2.



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.

   In some cases where the client has limited computational
   capabilities, which is used in the above process automation system,
   the overhead of these cross-realm exchanges may grow into
   unacceptable delays.  TGS exchange requires cryptographic operations,
   and it demands important processing time especially when small
   devices are used.

   This issue will happen as a by-product of a result meeting the
   requirements A-1 and A-2, and is related to B-3.



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 A-6.



6.  Implementation consideration

   This document just describes issues of the cross-realm operation in
   the specific systems.  However, there are important matters to be
   considered, when we solve these issues and implement solution.
   Solution must not introduce new problem.  Solution should use



S.Sakane, et al.                                               [Page 10]
\f
Internet-Draft                                              October 2006


   existing components or protocols as much as possible, should not
   introduce any definition of new component.  Solution must not require
   a KDC to have any additional process.  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 just clarifies some issues of the cross-realm operation
   of the Kerberos V system.  There is especially not describing
   security.  Some troubles might be caused to your system by malicious
   user who misuses the description of this document if it dares to say.



9.  Acknowledgments



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.



10.2.  Informative References

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


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





S.Sakane, et al.                                               [Page 11]
\f
Internet-Draft                                              October 2006


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


   [RFC2119]     S.Bradner, "Key words for use in RFCs to Indicate
                 Requirement Levels", RFC 2119, March 1997.


   [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
   Nobuo Okabe
   Kazunori Miyazawa
   Yokogawa Electric Corporation
   2-9-32 Nakacho
   Musashino-shi, Tokyo  180-8750
   JAPAN
   E-mail: Shouichi.Sakane@jp.yokogawa.com,
           Nobuo.Okabe@jp.yokogawa.com,
           Kazunori.Miyazawa@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


   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 12]
\f
Internet-Draft                                              October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.












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