Change GPLv2+ to GPLv3+.

[shishi.git] / doc / specifications / draft-kamada-krb-client-friendly-cross-01.txt

Network Working Group                                    Ken'ichi Kamada
INTERNET-DRAFT                                            Shoichi Sakane
Expires: September 6, 2007                 Yokogawa Electric Corporation
                                                           March 5, 2007


            Client-Friendly Cross-Realm Model for Kerberos 5
             draft-kamada-krb-client-friendly-cross-01.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/1id-abstracts.html

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

   This Internet-Draft expires on September 6, 2007.


Copyright Notice

   Copyright (C) The IETF Trust (2007).










Kamada and Sakane                                               [Page 1]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


Abstract

   This document proposes a cross-realm transition model, which is
   friendly to resource-limited clients, for Kerberos Version 5.  This
   model provides a way to move the cost of consecutive Ticket-Granting
   Service (TGS) exchanges from the clients to the Key Distribution
   Center (KDC) and a way to reduce the transition cost by generating a
   direct inter-realm relationship between two realms.  The document
   itself does not specify any protocols, which need to be specified
   separately.


Table of Contents

    1. Introduction .................................................  3
    2. Problems on Client Performance ...............................  3
       2.1. Long Authentication Path ................................  4
       2.2. Client-Centric Ticketing ................................  4
    3. Proposal of Client-Friendly Cross-Realm Model ................  4
       3.1. Temporary Inter-Realm Relationship Generation Mode ......  5
       3.2. Attorney Ticketing Mode .................................  6
       3.3. Combination of the Two Modes ............................  7
    4. Generality and Orthogonality of These Modes ..................  8
    5. Related Protocols Currently Proposed .........................  9
       5.1. PKCROSS .................................................  9
       5.2. XTGS ....................................................  9
    6. Interoperability Considerations ..............................  9
    7. Security Considerations ...................................... 10
       7.1. Denial of Service (DoS) ................................. 10
       7.2. Ticketing Policy ........................................ 10
    8. IANA Considerations .......................................... 11
    9. Acknowledgments .............................................. 11
   10. References ................................................... 11
   Authors' Addresses ............................................... 12
   Full Copyright Statement ......................................... 12
   Intellectual Property Statement .................................. 12















Kamada and Sakane                                               [Page 2]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


1.  Introduction

   Kerberos Version 5 [RFC4120] has a concept of cross-realm
   authentication so that principals in different realms can
   authenticate each other.  However in the current cross-realm model,
   each client has to traverse the authentication path, and the burden
   of the traversal is not negligible for clients with limited
   resources, e.g., computational speed or power supply [CRPS].

   In the current cross-realm operation, a client obtains a service
   ticket for a remote principal in the following steps:

   1)  N TGSes to get cross-realm TGTs in order to traverse the
       intermediate realms, where N is the number of transits, and

   2)  One TGS to get the final service ticket.

   That is, a client needs to perform N + 1 transactions to obtain a
   ticket for a remote service.

   This document proposes a new cross-realm model, which consists of
   "temporary inter-realm relationship generation mode" and "attorney
   ticketing mode".  The former is intended to reduce the transition
   cost itself, and the latter is to move the cost from clients to KDCs.
   The document does not specify any protocols, which need to be
   specified separately.

   Terms defined in section 1.7 of RFC 4120 are used throughout this
   document.


2.  Problems on Client Performance

   In the current model of cross-realm operation, a client has to
   transit all realms on the path to the destination realm.  When the
   source realm and the destination realm have a direct inter-realm
   relationship, a client is able to obtain a service ticket with two
   TGS transactions (one for a cross-realm TGT and another for the
   service ticket).  When the realms have a multi-hop relationship, a
   client must transit the intermediate realm before it obtains the
   service ticket.  That is, the client's task increases in proportion
   to the distance of the relationship.

   Two issues can be observed here behind the client load, which are
   described in the following subsections.






Kamada and Sakane                                               [Page 3]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


2.1.  Long Authentication Path

   When a client wants to get a service ticket for a remote realm, it
   must transit to the remote realm by traversing the intermediate
   realms on the authentication path to the remote realm.  The result of
   a transition is cached as a cross-realm TGT, but it is nothing more
   than a per-client optimization.  Thus all clients accessing a remote
   realm must pay the cost separately, even if their resources are
   limited.  For a long authentication path, the cost of the whole
   system becomes large.


2.2.  Client-Centric Ticketing

   In Kerberos, any service tickets or cross-realm TGTs are issued via
   TGS, where a client present a ticket for the TGS and obtains a next
   ticket.  Currently, all TGS transactions are initiated by the client
   and it needs to get all necessary cross-realm TGTs iteratively before
   the final service ticket.  This process is a burden to a resource-
   limited client.


