Internet DRAFT - draft-zrelli-krb-xkdcp
draft-zrelli-krb-xkdcp
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]
