[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          S. Zrelli
Internet-Draft                                                Y. Shinoda
Expires: December 19, 2006                                         JAIST
                                                               S. Sakane
                                                               K. Kamada
                                                 Yokogawa Electric Corp.
                                                             M. Ishiyama
                                                           Toshiba Corp.
                                                           June 17, 2006


 XKDCP, the Inter-KDC protocol for cross-realm operations in Kerberos.
                       draft-zrelli-krb-xkdcp-00

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 will expire on December 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo proposes protocol extensions to the Kerberos protocol
   specification.  The extension (hereafter called XKDCP) offers a new
   cross-realm protocol for Kerberos.  The XKDCP extension defines a



Zrelli, et al.          Expires December 19, 2006               [Page 1]


Internet-Draft                    XKDCP                        June 2006


   protocol between Kerberos Key Distribution Centers (KDCs) that allows
   a KDC to build credentials even when the client or the requested
   service is not registered in the KDC's database (but registered in
   another KDC's database).  The XKDCP extension defines two protocols:
   XTGSP (Inter Ticket Granting Service Protocol) and XASP (Inter
   Authentication Service Protocol).  The XTGSP protocol can be used in
   remote access scenarios to allow the local KDC to deliver credentials
   for services located in remote realms.  On the other hand, the XASP
   protocol can be used in case of cross-realm roaming scenarios to
   allow the visited KDC to deliver credentials for roaming users.









































Zrelli, et al.          Expires December 19, 2006               [Page 2]


Internet-Draft                    XKDCP                        June 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Kerberos basic operations  . . . . . . . . . . . . . . . .  4
     1.2   Kerberos cross-realm operations  . . . . . . . . . . . . .  6
     1.3   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  8
     1.4   Overview of the extension  . . . . . . . . . . . . . . . .  9
   2.  Motivations  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     2.1   Inter realm trust model  . . . . . . . . . . . . . . . . . 11
     2.2   Exposure of the KDC  . . . . . . . . . . . . . . . . . . . 12
     2.3   Client centralized exchanges . . . . . . . . . . . . . . . 12
     2.4   Pre-authentication problem in roaming scenarios  . . . . . 12
   3.  XKDCP: the cross-realm authentication protocol . . . . . . . . 13
     3.1   Introduction . . . . . . . . . . . . . . . . . . . . . . . 13
     3.2   Overview of the XTGSP extension  . . . . . . . . . . . . . 13
     3.3   Overview of the XASP extension . . . . . . . . . . . . . . 17
     3.4   The XKDCP padata . . . . . . . . . . . . . . . . . . . . . 20
     3.5   XTGSP protocol details . . . . . . . . . . . . . . . . . . 23
       3.5.1   The KRB_TGS_REQ message  . . . . . . . . . . . . . . . 23
       3.5.2   The XTGSP-REQ message  . . . . . . . . . . . . . . . . 24
       3.5.3   The XTGSP-REP message  . . . . . . . . . . . . . . . . 25
       3.5.4   The KRB_TGS_REP message  . . . . . . . . . . . . . . . 27
     3.6   The XASP protocol details  . . . . . . . . . . . . . . . . 29
       3.6.1   The KRB_AS_REQ message . . . . . . . . . . . . . . . . 29
       3.6.2   The XASP-REQ message . . . . . . . . . . . . . . . . . 29
       3.6.3   The XASP-REP message . . . . . . . . . . . . . . . . . 31
       3.6.4   The KRB_AS_REP message . . . . . . . . . . . . . . . . 33
     3.7   Realm policy . . . . . . . . . . . . . . . . . . . . . . . 35
   4.  Constants  . . . . . . . . . . . . . . . . . . . . . . . . . . 37
     4.1   XKDCP error codes  . . . . . . . . . . . . . . . . . . . . 37
     4.2   XKDCP message types  . . . . . . . . . . . . . . . . . . . 37
   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 38
     5.1   Integrity protection . . . . . . . . . . . . . . . . . . . 38
     5.2   Confidentiality  . . . . . . . . . . . . . . . . . . . . . 38
     5.3   DoS and replay protection  . . . . . . . . . . . . . . . . 38
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 39
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 39
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
   A.  ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . 41
       Intellectual Property and Copyright Statements . . . . . . . . 44











Zrelli, et al.          Expires December 19, 2006               [Page 3]


Internet-Draft                    XKDCP                        June 2006


1.  Introduction

1.1  Kerberos basic operations

   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
   (ST).  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 the 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 some
   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.  Finally, the
   TGS issues the credentials requested by the user, these credentials
   consists on a service ticket and a session key that will be used to
   authenticate the user with the desired application service.

   Figure 1 shows the different exchanges between the client, the KDC
   and the service.







Zrelli, et al.          Expires December 19, 2006               [Page 4]


Internet-Draft                    XKDCP                        June 2006


                                                      KDC
                         +-------------------------------+   +---------+
   Client                |    AS                   TGS   |   |   SVC   |
   |                     +----+--------------------+-----+   +----+----+
   |                          |                    |              |
   |     KRB_AS_REQ [1]       |                    |              |
   | -----------------------> |                    |              |
   |                          |                    |              |
   |     KRB_AS_REP [2]       |                    |              |
   | <----------------------- |                    |              |
   |                          |                    |              |
   |                   KRB_TGS_REQ  [3]            |              |
   | --------------------------------------------> |              |
   |                          |                    |              |
   |                   KRB_TGS_REP  [4]            |              |
   | <-------------------------------------------- |              |
   |                          |                    |              |
   |                          |                    |              |
   |                          |                    |              |
   |                             KRB_AP_REQ   [5]                 |
   | -----------------------------------------------------------> |
   |                          |                    |              |
   |                             KRB_AP_REP   [6]                 |
   | <----------------------------------------------------------- |
   |                          |                    |              |
   |                          |                    |              |

























Zrelli, et al.          Expires December 19, 2006               [Page 5]


Internet-Draft                    XKDCP                        June 2006


   [1] Client -> AS     : Client_ID, Nonce1

   [2] AS     -> Client : [Client_ID, TimeStamp1, TGS_SK]_TGS_K,
                          [Nonce1, TGS_SK]_Client_K

   [3] Client -> TGS    : [Client_ID, TimeStamp1, TGS_SK]_TGS_K,
                          [Client_ID, TimeStamp2]_TGS_SK,
                          SVC_ID, Nonce2

   [4] TGS    -> Client : [Client_ID, TimeStamp3, SK]_SVC_K,
                          [Nonce2, SK]_TGS_SK

   [5] Client -> SVC    : [Client_ID, TimeStamp3, SK]_SVC_K,
                          [Client_ID, TimeStamp4]_SK,

   [6] SVC    -> Client : [Client_ID, TimeStamp4]_SK


   Notation :
   ----------

   Client_ID : Principal name of the client
   [A]_x     : Content A is encrypted using secret key x
   A_K       : Secret key of principal A
   TGS_SK    : TGS session key
   SK        : Session key
   SVC       : An application service
   SVC_ID    : Principal name of the application service


                 Figure 1: The Kerberos Protocol exchanges

   For more details about the different exchanges and the exact message
   specifications, refer to [RFC4120].

1.2  Kerberos cross-realm operations

   The Kerberos protocol offers cross-realm authentication capabilities.
   This allows users to obtain service tickets to access resources 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 (message 1 of Figure 2).  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-



Zrelli, et al.          Expires December 19, 2006               [Page 6]


Internet-Draft                    XKDCP                        June 2006


   realm keys with the target realm (message 2 of Figure 2).  The client
   can use this 'intermediary TGT' to communicate with the intermediary
   KDC (message 3 of Figure 2) 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 (message 4 of
   Figure 2).

   After obtaining a TGT for the desired foreign realm, the client uses
   it to obtain service tickets from the TGS of the foreign realm
   (messages 5 and 6 of Figure 2).  Finally the user authenticates to
   the service using the service ticket.



   Figure 2 shows the exchanges between the different entities involved
   in a cross-realm authentication aiming at delivering a service ticket
   to a client when the service is deployed in a foreign realm.






























Zrelli, et al.          Expires December 19, 2006               [Page 7]


Internet-Draft                    XKDCP                        June 2006


                                +-------+
                                |       |
                    ST-SRV?  5  | KDC-T | 6  ST-SRV
          +-------------------->|       |---------------------+
          |                     +-------+                     |
          |                                                   |
          |                     +-------+                     |
          |         TGT-T?   3  |       | 4  TGT-T            |
          |      +------------->| KDC-I |--------------+      |
          |      |              |       |              |      |
          |      |              +-------+              |      |
          |      |                                     |      |
          |      |              +-------+              |      |
          |      |  TGT-T?   1  |       | 2  TGT-I     |      |
          |      |      +------>| KDC-H |-------+      |      |
          |      |      |       |       |       |      |      |
          |      |      |       +-------+       |      |      |
          |      |      |                       |      |      |
          |      |      |                       |      |      |
          |      |      +------ +--------+ <----+      |      |
          |      +------------- | Client | <-----------+      |
          +-------------------- +--------+ <------------------+






   H      : Home realm
   I      : Intermediary realm
   T      : Target realm
   KDC-X  : KDC of realm X (where X in {H,I,T})
   TGT-X ?: A KRB_TGS_REQ requesting a TGT for realm X
   ST-SRV?: A KRB_TGS_REQ requesting a service ticket for service SRV
   TGT-X  : A KRB_TGS_REP that contains a a TGT for realm X
   ST-SRV : A KRB_TGS_REP that contains a service ticket for service SRV

   Figure 2: The Kerberos Protocol exchanges for cross-realm operations


1.3  Terminology

   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 [RFC2119].

   The following terms are used in this document :




Zrelli, et al.          Expires December 19, 2006               [Page 8]


Internet-Draft                    XKDCP                        June 2006


   Local realm : The realm where the client is physically (or
      topologically) located.  The client can be a registered user or
      principal in the local realm or she can be a visitor in the local
      realm.

   Remote realm : A realm that is different from the local realm.

   Home realm : The realm where the client is registered as a Kerberos
      principal.

   Foreign realm : A realm that is different from the home realm.

   Roaming client/user : A user that is being physically (or
      topologically) located in a realm that is not her home realm.

   Visited realm : When a client is in a roaming situation, the realm
      where she is located is referred to as the visited realm.  The
      visited realm is considered as a local realm from the client's
      point of view.

   TGS session key : The session key that is shared between the TGS and
      the client.  This session key corresponds to the field 'key' of
      the EncASRepPart in the TGS-REP message.

   Service session key : The session key that is shared between the
      service and the client.  This session key corresponds to the field
      'key' of the EncTGSRepPart in the AS-REP message.

   TGS : The KDC is logically divided into two main services, one of
      these services is the TGS (Ticket Granting Service), the TGS
      provides service tickets to clients with valid TGTs

   AS : The authentication service (AS), is the part of the KDC that
      authenticates clients and delivers TGTs.


1.4  Overview of the extension

   The extension described in this document augments the specification
   of the Kerberos protocol as follows :

   o  Extension of the TGS exchange :

      *  Clients can issue KRB_TGS_REQ [RFC4120] messages to any KDC for
         which they have a valid TGT.

      *  When a KRB_TGS_REQ message can not be processed by the TGS
         because the requested service is registered in a different



Zrelli, et al.          Expires December 19, 2006               [Page 9]


Internet-Draft                    XKDCP                        June 2006


         realm, then the TGS issues a message to the TGS of the remote
         realm (where the service is registered) requesting a service
         ticket and the associated service session key, on behalf of the
         client.  The communication between the two KDCs is protected
         using public key cryptography.

   o  Extension of the AS exchange :

      *  Clients can issue KRB_AS_REQ [RFC4120] messages to any KDC in
         order to a obtain TGT for that KDC.

      *  when a client issues a KRB_AS_REQ message [RFC4120] to a KDC
         where she is not registered, the foreign KDC identifies the
         client's home realm and initiates an exchange with client's
         home KDC.  The result of this exchange is that the foreign KDC
         has all the required information to build the KRB_AS_REP
         message [RFC4120] and send it to the client.  This exchange
         between the two KDCs is protected and authenticated using the
         public-keys of both KDCs.
































Zrelli, et al.          Expires December 19, 2006              [Page 10]


Internet-Draft                    XKDCP                        June 2006


2.  Motivations

   This document defines an alternative to Kerberos cross-realm
   operations as specified in [RFC4120].  The protocol, here after
   called XKDCP, defines exchanges between KDCs when cross-realm
   operations are involved.  The motivations behind this extension are
   to fulfill new needs and enhance the cross-realm operations in
   general.

   There are several aspects in the Kerberos-cross realm operations that
   can benefit from enhancement.  In certain cases, the semantic of the
   current cross-realm protocol introduces security risks, in other
   cases, the Kerberos protocol can not be used at all.  The following
   sections list the aspects where the Kerberos cross-realm protocol can
   be enhanced.  The actual extension defined in this document aims at
   resolving all these issues.

2.1  Inter realm trust model

   Kerberos offers cross-realm authentication that allows users to
   access services managed by foreign realms.  The cross-realm
   operations assumes that realms have a direct or indirect trust
   relationships.

   A direct trust relationship means that the realms involved in the
   cross-realm authentication 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.  Therefore, cross-realm authentication
   based on indirect trust relationships, offer better scalability.

   Indirect trust relationship means that there is a 'chain of trust'
   linking the two realms.  This can be performed by having a common
   trusted realm or a chain of intermediary trusted realms.

   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, when the inter-realm trust model
   does not follow the hierarchic approach, the trust path must be
   specified manually.

   When intermediary realms are involved, the success of the cross-realm
   authentication completely depends on the realms that are part of the
   authentication path.  If any of the realms in the authentication path
   is not available, then the principals of the end-realms can not
   perform cross-realm operations.  Moreover, as described in [CJSW05]



Zrelli, et al.          Expires December 19, 2006              [Page 11]


Internet-Draft                    XKDCP                        June 2006


   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 identify of the
   service and the client as well as to eavesdrop on the communication
   between the client and the server.

2.2  Exposure of the KDC

   One of the assumption made when allowing cross-realm operations 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.  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. a company with
   offices located world wide), then the administrator of the local KDC
   must collect the list of prefixes that belong to this company.  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.  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.