3.  Proposal of Client-Friendly Cross-Realm Model

   In this section, two modes of operation are introduced, "Temporary
   Inter-Realm Relationship Generation Mode" and "Attorney Ticketing
   Mode", to solve the issues described in the previous section.

   Temporary Inter-Realm Relationship Generation Mode
      This is introduced to solve the issue of the long authentication
      path.  In this mode, if the source realm and the destination realm
      do not have a direct inter-realm relationship, the source KDC
      traverses the authentication path by itself, contacts with the
      remote KDC, and generates a direct inter-realm relationship
      between them.  After that, the source KDC can issue direct inter-
      realm TGTs for the destination realm.  The purpose of this mode is
      to reduce the transition cost itself.

   Attorney Ticketing Mode
      This is introduced to solve the issue of the client-centric
      ticketing.  Consecutive TGS transactions to get cross-realm TGTs
      and/or a final service ticket are initiated by a client in the
      traditional Kerberos, whereas a KDC undertake that process in this
      mode.  The purpose of this mode is to shift the cost of TGSes from
      a client to a KDC.  This does not reduce the cost itself.

   These two modes are designed to be independent, that is, can be used
   separately or in combination.



Kamada and Sakane                                               [Page 4]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


3.1.  Temporary Inter-Realm Relationship Generation Mode

   Temporary inter-realm relationship generation mode enables a KDC to
   issue an inter-realm TGT directly to a remote KDC with which the KDC
   doesn't preshare an inter-realm key.  To issue an inter-realm TGT
   directly, a temporary inter-realm key needs to be provided somehow.
   To achieve that, the local KDC obtains a special ticket for the
   remote KDC and uses its session key as an inter-realm key.  This
   methodology was introduced by PKCROSS [PKCROSS].  In this document,
   that special ticket is called as an "inter-KDC ticket", and an inter-
   realm TGT generated using an inter-KDC ticket as a "direct inter-
   realm TGT".

   How does the local KDC reach the remote KDC is out of scope of this
   model, but we can easily come up with 1) traversing a long
   authentication path if available or 2) using PKINIT.  That is,
   PKCROSS is interpreted as a combination of this model and PKINIT.

   This document does not standardize a specific protocol, but an inter-
   KDC ticket will have the following form:

   -  its sname has a special form (PKCROSS proposes
      "pkcross/realm@REALM", but it would be better to use a more
      general name than "pkcross"),

   and a direct inter-realm TGT will have the following form:

   -  its TicketExtensions field [KRBEXT] contains the inter-KDC ticket,
      and

   -  it is protected by the session key (or the sub-session key) of the
      inter-KDC ticket.



















Kamada and Sakane                                               [Page 5]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


         client C                KDC-L          KDC-I          KDC-R
         --------                -----          -----          -----

      1.    --------TGS-REQ-------->
      2.                           [Reach to KDC-R in any way.]
                                   [Below is an example of PKCROSS.]
                                   ------------PKINIT------------>
                                   <----------XTKT(L,R)-----------
      3.    <--TKT(C,R)w/XTKT(L,R)--
      4.    ----------------------TGS-REQ------------------------>
      5.    <---------------------TKT(C,S)------------------------

      [Note: TKT(x,y) means a ticket whose cname is x and sname is y.  ]
      [      XTKT is an inter-KDC ticket.  See PKCROSS.                ]
      [      The client C and KDC-L belong to the local realm L.       ]
      [      The KDC-I is a KDC of an intermediate realm I.            ]
      [      The KDC-R is a KDC of the remote realm R.                 ]

      1. The client C sends a normal TGS-REQ to KDC-L, requesting
         a cross-realm TGT to KDC-R.
      2. KDC-L reaches KDC-R in any way and obtains a XTKT.
         There is no standardized way to achieve this step yet.
         PKCROSS is one candidate.  We could also standardize a way
         in which KDC-L normally transits to KDC-R and obtains an XTKT.
      3. KDC-L generates a cross-realm TGT that is from C to KDC-R
         and returns to it to C.
      4. The same with the traditional cross-realm TGS.
      5. The same with the traditional cross-realm TGS.

           Figure 1: Message Flow of Temporary Inter-Realm Relationship
                     Generation


3.2.  Attorney Ticketing Mode

   Traditionally, a Kerberos client repeats TGS transactions until it
   gets the final ticket.  For example, it has a TGT for its own realm
   and wants to get a ticket for a service in 3-hop neighbor realm, then
   it will:

   1)  Present the TGT and get a cross-realm TGT for the next realm,

   2)  Present the 1st cross-realm TGT and get a cross-realm TGT for the
       2nd next realm,

   3)  Present the 2nd cross-realm TGT and get a cross-realm TGT for the
       final realm, and




Kamada and Sakane                                               [Page 6]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


   4)  Present the final cross-realm TGT and get a service ticket.

   Attorney ticketing mode enables the client to delegate the KDC to
   perform all transactions listed above on behalf of the client.  An
   example message flow is shown in Figure 2.  The client entrust the
   KDC with its TGT (step 1).  The KDC "impersonates" the client and
   performs all necessary TGS transactions (steps 2 to 4), and returns
   the final ticket to the client (step 5).

         client C                KDC-L          KDC-I          KDC-R
         --------                -----          -----          -----

      1.    --------TGS-REQ-------->
      2.                        TKT(C,I)
      3.                           ----TGS-REQ---->
                                   <---TKT(C,R)----
      4.                           ------------TGS-REQ----------->
                                   <-----------TKT(C,S)-----------
      5.    <-------TKT(C,S)--------

      1. The client C sends a special TGS-REQ, which indicates attorney
         ticketing mode requesting a service ticket for S instead of a
         cross-realm TGT, to KDC-L.
      2. KDC-L internally generates a cross-realm TGT that is from C
         to KDC-I, but does not return it to C.
      3. KDC-L uses the generated cross-realm TGT by itself, and sends
         a TGS-REQ to KDC-I, which requests a cross-realm TGT from C
         to KDC-R.
      4. KDC-L use the obtained cross-realm TGT by itself, and sends
         a TGS-REQ to KDC-R, which requests a service ticket from C
         to S.
      5. KDC-L returns the final service ticket to C.

            Figure 2: Message Flow of Attorney Ticketing Mode


3.3.  Combination of the Two Modes

   Figure 3 shows a typical message flow when the temporary inter-realm
   relationship generation mode and the attorney ticketing mode are used
   in combination.  The figure shows the case of the initial contact, so
   a transaction to obtain an inter-KDC ticket is shown (step 2), but it
   is infrequently used because the XTKT is cached.  Usually, only two
   round-trips do all the work.







Kamada and Sakane                                               [Page 7]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


         client C                KDC-L          KDC-I          KDC-R
         --------                -----          -----          -----

      1.    --------TGS-REQ-------->
      2.                           [Temporary inter-realm relationship
                                   generation mode runs here.]
                                   ------------PKINIT------------>
                                   <----------XTKT(L,R)-----------
      3.                           [Attorney ticketing mode runs here.]
                           TKT(C,R)w/XTKT(L,R)
      4.                           ------------TGS-REQ----------->
                                   <-----------TKT(C,S)-----------
      5.    <-------TKT(C,S)--------

           Figure 3: Message Flow When Temporary Inter-Realm
                     Relationship Generation Mode and Attorney Ticketing
                     Mode Are Combined


4.  Generality and Orthogonality of These Modes

   Compatibility with Traditional Kerberos Deployment

      Temporary inter-realm relationship generation involves only KDCs.
      From the viewpoint of a client (and a server), it seems that there
      is a direct inter-realm relationship between two realms.

      In short, temporary inter-realm relationship generation mode needs
      to be deployed only in KDCs.  The merit of this property is large,
      because it does not affect large installed base of clients.

      Attorney ticketing mode involves only a client and the local KDC.
      From the viewpoint of the remote KDC, TGS-REQs from a KDC as an
      attorney cannot be distinguished from those from a "genuine"
      client (except caddr; see the Interoperability Considerations
      section).  Resulting service ticket is identical to the
      traditional one, so the remote server has nothing to do this mode.

      In short, attorney ticketing mode can be deployed in local realm,
      independently of the remote deployment.  The merit of this
      property is large, because remote realms are often in different
      administration.

   Orthogonality of Temporary Inter-Realm Relationship Generation Mode
   and Attorney Ticketing Mode

      Temporary inter-realm relationship generation mode and attorney
      ticketing mode are independent concepts.  Both can be implemented



Kamada and Sakane                                               [Page 8]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


      separately or can be used in combination.  When they are combined,
      the load of clients are shifted to KDCs and additional load of
      KDCs are minimized, thus efficient cross-realm environment is
      achieved.


5.  Related Protocols Currently Proposed


5.1.  PKCROSS

   PKCROSS will be usable as a protocol for temporary inter-realm
   relationship generation mode.


5.2.  XTGS

   The purpose of XTGS protocol is similar to that of this model, but
   the behavior is somewhat different [XTGS].  If XTGS is viewed from
   the perspective of this model, it blends the two modes indivisibly to
   reduce the number of messages between KDCs as far as possible at the
   price of the abstraction of cross-realm TGTs and inter-KDC tickets.

   Once a front-end (i.e., between a client and a KDC) protocol to
   request attorney ticketing mode is standardized, XTGS can be used as
   an opaque back-end.