2.3  Client centralized exchanges

   In the cross-realm operations, 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, the overhead of these cross-realm
   exchanges may grow into unacceptable delays.  Furthermore, if the
   number or intermediary realms increases, the delay introduced by the
   cross-realm messages can result in unacceptable delays.

2.4  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 usually does not allow
   clients to communicate with hosts in the Internet unless they provide
   valid authentication credentials.  In this manner, the client falls
   in a deadlock situation where two resources are inter-dependent; 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.




Zrelli, et al.          Expires December 19, 2006              [Page 12]


Internet-Draft                    XKDCP                        June 2006


3.  XKDCP: the cross-realm authentication protocol

3.1  Introduction

   In the standard Kerberos specification, when a client wishes to
   obtain credentials for a certain service, she must issue a request
   for a service ticket to the KDC where the service is registered.  The
   XKDCP extension allows the client to obtain the service ticket from
   any KDC for which she already has a TGT.

   On the other hand, the XKDCP extension allows a client to obtain a
   TGT for any KDC after only one AS exchange with the target KDC.

   XKDCP extends the Kerberos protocol [RFC4120] by adding two exchanges
   called XASP and XTGSP.

   o  XTGSP (Inter-TGS Protocol) : When a TGS can not process a request
      for a service ticket because the service's realm is different from
      the TGS's realm, then the XTGSP protocol can be used between the
      TGS of both realms to build the desired service ticket.  When
      XTGSP is used, the client does not need to communicate with the
      KDC in which the service is registered.  The TGSs for which the
      client has already obtained a TGT is capable of delivering the
      service ticket after using the XTGSP protocol with the remote TGS.

   o  XASP (Inter-AS Protocol) : When an AS can not process a client
      request (a KRB_AS_REQ message) because the client does not belong
      to the local realm, the XASP extension can be used between the
      visited AS and the home AS to build the required credentials (a
      TGT) for the roaming client.

   XASP and XTGSP extend the Kerberos messages by exploiting the pre-
   authentication data field 'padata' in the KRB_KDC_REQ and KRB_KDC_REP
   messages [RFC4120].  The 'padata' field is used as a typed hole and
   employed to convey information related to the XKDCP protocol.  The
   specification of the new padata type is detailed in Section 3.4.  The
   details of the XASP and the XTGSP protocols can be found in
   Section 3.6 and Section 3.5 respectively.

3.2  Overview of the XTGSP extension

   XTGSP allows users to obtain service tickets from a KDC even if the
   service is not registered in that KDC.

   The typical use of XTGSP is in remote access scenarios where a user
   has a TGT for a local KDC and wishes to access a service deployed in
   a remote realm.  The advantage of using the XTGSP protocol is that
   the client does not need to have a cross-realm TGT for the target



Zrelli, et al.          Expires December 19, 2006              [Page 13]


Internet-Draft                    XKDCP                        June 2006


   realm deploying the service.  Moreover, the client does not need to
   contact the remote KDC at all since the local KDC will deliver the
   service ticket that can be used directly to authenticate with the
   remote service.  In fact, from the client's point of view, the local
   KDC delivers the service ticket as if the remote service was
   registered in the local realm.  The cross-realm operations are
   managed by the local KDC and made transparent to the client.  The
   local KDC uses the XTGSP protocol with the KDC of the realm where the
   service is registered.  As a result of the XTGSP exchange, the local
   KDC acquires enough materials to be able to deliver the requested
   service ticket to the client.

   Figure 3 represents the different exchanges in a cross-realm
   operation, based on the XTGSP protocol, for delivering service ticket
   to a client.



                                     |
                                     |
                                     |

        +-------+              (2) XTGSP-REQ         +-------+
        |       |<-----------------------------------|       |
        | TGS-R |              XTGSP-REP (3)         | TGS-L |
        |       |----------------------------------->|       |
        +-------+                    |               +-------+
                                     |                  ^  |
                                     |                  |  |
                      +-------+      |               (1)|  |(4)
                      | SRV-R |      |      KRB_TGS_REQ |  | KRB_TGS_REP
                      +-------+      |                  |  |
                                     |                  |  v
                                     |                +------+
                                     |                |Client|
                                     |                +------+
                                     |
           Remote Realm (R)          |       Local Realm (L)













Zrelli, et al.          Expires December 19, 2006              [Page 14]


Internet-Draft                    XKDCP                        June 2006


   client         : A client that has a TGT for the local realm L
   TGS-L          : The TGS of the local realm L
   TGS-R          : The TGS of the remote realm R
   SRV-R          : A service registered in the remote realm R
   KRB_TGS_REQ    : A message requesting service ticket for the
                    remote service SRV-R
   KRB_TGS_REP    : A message containing a service ticket for
                    the servie SRV-R

                     Figure 3: The Inter-TGS protocol

   In the following, we assume that the client has already obtained a
   TGT that can be used with the TGS of the local realm (TGS-L).

   1.  Client -> TGS-L : KRB_TGS_REQ

       The client sends a KRB_TGS_REQ [RFC4120] to the local TGS asking
       for credentials required to access a certain remote service
       (SRV-R).

       The KRB_TGS_REQ message is built as specified in [RFC4120].  Note
       that the 'realm' field MUST be set to the realm name of the
       desired service.  In the scenario of Figure 3 the client MUST put
       the realm name 'R' in the 'realm' field of the KRB_TGS_REQ
       message.


   2.  TGS-L -> TGS-R : XTGSP-REQ

       TGS-L extracts the service's realm name from the field 'realm' of
       the client's request.  If the extracted realm name does not match
       with the local realm name, then TGS-L MUST use the XTGSP
       extension with the TGS of the remote realm (TGS-R).

       The goal of the XTGSP protocol is to enable the local KDC (TGS-L)
       to build a valid KRB_TGS_REP [RFC4120] in response to a
       KRB_TGS_REQ for a service that is not registered in the local
       realm.  TGS-L basically needs to build or have an EncTicketPart
       [RFC4120] as well as the session key associated with it.  The
       EncTicketPart is a component of the ticket included in the
       KRB_TGS_REP message, it must be encrypted using the secret key of
       the remote service (shared with the remote TGS only).  Since the
       only entity capable of building the EncTicketPart is the remote
       TGS (TGS-R), there is need for a protocol to request TGS-R to
       build the EncTicketPart component and to communicated it along
       with the associated service session key to TGS-L in a secure
       manner.  XTGSP was designed to fulfill this task.




Zrelli, et al.          Expires December 19, 2006              [Page 15]


Internet-Draft                    XKDCP                        June 2006


       The XTGSP-REQ message contains all the necessary information to
       enable TGS-R to build an EncTicketPart and to transmit it along
       with the associated session key ,in a secure manner, to TGS-L.
       The XTGSP-REQ message is built from the client's original
       KRB_TGS_REQ message (which contains all information about the
       requested credentials).  The XTGSP-REQ message is in fact a copy
       of the client's request extended using the 'padata' field.  The
       'padata' field defined by the XKDCP extension includes
       information for cross-realm operations as well as materials that
       will allow the KDCs to authenticate each others and to protect
       the XTGSP exchange.  For this purpose, public key cryptography
       (based on a pre-existent PKI) is used between the two KDCs.  The
       padata field of the XTGSP-REQ includes a signature [RFC3852] and
       the certificate of TGS-L.  The process of building the XTGSP-REQ
       message and the associated 'padata' field is detailed in
       Section 3.5.2.


   3.  TGS-R -> TGS-L : XTGSP-REP

       When TGS-R receives a TGS-REQ message, it authenticates TGS-L and
       validates the request by verifying the certificate and the
       signature embedded in the padata field.  Then, TGS-R creates a
       service session key and builds an EncTicketPart.  The
       EncTicketPart is created as specified in [RFC4120].  TGS-R gets
       all the information needed to build the EncTicketPart from the
       XTGSP-REQ message.  The EncTicketPart is encrypted using the
       secret key of the service (SRV-R).  A copy of the generated
       session key (included in the EncTicketPart) is encrypted using
       the public key of TGS-L.  The encrypted EncTicketPart and the
       encrypted service session key are conveyed to TGS-L using the
       padata field of the XTGSP-REP message.  The XTGSP-REP message is
       a KRB_TGS_REP message extended using the padata field.  The
       padata field includes materials for authenticating TGS-R to TGS-L
       and for verifying the integrity of the message.  The XTGSP-REP
       message will be used by TGS-L to build a valid KRB_TGS_REP.  More
       details on how to build the XTGSP-REP message are in
       Section 3.5.3.


   4.  TGS-L -> Client : KRB_TGS_REP

       When TGS-L recieves a XTGSP-REP message, it authenticates TGS-R
       and validates the message by verifying the certificate and the
       signature embedded in the padata field.

       After receiving the XTGSP-REP message, TGS-L is able to build the
       credentials requested by the client.  For that, TGS-L will



Zrelli, et al.          Expires December 19, 2006              [Page 16]


Internet-Draft                    XKDCP                        June 2006


       decrypt the service session key using its private key.  The
       EncTicketPart will be used to build a service ticket.  The
       session key will be sent to the client along with the service
       ticket in a KRB_TGS_REP message.  The KRB_TGS_REP message has the
       same format as specified in [RFC4120].  More details about this
       phase of the protocol are in Section 3.5.4.

       The client processes the KRB_TGS_REP message exactly as specified
       in [RFC4120].  She can use the service session key and the
       service ticket to issue a KRB_AP_REQ to the remote service.  The
       mutual authentication between the client and the remote service
       occurs as specified in [RFC4120].



3.3  Overview of the XASP extension

   In situations where the home KDC (or the KDC for which the client has
   a TGT) is not reachable or when the client has a limited network
   connectivity in a visited network, neither the standard Kerberos
   protocol nor the XTGSP protocol can be used to obtain tickets.  In
   such circumstances, the client has no other alternatives but using
   previously acquired credentials (as long as they are still valid) or
   contact an entity in the visited network in order to acquire new
   credentials.

   XASP is an extension to the Kerberos protocol that complements the
   XTGSP protocol.  It allows two Kerberos authentication services (that
   may be belong to two distinct realms) to collaborate in order to
   authenticate a roaming user and to deliver a TGT usable in the
   visited realm.

   When assuming that the KDC of the visited realm and the home KDC both
   support the XKDCP extension, the client behaves as if the visited KDC
   is capable of delivering a TGT even if she knows that she is not
   registered as principal in the visited realm.  When the visited KDC
   supports the XASP extension it processes KRB_AS_REQ requests from
   users belonging to different realms.  The processing of these
   requests is specified by the XASP extension.

   Figure 4 depicts the different exchanges between the different
   entities involved in a cross-realm operation based on XASP for
   delivering a TGT to a roaming user.








Zrelli, et al.          Expires December 19, 2006              [Page 17]


Internet-Draft                    XKDCP                        June 2006


                                        |
                                        |
                                        |

           +-------+              (2) XASP-REQ          +-------+
           |       |----------------------------------->|       |
           | AS-V  |              XASP-REP (3)          | AS-H  |
           |       |<-----------------------------------|       |
           +-------+                    |               +-------+
              ^  |                      |
              |  |                      |
           (1)|  |(4)                   |
   KRB_AS_REQ |  | KRB_AS_REP           |
              |  |                      |
              |  v                      |
            +------+                    |
            |Client|                    |
            +------+                    |
                                        |
              Visited Realm (V)         |       Home Realm (H)





   client         : A roaming client registered in realm H
   AS-V           : The AS of the visited realm V
   AS-H           : The AS of the home realm H
   KRB_AS_REQ     : A message requesting a TGT for
                    the visited realm V
   KRB_AS_REP     : A message containing a TGT for
                    the visited realm V


                      Figure 4: The Inter-AS protocol

   The following is a description of the different exchanges shown in
   Figure 4.

   1.  Client -> AS-V : KRB_AS_REQ

       The roaming client requests a TGT from the visited KDC.  This
       request is a KRB_AS_REQ as specified in [RFC4120].  The XASP
       protocol mandates that the client MUST put her home realm name in
       the 'realm' field of the request.  Furthermore, the 'sname' field
       of the KRB_AS_REQ MUST contain the principal name of the TGS of
       the visited realm.  The name of the TGS indicates the visited
       realm name as the realm issuing the TGT and the realm that will



Zrelli, et al.          Expires December 19, 2006              [Page 18]