6.  Interoperability Considerations

   User-to-user mode
      The protocol for the attorney mode should be able to indicate
      user-to-user authentication.

   The addresses field in TGS-REQ
      This field is copied into the caddr field in EncTicketPart, so if
      this field is used in a TGS-REQ, the resulting ticket can be used
      only from the specified addresses.  When the local KDC receives a
      TGS-REQ requesting attorney mode, it should copy the addresses
      field only into the final TGS-REQ in the attorney process.  It
      must not copy the field into TGS-REQs to intermediate KDCs,
      because resulting tickets are to be used by the local KDC instead
      of the client.

   [[negotiation of various parameters]]

   [[If there are multiple authentication paths and a client has enough
   knowledge, it could choose which path to take.  With attorney



Kamada and Sakane                                               [Page 9]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


   ticketing mode, it cannot because it is up to the KDC to select the
   path.  Is this a problem?  With temporary inter-realm relationship
   generation mode, it can as before.]]

   [[co-existence with the plain Kerberos; attorney ticketing mode
   client vs. non-attorney KDC; inter-realm generating local KDC vs.
   non-generating remote KDC]]

   [[anything to do with referral?]]

   [[when a KDC in attorney mode receives a KRB-ERROR?]]


7.  Security Considerations


7.1.  Denial of Service (DoS)

   A KDC that implements attorney ticketing mode needs to initiate
   multiple TGS-REQ upon a request from a client.  This means that the
   KDC will have some states in it and may suffer from DoS attacks.

   Fortunately, attorney ticketing mode can be requested in TGS-REQ,
   which is only available to authenticated clients, thus, any untrusted
   party cannot exploit this statefulness.


7.2.  Ticketing Policy

   Attorney ticketing mode changes nothing about the messages sent to
   the intermediate and remote KDCs.  Those KDCs will not notice the
   difference and their ticketing process have nothing to be changed.

   Temporary inter-realm relationship generation mode dynamically
   generates new authentication paths.  This means that KDCs that will
   be involved in the transition of a client will be different ones.

   -  Parameters of cross-realm TGTs (lifetime and flags) for a new
      relationship need to be dynamically negotiated (a la PKCROSS).

   -  How to handle the transited fields in inter-KDC tickets, direct
      inter-realm tickets, and service tickets?

   -  Where the remote KDC adds AuthorizationData and the end-server
      checks it: there is no problem because it is a local matter of the
      remote realm.





Kamada and Sakane                                              [Page 10]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


   -  Where an intermediate KDC adds AuthorizationData: traditionally it
      is added in a cross-realm TGT and propagated to the service
      ticket; now it will be propagated to the inter-KDC ticket.  Should
      AuthorizationData in an inter-KDC ticket be copied into a cross-
      realm TGT or not?  Even if it is copied, AuthorizationData on
      inter-KDC ticket cannot represent per-client information, so if it
      is necessary, temporary inter-realm relationship generation mode
      must not be used.


8.  IANA Considerations

   This document has no actions for IANA.


9.  Acknowledgments

   The authors would like to acknowledge Saber Zrelli, Masahiro
   Ishiyama, Atsushi Inoue, Kazunori Miyazawa, and Nobuo Okabe for
   contributions to this document.


10.  References

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

   [CRPS]        Sakane, S., Zrelli, S., M. Ishiyama, "Problem statement
                 on the cross-realm operation of Kerberos in a specific
                 system", draft-sakane-krb-cross-problem-statement-01,
                 Work in Progress, October 2006.

   [KRBEXT]      Yu, T., "The Kerberos Network Authentication Service
                 (Version 5)", draft-ietf-krb-wg-rfc1510ter-03, Work in
                 Progress, October 2006.

   [PKCROSS]     Hur, M. et al., "Public Key Cryptography for Cross-
                 Realm Authentication in Kerberos", draft-ietf-cat-
                 kerberos-pk-cross-08 (expired), Work in Progress,
                 November 2001.

   [XTGS]        Zrelli, S. et al., "XTGSP, the Inter-TGS protocol for
                 cross-realm operations in Kerberos", draft-zrelli-krb-
                 xtgsp-00, Work in Progress, November 2006.






Kamada and Sakane                                              [Page 11]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


Authors' Addresses

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


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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



Kamada and Sakane                                              [Page 12]
\f
Internet-Draft         Client-Friendly Cross-Realm            March 2007


   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

















































Kamada and Sakane                                              [Page 13]
\f