Internet-Draft                    XKDCP                        June 2006


       accept the TGT.


   2.  AS-V -> AS-H : XASP-REQ

       When AS-V receives a KRB_AS_REQ message, it extracts the client's
       home realm name from the 'realm' field.  If the extracted realm
       name matches the local realm name, then the request is processed
       as specified in [RFC4120].  In the opposite case (when the
       client's realm name is different from the local realm name), AS-V
       determines the IP address of the KDC that serves the client's
       home realm (AS-H).  AS-V then initiates an XASP exchange with
       AS-H by sending an XASP-REQ message.

       The goal of the XASP exchange is to enable the visited KDC to
       build a valid KRB_AS_REP message in response to a KRB_AS_REQ
       request issued by a roaming client.  AS-V basically needs to
       build or have an EncASRepPart [RFC4120] and the associated
       session key.  The EncASRepPart is a part of the KRB_AS_REP that
       must be encrypted using the client's secret key (shared with the
       home AS only).  The XASP protocol allows AS-V to obtain the
       EncASRepPart from the home AS.  The EncASRepPart includes a
       session key that will be shared between the client and the TGS of
       the visited realm.  This session key is also obtained from AS-H
       using the XASP protocol.

       The XASP-REQ message contains all the necessary information to
       enable AS-H to build an EncASRepPart and to transmit it along
       with the associated session key, in a secure manner, to AS-V.
       The XASP-REQ message is built from the client's KRB_AS_REQ
       request, extended using the 'padata' field.  The 'padata' field
       includes information for cross-realm operations as well as
       material that will allow the KDCs to authenticate each others and
       to protect the XASP exchange.  For this purpose, public key
       cryptography (based on a pre-existent PKI) is used between the
       two KDCs.  The padata field of the XASP-REQ includes a signature
       [RFC3852] and the certificate of AS-V.  The process of building
       the XASP-REQ message and the associated 'padata' field is
       detailed in Section 3.6.2.  Note that the padata fields used in
       the XASP and XTGSP exchanges all have the same format which is
       described in Section 3.4.


   3.  AS-H -> AS-V : XASP-REP

       Upon reception of an XASP-REQ message, AS-H uses the signature
       and the certificate from the padata field to authenticate and
       verify the request.  Then, AS-H generates a session key (a TGS



Zrelli, et al.          Expires December 19, 2006              [Page 19]


Internet-Draft                    XKDCP                        June 2006


       session key) and builds an EncASRepPart then encrypts it using
       the client's secret key.  The TGS session key is included in the
       EncASRepPart as specified by [RFC4120] and a copy of the same key
       is encrypted using the public key of AS-V.  The encrypted
       EncASRepPart and the encrypted session key are conveyed to AS-V
       using the padata field of the XASP-REP message.  The XASP-REP
       message is a KRB_AS_REP message extended using the padata field.
       The padata field includes material for authenticating the home
       KDC and for verifying the integrity of the message.  The XASP-REP
       message will be used by AS-V to build a KRB_AS_REP.


   4.  AS-V -> Client : KRB_AS_REP

       When AS-V receives the XASP-REP message, it starts by
       authenticating and verifyng the message using the signature and
       the certificate from the padata field.  Then, it extracts the TGS
       session key from the padata field.  AS-V uses its own private key
       to decrypt the TGS session key.  The EncASRepPart is extracted
       from the XASP-REP message.  At this stage AS-V is able to build a
       KRB_AS_REP composed of a TGT (using the TGS session key extracted
       from the XASP-REP) and the EncASRepPart.  The KRB_AS_REP message
       is then delivered to the roaming client.

       The client processes the KRB_AS_REP message exactly as specified
       in [RFC4120].  The client uses her secret key to decrypt the
       EncASRepPart (created by AS-H).  The TGT and the TGS session key
       can then be used to create a KRB_TGS_REQ messages to request
       service tickets from the visited KDC.



3.4  The XKDCP padata

   The XKDCP protocol defines a new pre-authentication type (padata-
   type)

   PA-XKDCP    18

   The XKDCP extension specifies the ASN.1 PA-XKDCP-DATA type which
   represents a mandatory padata that MUST be included in all XKDCP
   messages.  Each time a KDC issues an XKDCP message, it MUST build a
   PA-DATA object whose padata-type is PA-XKDCP and with the DER
   encoding of an PA-XKDCP-DATA object as padata-value.

   The PA-XKDCP-DATA object specification is as follows :





Zrelli, et al.          Expires December 19, 2006              [Page 20]


Internet-Draft                    XKDCP                        June 2006


   PA-XKDCP-DATA  ::= [APPLICATION 18] IMPLICIT OCTET STRING

   XKDCP-BODY       ::= SEQUENCE {

       kippu        [0] IMPLICIT OCTET STRING OPTIONAL,

       cname        [1] PrincipalName,

       caddr        [2] HostAddresses,

       crealm       [3] Realm,

       lrealm       [4] Realm,

       cksum        [5] Checksum OPTIONAL,

       ...
   }

   KIPPU            ::= SEQUENCE {

       encSK        [1] EncryptionKey,

       xkdcpEncData [2] EncryptedData,

       tktOptions   [3] TicketFlags,

       last-req     [4] LastReq,

       authtime     [5] KerberosTime,

       starttime    [6] KerberosTime OPTIONAL,

       endtime      [7] KerberosTime,

       renew-till   [8] KerberosTime OPTIONAL,

       proxyaddr    [9] HostAddress OPTIONAL,

       ...
   }



   The PA-XKDCP-DATA object contains a CMS type ContentInfo encoded
   according to [RFC3852].  The contentType field of the type
   ContentInfo is id-signedData (1.2.840.113549.1.7.2), and the content
   field is a SignedData.  The eContentType field for the type



Zrelli, et al.          Expires December 19, 2006              [Page 21]


Internet-Draft                    XKDCP                        June 2006


   SignedData is id-xkdcp-authData (1.3.6.1.5.2.4.1), and the eContent
   field contains the DER encoding of the type XKDCP-BODY.

   The XKDCP-BODY object is filled as follows:

   kippu : The kippu field is built by the responding KDC.  It contains
      a KIPPU object signed by the responding KDC and encrypted using
      the public key of the initiating KDC.  It consists of a CMS type
      ContentInfo encoded according to [RFC3852].  The contentType field
      of the type ContentInfo is id-envelopedData
      (1.2.840.113549.1.7.3), and the content field is an EnvelopedData.
      The contentType field of the EncryptedContentInfo id-signedData
      (1.2.840.113549.1.7.2).  The eContentType field for the inner type
      SignedData (when unencrypted) is id-xkdcp-kippu (1.3.6.1.5.2.4.2)
      and the eContent field contains the DER encoding of a KIPPU object
      (described below).  Note that the Kippu field is used in XTGSP-REP
      and XASP-REP messages only.

   cname : The principal name of the client who issued the initial
      request (KRB_AS_REQ or KRB_TGS_REQ).  The client name is obtained
      from the 'cname' field of the client's request.

   caddr : The IP address of the client who issued the request.  This
      field is a "HostAddress" object [RFC4120].

   crealm : The realm name where the client is registered as a Kerberos
      principal.  This information is filled by the initiating KDC.  In
      case of an XTGSP exchange, the realm name of the client is
      extracted from the TGT.  In case of an XASP exchange, the client's
      realm name is obtained from the 'realm' field of the KRB_AS_REQ
      message.

   lrealm : The realm name of the KDC that initiated an XKDCP exchange.

   cksum : This field contains an unkeyed checksum computed over the DER
      encoding of the "req-body" of a XTGSP-REQ or an XASP-REQ message
      (Note that the req-body in the XKDCP messages is a copy of the
      req-body component of the KRB_KDC_REQ issued by the client).  This
      checksum is used to protect the integrity of "req-body" part of
      the XTGSP-REQ and XASP-REQ messages.  The "cksum" field is a
      "Checksum" data object as defined in [RFC4120].  The SHA-1 hash
      function ("cksumtype" value 10 [RFC3961]) MUST be supported to
      compute the checksum.  The KDC SHOULD support additional
      collision-proof, unkeyed hash functions.







Zrelli, et al.          Expires December 19, 2006              [Page 22]


Internet-Draft                    XKDCP                        June 2006


   encSK : This field contains an EncryptionKey object [RFC4120].

   xkdcpEncData : The xkdcpEncData is an EncryptedData object [RFC4120].
      In case of a XTGSP-REP message, this field contains an
      EncTicketPart [RFC4120] encrypted using the secret key of the
      service.  In case of an XASP-REP message, the xkdcpEncData
      contains an EncASRepPart [RFC4120] encrypted using the secret key
      of the client.

   tktOptions:  Contains a "TicketFlags" object that indicates the
      options associated with a certain credential.  The responding KDC
      fills these fields by applying the realm's policy while taking
      into account the client's request.

   last-req, authtime, starttime, endtime, renew-till: These fields have
      the same definition as in section 5.4.2. of [RFC4120].  The
      responding KDC fills these fields by applying the realm's policy
      while taking into account the client's request.  These options
      will be used by the initiating KDC to build the KRB_KDC_REP
      message.

   proxyaddr:  Same as the 'caddr' field of the Ticket object (section
      5.3. of [RFC4120]).

   The XKDCP extension defines the following object identifiers:

   id-xkdcp OBJECT IDENTIFIER ::=
    { iso (1) org (3) dod (6) internet (1) security (5)
      kerberosv5 (2) xkdcp (4) }

   id-xkdcp-authData      OBJECT IDENTIFIER  ::= { id-xkdcp 1 }
   id-xkdcp-kippu         OBJECT IDENTIFIER  ::= { id-xkdcp 2 }

   "id-xkdcp" identifies the XKDCP extension and the PA-XKDCP-DATA
   object.  The "id-xkdcp-authData" identifies the XKDCP-DATA object.
   "id-xkdcp-kippu" identifies the object KIPPU.

3.5  XTGSP protocol details

3.5.1  The KRB_TGS_REQ message

   When a client wishes to access any service located at any realm.  She
   must first determine the principal name and the realm name of the
   service.  In the current specification of the Kerberos protocol, if
   the realm name of the service is different from the client's home
   realm, then the client must first obtain a TGT for the remote realm
   (where the service is registered).




Zrelli, et al.          Expires December 19, 2006              [Page 23]


Internet-Draft                    XKDCP                        June 2006


   When assuming that the KDCs support the XTGSP extension, the client
   does not try to obtain a TGT for the remote realm.  Instead, she
   issues a KRB_TGS_REQ to the KDC for which she has already a TGT (this
   KDC might be the client's home KDC or it might be any another KDC for
   which the client has a TGT).  The KRB_TGS_REQ message in the same as
   defined in section 5.4.1 of [RFC4120].  The only difference is in the
   field 'realm'.  The XKDCP specification mandates that the 'realm'
   field MUST contain the realm name where the service is believed to be
   registered.

3.5.2  The XTGSP-REQ message

   On reception of a KRB_TGS_REQ message, the KDC checks the field
   'realm' in the KDC-REQ-BODY.  If this field indicates the same realm
   name as the KDC's realm name, then the KDC follows the same behavior
   as described in section 3.3.2 of [RFC4120].  If the realm name
   indicated in the 'realm' field is different from the local realm name
   (which means that the service is located in a remote realm), then the
   XTGSP extension MUST be used.

   The following specifies the behavior of the KDC when the XTGSP
   extension is in use:

   1.  The KDC starts by validating the request by validating the TGT
       and verifying the integrity of the KRB_TGS_REQ message as
       specified in section 3.3.2 of [RFC4120].  If the KRB_TGS_REQ is
       valid then the KDC can proceed to the next step.

   2.  The KDC determines the KDC of the remote realm, the process of
       discovering the remote KDC is out of the scope of this document
       but the same guidelines specified in section 7.2.3. of [RFC4120]
       are applicable.  If the KDC fails to discover the KDC of the
       remote realm, then a KRB_ERROR message is sent to the client with
       an error code KDC_ERR_XKDCP_CANT_DISCOVER_KDC and the processing
       of the KRB_TGS_REQ stops here, otherwise the KDC proceeds to the
       next step.

   3.  The KDC creates a XTGSP-REQ message as specified below :


       XTGSP-REQ        ::= SEQUENCE {
               pvno            [1] INTEGER ,
               msg-type        [2] INTEGER ,
               padata          [3] SEQUENCE OF PA-DATA OPTIONAL,
               req-body        [4] KDC-REQ-BODY
       }





Zrelli, et al.          Expires December 19, 2006              [Page 24]


Internet-Draft                    XKDCP                        June 2006


       The XTGSP-REQ message has the same format and semantics as the
       KDC-REQ [RFC4120] message.  The fields are filled as follows :

       pvno : Indicates the Kerberos protocol version, this integer MUST
          be set to 5.

       msg-type : The XTGSP-REQ message type MUST be set to the integer
          XKDCP-XTGSP-REQ.

       padata : The padata field MUST contain any padata field extracted
          from the client's initial KRB_TGS_REQ message as well as an
          additional padata field of type PA-XKDCP-DATA as specified in
          Section 3.4.

       req-body : This field contains a copy of the 'req-body' component
          from the KRB_TGS_REQ issued by the client.  Note that the
          initiating KDC can modify the fields of the req-body to
          reflect the realm policy (more details in Section 3.7).

   4.  The XTGSP-REQ is then sent to the remote KDC.


3.5.3  The XTGSP-REP message

   On reception of a XTGSP-REQ message the remote KDC proceeds as
   follows:

   1.  The KDC MUST verify the signature in the PA-XKDCP-DATA object
       according to [RFC3852].  If the remote KDC can not build a
       certification path to validate the X.509 certificate [RFC3280],
       it sends back a KRB-ERROR message with the code
       KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE.   When receiving this error
       message, the initiating KDC SHOULD issue a new XTGSP-REQ using a
       different certificate.  If the signature is verified
       successfully, the KDC proceeds to the next step.

   2.  The KDC verifies the checksum in the field 'cksum'.  If the
       checksum test fails, the remote KDC sends a KRB_ERROR message
       with an error code KRB_ERR_XKDCP_BAD_INTEGRITY .  If the checksum
       test succeeds, then the integrity of the information embedded in
       the 'req-body' of the XTGSP-REQ message is verified.  The KDC can
       then proceed to the next step.

   3.  The remote KDC verifies that the realm indicated by the field
       'realm' of the XTGSP-REQ matches with its own realm name.  If the
       realm name does not match, the KDC issues a KRB_ERROR message to
       the initiating KDC, the error code of this message is
       KRB_ERR_XKDCP_WRONG_REALM.  If the realm name matches, the KDC



Zrelli, et al.          Expires December 19, 2006              [Page 25]


Internet-Draft                    XKDCP                        June 2006


       verifies that the requested service is registered in its
       database.  If the principal is not found, then a KRB_ERROR
       message is sent to the initiating KDC with an error code
       KDC_ERR_XKDCP_S_PRINCIPAL_UNKNOWN .  If the principal is found in
       the database, then the KDC proceeds to the next step.

   4.  The remote KDC builds an EncTicketPart [RFC4120] which is defined
       as follows :

   EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
              flags                   [0] TicketFlags,
              key                     [1] EncryptionKey,
              crealm                  [2] Realm,
              cname                   [3] PrincipalName,
              transited               [4] TransitedEncoding,
              authtime                [5] KerberosTime,
              starttime               [6] KerberosTime OPTIONAL,
              endtime                 [7] KerberosTime,
              renew-till              [8] KerberosTime OPTIONAL,
              caddr                   [9] HostAddresses OPTIONAL,
              authorization-data      [10] AuthorizationData OPTIONAL
      }


       The EncTicketPart is filled as follows :

       flags : The remote KDC relies on the local policy and the options
          requested by the client (in the kdc-options field of the req-
          body of the XTGSP-REQ message) to decide which ticket options
          will be granted.

       Key : The remote KDC generates a random session key and places it
          in an EncryptionKey [RFC4120] object.

       crealm : The same as the 'crealm' field of the 'req-body' of the
          XTGSP-REQ message

       cname : Contains the client's principal name.

       transited : Not used, left empty.

       authtime, starttime, endtime, renew-till, caddr, authorization-
       data : These fields are filled according to [RFC4120].  The KDC
          takes into consideration the realm's policy and the client's
          request to determine the lifetime and other parameters related
          to the ticket.





Zrelli, et al.          Expires December 19, 2006              [Page 26]


Internet-Draft                    XKDCP                        June 2006


   5.  The remote KDC builds a XTGSP-REP message defined as follows :

      XTGSP-REP         ::= SEQUENCE {
              pvno            [0] INTEGER ,
              msg-type        [1] INTEGER ,
              padata          [2] SEQUENCE OF PA-DATA OPTIONAL,
              crealm          [3] Realm,
              cname           [4] PrincipalName,
              ticket          [5] Ticket,
              enc-part        [6] EncryptedData
      }

       The XTGSP-REP message is filled as follows :

       pvno : Indicates the Kerberos protocol version, this integer MUST
          be set to 5.

       msg-type : The XTGSP-REP message type MUST be set to the integer
          XKDCP-XTGSP-REP

       padata : The padata field MUST contain a padata field of type PA-
          XKDCP-DATA ( specified in Section 3.4).  The session key which
          was generated by the remote KDC and inserted in the 'key'
          field of EncTicketPart, is used to build an EncryptionKey
          object.  This object is used as the field 'encSK' of the kippu
          object of the padata.  The EncTicketPart, built by the remote
          KDC in step 4, is encrypted using the secret key of the
          requested service.  The result is used to build an
          EncryptedData object.  The EncryptedData object is then placed
          in the xkdcpEncData of the KIPPU object.  The padata is then
          signed by the KDC as specified in Section 3.4

          These fields contain the client's principal name and the
          client's realm name.

       ticket, enc-part: These fields are not used, they are left empty.

   6.  The remote KDC sends the XTGSP-REP to the initiating KDC.


3.5.4  The KRB_TGS_REP message

   The local realm uses the XTGSP-REP message to build a KRB_TGS_REP
   message for the client.  For that, the local KDC proceeds as follows
   :

   1.  The local KDC MUST verify the signature in the PA-XKDCP-DATA
       object according to [RFC3852].  If the local KDC can not build a



Zrelli, et al.          Expires December 19, 2006              [Page 27]


Internet-Draft                    XKDCP                        June 2006


       certification path to validate the X.509 certificate [RFC3280],
       it sends back a KRB-ERROR message with the code
       KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE.   Upon reception of this
       error message, the remote KDC SHOULD try to retransmit the XTGSP-
       REP message using a different certificate.  If the signature is
       verified successfully, the local KDC proceeds to the next step.

   2.  The EncTicketPart is extracted from the xkdcpEncData component of
       the kippu object.  The session key is extracted from the encSK
       field of the kippu object.  For that, the KDC uses its own
       private key to decrypt the kippu object.

   3.  The local KDC builds an EncTGSRepPart [RFC4120] which is defined
       as follows :


     EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart

     EncKDCRepPart   ::= SEQUENCE {
              key             [0] EncryptionKey,
              last-req        [1] LastReq,
              nonce           [2] UInt32,
              key-expiration  [3] KerberosTime OPTIONAL,
              flags           [4] TicketFlags,
              authtime        [5] KerberosTime,
              starttime       [6] KerberosTime OPTIONAL,
              endtime         [7] KerberosTime,
              renew-till      [8] KerberosTime OPTIONAL,
              srealm          [9] Realm,
              sname           [10] PrincipalName,
              caddr           [11] HostAddresses OPTIONAL
      }


       The EncTGSRepPart is filled as follows :

       Key: This field is filled with the session key extracted from the
          kippu object.

       flags: This field is obtained from the tktOptions field of the
          kippu object extracted from the XTGSP-REP message.  These
          ticket options reflect the policy of the remote realm where
          the service is actually deployed.

       authtime, starttime, endtime, renew-till These fields are filled
          using the fields with the same name in the kippu object.





Zrelli, et al.          Expires December 19, 2006              [Page 28]


Internet-Draft                    XKDCP                        June 2006


       srealm, sname Contains the realm name of the service (which is
          different from the realm name that issues the KRB_TGS_REP
          message) and the principal name of the service.

          Same usage as in [RFC4120].  This field is filled using the
          field proxyaddr from the kippu object.

   4.  The local KDC builds a ticket using the EncTicketPart and other
       information extracted from the kippu object.  The EncTGSRepPart
       built in the previous step is used with the Ticket to build a
       KRB_TGS_REP message that will be sent to the client.  The
       EncTGSRepPart is encrypted using the TGS session key shared
       between the client and the local TGS, then placed in the enc-part
       field of the KRB_TGS_REP message


3.6  The XASP protocol details

   The XASP protocol allows a KDC (generally a visited KDC) to deliver a
   TGT (destined to be used with the TGS of the same KDC) to users who
   are not registered in the KDC's database.  The XASP protocol defines
   an exchange between the visited KDC and the client's home KDC.  The
   result of the XASP exchange is that the visited KDC is able to
   deliver the desired TGT.  An overview of the the XASP protocol was
   presented in section Section 3.3.  The following paragraphs give
   deeper details of the XASP message specification and exchanges.

3.6.1  The KRB_AS_REQ message

   When a client wishes to get a TGT for a visited realm, she issues a
   KRB_AS_REQ message to the KDC of the target realm.  The KRB_AS_REQ is
   defined in [RFC4120].  The client fills this request exactly as if
   she was initiating an AS exchange with her home KDC.  Note that, the
   XKDCP protocol mandates that the client MUST indicate her home realm
   name in the field 'realm' of the KRB_AS_REQ request.  The client MUST
   use the principal name of the TGS of the visited realm in the 'sname'
   field of the request.  According to [RFC4120], section 7.3, the name
   of the TGS contains the realm name of the KDC that will issue the TGT
   and the realm name of the KDC that will accept the TGT.  In case of
   roaming scenario using XASP for cross-realm operations, the client
   MUST use the visited realm name for building the TGS name of the
   KRB_AS_REQ.

3.6.2  The XASP-REQ message

   Upon reception of a KRB_AS_REQ, the AS checks the 'realm' field of
   the KDC-REQ-BODY.  If this field matches the local realm name, then
   the request MUST be processed as defined in [RFC4120].  If the



Zrelli, et al.          Expires December 19, 2006              [Page 29]


Internet-Draft                    XKDCP                        June 2006


   client's realm name does not match with the target KDC's realm name,
   then the client is considered as roaming client, and the request MUST
   be processed using the XASP extension.

   The following specifies the behavior of the KDC when the XASP
   extension is being used :

   1.  The KDC determines the KDC of the client's home realm, this host
       discovery process is out of the scope of this document but the
       same guidelines specified in section 7.2.3. of [RFC4120] are
       applicable.  If the foreign KDC fails to discover the KDC of
       client's home realm, then a KRB_ERROR message is sent to the
       client with an error code KDC_ERR_XKDCP_CANT_DISCOVER_KDC and the
       processing of the KRB_AS_REQ stops here, otherwise the KDC
       proceeds to the next step.

   2.  The KDC creates an XASP-REQ message as specified below :


       XASP-REQ        ::= SEQUENCE {
               pvno            [1] INTEGER ,
               msg-type        [2] INTEGER ,
               padata          [3] SEQUENCE OF PA-DATA OPTIONAL,
               req-body        [4] KDC-REQ-BODY
       }


       The XASP-REQ message has the same format and semantics as the
       KDC-REQ [RFC4120] message.  The fields are filled as follows :

       pvno : Indicates the Kerberos protocol version, this integer MUST
          be set to 5.

       msg-type : The XASP-REQ message type MUST be set to the integer
          XKDCP-XASP-REQ

       padata : The padata field MUST contain any padata field issued by
          the client as well as a padata field of type PA-XKDCP-MSG as
          specified in Section 3.4.

       req-body : This field contains a copy of the 'req-body' component
          from the KRB_AS_REQ issued by the client.  Note that the
          initiating KDC can modify the fields of the req-body to
          reflect the realm policy (more details in Section 3.7).

   3.  The XASP-REQ is sent to the client's home KDC.





Zrelli, et al.          Expires December 19, 2006              [Page 30]


Internet-Draft                    XKDCP                        June 2006


3.6.3  The XASP-REP message

   On reception of an XASP-REQ message the home KDC proceeds as follows
   :

   1.  The KDC MUST verify the signature in the PA-XKDCP-DATA object
       according to [RFC3852].  If the home KDC can not build a
       certification path to validate the X.509 certificate [RFC3280],
       it sends back a KRB-ERROR message [RFC4120] with error code
       KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE.  Upon reception of this
       error message, the visited KDC SHOULD try another XASP-REQ using
       a different certificate.  If the signature is verified
       successfully, then the home KDC proceeds to the next step.

   2.  The home KDC verifies the checksum in the 'cksum' field of the
       padata field of the XASP-REQ message.  If the checksum test
       fails, the home KDC sends a KRB_ERROR message with an error code
       KRB_ERR_XKDCP_BAD_INTEGRITY.  If the checksum test succeeds, the
       integrity of the information embedded in the 'req-body' of the
       XASP-REQ message is verified.  The KDC can then proceed to the
       next step.

   3.  The KDC verifies that the client's home realm indicated by the
       field 'realm' of the XASP-REQ matches with the KDC's realm name.
       If the realm name does not match, the KDC issues a KRB_ERROR
       message to the initiating KDC, the error code of this message is
       KRB_ERR_XKDCP_WRONG_REALM .  The KDC then verifies that the
       client's principal is registered in its database.  If the
       principal is not found, a KRB_ERROR message is sent to the
       visited KDC with an error code KDC_ERR_XKDCP_C_PRINCIPAL_UNKNOWN
       .  If the principal is found then the KDC proceeds to the next
       step.

   4.  The home KDC builds an EncASRepPart which is defined in [RFC4120]
       as follows.
















Zrelli, et al.          Expires December 19, 2006              [Page 31]


Internet-Draft                    XKDCP                        June 2006


   EncASRepPart   ::= [APPLICATION 26] EncKDCRepPart

   EncKDCRepPart   ::= SEQUENCE {
           key             [0] EncryptionKey,
           last-req        [1] LastReq,
           nonce           [2] UInt32,
           key-expiration  [3] KerberosTime OPTIONAL,
           flags           [4] TicketFlags,
           authtime        [5] KerberosTime,
           starttime       [6] KerberosTime OPTIONAL,
           endtime         [7] KerberosTime,
           renew-till      [8] KerberosTime OPTIONAL,
           srealm          [9] Realm,
           sname           [10] PrincipalName,
           caddr           [11] HostAddresses OPTIONAL
   }


       The EncKDCRepPart is filled as follows :

       Key : The home KDC generates a random session key and places it
          in an EncryptionKey object.  This session key will be used
          later on as a TGS session key shared between the client and
          the visited KDC.

       nonce : The value of the nonce field from the XASP-REQ message is
          copied into this field.

       flags : The home KDC relies on the local policy and the options
          requested by the client (in the kdc-options field of the req-
          body of the XASP-REQ message) to decide which ticket options
          will be granted.

       crealm, cname : The client's home realm name and principal name.

       transited : Not used, left empty.

       authtime, starttime, endtime, renew-till, caddr,authorization-
       data : These fields are filled according to [RFC4120].  The home
          KDC takes into consideration the realm's policy and the
          client's request to determine the lifetime and other
          parameters related to the ticket.

       srealm: This field MUST indicate the realm name of the visited
          KDC (or the visited realm name).  The visited realm name is
          extracted from the 'lrealm' field of the XASP-REQ message.





Zrelli, et al.          Expires December 19, 2006              [Page 32]


Internet-Draft                    XKDCP                        June 2006


       sname: This field contains the principal name that corresponds to
          the TGS of the visited realm.

   5.  The remote KDC builds an XASP-REP message defined as follows :

      XASP-REP         ::= SEQUENCE {
              pvno            [0] INTEGER ,
              msg-type        [1] INTEGER ,
              padata          [2] SEQUENCE OF PA-DATA OPTIONAL,
              crealm          [3] Realm,
              cname           [4] PrincipalName,
              ticket          [5] Ticket,
              enc-part        [6] EncryptedData
      }

       The XASP-REP message is filled as follows :

       pvno : Indicates the Kerberos protocol version, this integer MUST
          be set to 5.

       msg-type : For the XASP-REP message this field MUST be set to the
          integer XKDCP-XASP-REP

       padata : The padata field MUST contain a padata of type PA-XKDCP-
          MSG (specified in Section 3.4).  The session key (generated by
          the home KDC and inserted in the 'key' field of EncTicketPart)
          is used to build an EncryptionKey object.  The EncryptionKey
          object is placed in the encSK field of the kippu object.  The
          EncASRepPart built by the home KDC in step 4 is encrypted
          using the client's secret key.  The result is used to build an
          EncryptedData object which will be placed in the xkdcpEncData
          of the kippu object.

          These fields contain the client's realm name and the client's
          principal name

       ticket, enc-part: These fields are not used, they are left empty.

   6.  The home KDC sends the XASP-REP to the visited KDC.


3.6.4  The KRB_AS_REP message

   The visited realm uses the XASP-REP message to build a KRB_AS_REP
   message for the client.  For that, the visited KDC proceeds as
   follows :





Zrelli, et al.          Expires December 19, 2006              [Page 33]


Internet-Draft                    XKDCP                        June 2006


   1.  The visited KDC MUST verify the signature in the PA-XKDCP-DATA
       object according to [RFC3852].  If the visited KDC can not build
       a certification path to validate the X.509 certificate [RFC3280],
       it sends back a KRB-ERROR message with the code
       KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE.  Upon reception of this
       error message, the home KDC SHOULD try to retransmit the XASP-REP
       message using a different certificate.  If the signature is
       verified successfully, the local KDC proceeds to the next step.

   2.  The EncASRepPart is obtained from the xkdcpEncData component of
       the kippu object.  The TGS session key is extracted from the
       encSK field of the kippu object.  For that, the visited KDC uses
       its own private key to decrypt the kippu object.

   3.  The visited KDC builds an EncTicketPart object [RFC4120] which is
       defined as follows :


   EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
              flags                   [0] TicketFlags,
              key                     [1] EncryptionKey,
              crealm                  [2] Realm,
              cname                   [3] PrincipalName,
              transited               [4] TransitedEncoding,
              authtime                [5] KerberosTime,
              starttime               [6] KerberosTime OPTIONAL,
              endtime                 [7] KerberosTime,
              renew-till              [8] KerberosTime OPTIONAL,
              caddr                   [9] HostAddresses OPTIONAL,
              authorization-data      [10] AuthorizationData OPTIONAL
      }


       The EncTicketPart is filled as follows :

       flags: The visited KDC SHOULD use the tktOptions field of the
          kippu object extracted from the XASP-REP message.  The visited
          KDC MAY check the ticket options indicated in the tktOptions
          field against its local policy to decide which are the final
          ticket options that will be granted to the client.  (Note that
          if the visited KDC does not use the same flags as in
          tktOptions, the client will have wrong information about the
          ticket flags).

       Key : The TGS session key extracted from the encSK field of the
          kippu object is placed in this field.





Zrelli, et al.          Expires December 19, 2006              [Page 34]


Internet-Draft                    XKDCP                        June 2006


       crealm, cname : The client's home realm name and principal name.

       transited : Not used, left empty.

       authtime, starttime, endtime, renew-till, caddr, authorization-
       data : To fill these fields, the visited KDC SHOULD use the the
          correspondent fields of the kippu object extracted from the
          XASP-REP message.  The visited KDC MAY check these fields
          against its local policy to decide what will be the final
          values assigned to these fields.  (Note that if the visited
          KDC does not use the same values as in the kippu object, the
          client will have wrong information about the TGT that she
          obtained).

   4.  The visited KDC builds a Ticket object (ticket granting ticket)
       using the EncTicketPart built in the previous step.  The 'realm'
       field of the ticket indicates the realm name of visited KDC.  The
       EncASRepPart extracted from the kippu object is used with the
       ticket to build a KRB_AS_REP message that will be sent to the
       client.  The client uses her secret key to decrypt the
       EncASRepPart of the KRB_AS_REP message.  She can then use the TGS
       session key to build an authenticator and issue KRB_TGS_REP
       messages to request service tickets for services deployed in the
       visited realm.


3.7  Realm policy

   Each realm has enough control that enables it to apply its own
   policies concerning cross-realm authentication.  The initiating KDC
   can accept or refuse a client's request according to its policy.  If
   the initiating KDC can not process the client's request because the
   requested options (ticket flags and lifetime) are not compatible with
   its policy, it MUST issue a KRB-ERROR with error code
   KDC_ERR_XKDCP_WRONG_TKT_OPTS.  The client then SHOULD issue another
   request with different options.  When the client's request is
   accepted, the initiating KDC MAY fix the final options according to
   its local policy while taking in consideration the client's request.
   Then, the initiating KDC issues an XKDCP request to the remote KDC.
   The responding KDC can decide whether to honor the request or not
   according to its local policy.  If the responding KDC can not process
   the XKDCP request because the requested options are not compatible
   with its policy, it issues a KRB-ERROR with error code
   KDC_ERR_XKDCP_WRONG_TKT_OPTS.  The initiating KDC notifies the client
   about the error and finalizes the exchange by sending a KRB-ERROR
   with code KDC_ERR_XKDCP_INCOMPATIBLE_CROSS_REALM_POLICY.  Otherwise
   the responding KDC processes the XKDCP request and issues the
   corresponding reply message.



Zrelli, et al.          Expires December 19, 2006              [Page 35]


Internet-Draft                    XKDCP                        June 2006


   After receiving the remote KDC's reply which contains parts of the
   credentials requested by the client, the initiating KDC can decide
   whether to accept the remote KDC's policy that were applied on the
   credentials or not.  If the XKDCP reply message indicates that the
   responding KDC did not use the same options as requested in the XKDCP
   request message, and if these options are not acceptable according to
   the initiating KDC's policy, then the initiating KDC MAY issue a KRB-
   ERROR message to the client with error code
   KDC_ERR_XKDCP_INCOMPATIBLE_CROSS_REALM_POLICY.  If the XKDCP reply
   message shows that the remote KDC used options that are compatible
   with the initiating KDC's policy, the initiating KDC use these
   options to build the credentials.

   For example, a roaming client can issue a request asking for a TGT
   from a visited KDC.  The client may ask for a ticket life time of 5
   hours.  The visited KDC decides whether to accept the client's
   request or not depending for example on whether the client's realm is
   known or not, whether the client's ip address is acceptable, and most
   importantly, if the requested ticket options are acceptable (lifetime
   of 5 hours).  The visited KDC may choose to reduce the lifetime to 2
   hours or to reject the client's request.  If the visited KDC decides
   to process the client's request, it will issue an XASP-REQ message to
   the client's home KDC.  The XASP-REQ message includes information to
   notify the home KDC that the credentials to be issued must have a
   lifetime of 2 hours.

   The client's home KDC can decide whether the requested lifetime is
   acceptable or not.  If not, the KDC_ERR_XKDCP_WRONG_TKT_OPTS error
   will be sent to the initiating KDC.  Otherwise, the home KDC may
   accept the requested lifetime of 2 hours.  It MAY also consider a
   shorter lifetime of 1 hour for example.  The XASP-REP message
   includes information that indicates to the visited KDC that the home
   KDC issued credentials with lifetime of 1 hour.  The visited KDC MAY
   accept this value or reject it by issuing an
   KDC_ERR_XKDCP_INCOMPATIBLE_CROSS_REALM_POLICY error to the client.
















Zrelli, et al.          Expires December 19, 2006              [Page 36]


Internet-Draft                    XKDCP                        June 2006


4.  Constants

   The XKDCP extension defines a new PreAuthentication Data Types as
   follows :


       Padata and Data Type          Padata-type value

        PA-XKDCP                          18


   Additionally, the XKDCP extension uses the following constants.

4.1  XKDCP error codes


   Error code                                      | Value
   ------------------------------------------------+-------
   KDC_ERR_XKDCP_CANT_DISCOVER_KDC                 |  80
   KDC_ERR_XKDCP_CANT_DISCOVER_KDC                 |  81
   KDC_ERR_XKDCP_CANT_VERIFY_CERTIFICATE           |  82
   KRB_ERR_XKDCP_BAD_INTEGRITY                     |  83
   KRB_ERR_XKDCP_WRONG_REALM                       |  84
   KDC_ERR_XKDCP_S_PRINCIPAL_UNKNOWN               |  85
   KDC_ERR_XKDCP_C_PRINCIPAL_UNKNOWN               |  86
   KDC_ERR_XKDCP_WRONG_TKT_OPTS                    |  87
   KDC_ERR_XKDCP_INCOMPATIBLE_CROSS_REALM_POLICY   |  89


4.2  XKDCP message types


   Message type                                    | Value
   ------------------------------------------------+-------
   XKDCP-XTGSP-REQ                                 |  40
   XKDCP-XTGSP-REP                                 |  41
   XKDCP-XASP-REQ                                  |  42
   XKDCP-XASP-REP                                  |  43













Zrelli, et al.          Expires December 19, 2006              [Page 37]


Internet-Draft                    XKDCP                        June 2006


5.  Security considerations

   [RFC4120] highlights several security considerations.  All these
   considerations apply to a Kerberos KDC implementing the XKDCP
   extension.  This section discusses the security properties as well as
   additional vulnerabilities and security recommendations introduced by
   the XKDCP extension.

5.1  Integrity protection

   All XKDCP messages are integrity protected.  The 'req-body' part of
   XKDCP requests is protected using an unkeyed checksum.  On the other
   hand, the 'padata' part is always protected using public key
   signature.  The uneyed checksum used to protect the 'req-body' field
   is included in the padata field and is thus protected.

5.2  Confidentiality

   In XKDCP, sensible information is encrypted in order to preserve its
   confidentiality.  The session keys created by the responding KDC are
   encrypted using the public key of the initiating KDC before sending
   the XKDCP reply message.  On the other hand no secret key (shared
   between a principal and its home KDC) is revealed to any third party.
   The secret keys are used by the responding KDC to create
   EncryptedData objects, but are never transmitted.

5.3  DoS and replay protection

   An attacker can flood a KDC with forged or replayed XKDCP requests or
   replies.  Since the processing of any XKDCP message involves public
   key cryptography, such attack can result in a denial of service at
   the target KDC.

   In order to mitigate the threat of DoS attacks, filtering mechanisms
   should be deployed to ensure that the KDC will only receive client
   requests from the internal network and XKDCP messages from a trusted
   set of remote KDCs.

   Additionally, the XKDCP extension SHOULD use a replay protection
   mechanism to detect replayed messages.











Zrelli, et al.          Expires December 19, 2006              [Page 38]


Internet-Draft                    XKDCP                        June 2006


6.  Acknowledgments

   The authors would like to thank the following individuals for their
   comments and suggestions : Okabe Nobuo and Atsushi Inoue.

7.  Normative References

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

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

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, February 2005.

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


Authors' Addresses

   Saber Zrelli
   Japan Advanced Institute of Science and Technology
   1-1 Asahidai
   Nomi, Ishikawa  923-1292
   JAPAN

   Email: zrelli@jaist.ac.jp


   Yoichi Shinoda
   Japan Advanced Institute of Science and Technology
   1-1 Asahidai
   Nomi, Ishikawa  923-1292
   JAPAN

   Email: shinoda@jaist.ac.jp







Zrelli, et al.          Expires December 19, 2006              [Page 39]


Internet-Draft                    XKDCP                        June 2006


   Shoichi Sakane
   Yokogawa Electric Corporation
   2-9-32 Nakacho
   Musashino-shi, Tokyo  180-8750
   JAPAN

   Email: Shouichi.Sakane@jp.yokogawa.com


   Ken'ichi Kamada
   Yokogawa Electric Corporation
   2-9-32 Nakacho
   Musashino-shi, Tokyo  180-8750
   JAPAN

   Email: Ken-ichi.Kamada@jp.yokogawa.com


   Masahiro Ishiyama
   Toshiba Corporation
   1, komukai-toshiba-cho
   Saiwai-ku, Kawasaki  212-8582
   JAPAN

   Email: masahiro@isl.rdc.toshiba.co.jp


























Zrelli, et al.          Expires December 19, 2006              [Page 40]


Internet-Draft                    XKDCP                        June 2006


Appendix A.  ASN.1 module



   KerberosV5-XKDCP-SPEC {
    iso(1) identified-organization(3) dod(6) internet(1)
    security(5) kerberosV5(2) modules(4) xkdcp(6)
   }

   DEFINITIONS EXPLICIT TAGS ::= BEGIN

   IMPORTS

    KerberosTime, PrincipalName, Realm, EncryptionKey,
    HostAddress, HostAddresses, EncryptedData, EncTicketPart,
    Checksum, Ticket, TicketFlags, LastReq, KDC-REQ, PA-DATA
    FROM KerberosV5Spec2 { iso(1) identified-organization(3)
    dod(6) internet(1) security(5) kerberosV5(2)
    modules(4) krb5spec2(2) };
    -- As defined in RFC 4120.



   id-xkdcp OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
   internet (1) security (5) kerberosv5 (2) xkdcp (4) }


   id-xkdcp-authData      OBJECT IDENTIFIER  ::= { id-xkdcp 1 }
   id-xkdcp-kippu         OBJECT IDENTIFIER  ::= { id-xkdcp 2 }



   -- XTGSP-REP and XASP-REP are identical to KDC-REP [RFC4120]
   -- XTGSP-REQ and XASP-REQ are identical to KDC-REQ [RFC4120]

   XTGSP-REQ       ::= [APPLICATION 40] KDC-REQ

   XTGSP-REP       ::= [APPLICATION 41] KDC-REQ

   XASP-REQ        ::= [APPLICATION 42] KDC-REQ

   XASP-REP        ::= [APPLICATION 43] KDC-REQ


   -- The PA-XKDCP-DATA object is used in the padata-value
   -- of a PA-DATA and inserted in the padata field of all
   -- XKDCP messages.




Zrelli, et al.          Expires December 19, 2006              [Page 41]


Internet-Draft                    XKDCP                        June 2006


   PA-XKDCP-DATA  ::= [APPLICATION 18] IMPLICIT OCTET STRING

                   -- Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].
                   -- The contentType field of the type ContentInfo
                   -- is id-signedData (1.2.840.113549.1.7.2),
                   -- and the content field is a SignedData.
                   -- The eContentType field for the type SignedData
                   -- is id-xkdcp-authData (1.3.6.1.5.2.4.1), and the
                   -- eContent field contains the DER encoding of the
                   -- type XKDCP-BODY
                   -- XKDCP-BODY is defined below.

   XKDCP-BODY      ::= SEQUENCE {

     kippu         [0] IMPLICIT OCTET STRING OPTIONAL,
                   -- Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].
                   -- The contentType field of the type ContentInfo
                   -- is id-envelopedData (1.2.840.113549.1.7.3),
                   -- and the content field is an EnvelopedData.
                   -- The contentType field of the EncryptedContentInfo
                   -- id-signedData (1.2.840.113549.1.7.2).
                   -- The eContentType field for the inner type
                   -- SignedData (when unencrypted) is
                   -- id-xkdcp-kippu (1.3.6.1.5.2.4.2) and the
                   -- eContent field contains the DER encoding of the
                   -- type KIPPU defined below

                   -- This field is used only in XASP-REP and XTGSP-REP
                   -- messages.

     cname         [1] PrincipalName,
                   -- The client's principal name

     caddr         [2] HostAddress,
                   -- IP address of the client

     crealm        [3] Realm,
                   -- The realm name of the client.

     lrealm        [4] Realm,
                   -- The realm name of the KDC that
                   -- initiated an XKDCP exchange.

     cksum         [5] Checksum OPTIONAL,
                   -- This field is a checksum computed
                   -- over the DER encoding of the "req-body" of



Zrelli, et al.          Expires December 19, 2006              [Page 42]


Internet-Draft                    XKDCP                        June 2006


                   -- an XKDCP request message (XTGSP-REQ or XASP-REQ)
                   -- The "cksum" field is a "Checksum" data object
                   -- as defined in [RFC4120]. The checksum used
                   -- here is an unkeyed checksum.

     ...
   }

   KIPPU           ::= SEQUENCE {

     encSK         [1] EncryptionKey,
                   -- contains a TGS session key in XASP-REP
                   -- contains a service session key in XTGSP-REP

     xkdcpEncData  [2] EncryptedData,
                   -- contains an EncTicketPart in XTGSP-REP
                   -- contains an EncASRepPart in XASP-REP

     tktOptions    [3] TicketFlags,
                   -- conains the ticket flags

     last-req      [4] LastReq,
     authtime      [5] KerberosTime,
     starttime     [6] KerberosTime OPTIONAL,
     endtime       [7] KerberosTime,
     renew-till    [8] KerberosTime OPTIONAL,
                   -- The fields labelled 4,5,6,7,8 have the same
                   -- definitions and use as specified in [RFC4120]
     proxyaddr     [9] HostAddress OPTIONAL,
                   -- used with proxy or forwarded tickets

     ...
   }

   END
















Zrelli, et al.          Expires December 19, 2006              [Page 43]


Internet-Draft                    XKDCP                        June 2006


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.


Disclaimer of Validity

   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.


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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Zrelli, et al.          Expires December 19, 2006              [Page 44]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/