Network Working Group S. Zrelli Internet-Draft Y. Shinoda Expires: September 5, 2007 JAIST S. Sakane K. Kamada Yokogawa Electric Corp. M. Ishiyama Toshiba Corp. March 4, 2007 XTGSP, the Inter-TGS protocol for cross-realm operations in Kerberos. draft-zrelli-krb-xtgsp-01 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 September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Zrelli, et al. Expires September 5, 2007 [Page 1] Internet-Draft XTGSP March 2007 Abstract Cross-realm operations in Kerberos allow users to access services offered by foreign realms. The cross-realm operations are based on inter-realm trust built using shared symmetric keys (aka. inter-realm keys) between the KDCs of the realms offering cross-realm services. The current cross-realm authentication model may be the origin of performance, scalability and security issues. This documents provides a brief overview of these issues and introduces a new cross- realm model based on PKINIT. The new model called XTGSP, defines a protocol that allows a client to obtain a service ticket, for a service offered by a foreign realm, in a single round trip. The protocol specifies an exchange between Kerberos KDCs that enables a local KDC to build a TGS-REP message for a service that is registered in a remote realm. The XTGSP exchange is secured using inter-realm keys maintained using the the PKINIT extension. Zrelli, et al. Expires September 5, 2007 [Page 2] Internet-Draft XTGSP March 2007 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Kerberos basic operations . . . . . . . . . . . . . . . . 4 1.2. Kerberos cross-realm operations . . . . . . . . . . . . . 5 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology and notations . . . . . . . . . . . . . . . . . . 10 4. Overview of the XTGSP extension . . . . . . . . . . . . . . . 12 5. Details of the XTGSP protocol . . . . . . . . . . . . . . . . 14 6. Security considerations . . . . . . . . . . . . . . . . . . . 17 7. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Zrelli, et al. Expires September 5, 2007 [Page 3] Internet-Draft XTGSP March 2007 1. Background 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 database of principals 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 lifetime, after when it expires 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 September 5, 2007 [Page 4] Internet-Draft XTGSP March 2007 KDC +-------------------------------+ +---------+ Client | AS TGS | | SVC | | +----+--------------------+-----+ +----+----+ | | | | | AS-REQ [1] | | | | -----------------------> | | | | | | | | AS-REP [2] | | | | <----------------------- | | | | | | | | TGS-REQ [3] | | | --------------------------------------------> | | | | | | | TGS-REP [4] | | | <-------------------------------------------- | | | | | | | | | | | | | | | AP-REQ [5] | | -----------------------------------------------------------> | | | | | | AP-REP [6] | | <----------------------------------------------------------- | | | | | | | | | 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. Zrelli, et al. Expires September 5, 2007 [Page 5] Internet-Draft XTGSP March 2007 However, if the home realm does not share inter-realm keys with the foreign realm, the home KDC will provide a TGT that can be used with an intermediary foreign realm that is likely to be sharing inter- realm keys with the target realm (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 inter- realm keys with the target realm), the intermediary KDC will issue a TGT that can be used with the KDC of the target realm (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 September 5, 2007 [Page 6] Internet-Draft XTGSP March 2007 +-------+ | | 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 that shares inter-realm keys with H and T T : Target realm KDC-X : KDC of realm X (where X in {H,I,T}) TGT-X ?: A TGS-REQ to request a TGT for realm X ST-SRV?: A TGS-REQ to request a service ticket for service SRV TGT-X : A TGS-REP that contains a a TGT for realm X ST-SRV : A TGS-REP that contains a service ticket for service SRV Figure 2: The Kerberos Protocol exchanges for cross-realm operations Zrelli, et al. Expires September 5, 2007 [Page 7] Internet-Draft XTGSP March 2007 2. Motivations The cross-realm support in Kerberos was added in the version 5 of the specification [RFC1510]. In contrast with other parts of the specification that have been extensively reviewed and enhanced, such as "Encryption and checksum Specification" [RFC3961] and "Kerberos Cryptosystem Negotiation Extension" [RFC4537], the cross-realm operations have not been updated since. As a result, the cross-realm operations fail to catch-up with the requirements introduced by new application domains such as mobility and building and factory automation. The applicability of Kerberos cross-realm operations in such domains present some issues. This document describes a new model for Kerberos cross-realm operations that targets the following issues: o Scalability of Inter-realm trust management : In Kerberos, the cross-realm operations are based on trust relationships between the Kerberos realms. There are two types of inter-realm trust relationships: Direct and Indirect trust relationship. A direct trust relationship means that the two realms involved in the cross-realm authentication share keys and their respective TGS principals are registered in each other's KDC. When only 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. The indirect trust relationship attempts to improve the direct trust relationship model by allowing two realms to perform cross-realm operations if there exist a chain of trust (also referred to as authentication path) that links the participating realms. However, the determination of the authentication path is an issue, there are no generic and scalable means by which the Kerberos KDC or client can dynamically discover possible authentication paths and chains of trusts between two realms. o Reliability and Forward Secrecy : 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. This constitutes a reliability issue that can fail Kerberos as a candidate authentication system for mission-critical deployments such as large factory automation and military applications. Moreover, during cross-realm authentication, 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 Zrelli, et al. Expires September 5, 2007 [Page 8] Internet-Draft XTGSP March 2007 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. If an intermediary KDC is corrupted, all the authentication operations using the corrupted KDC as intermediary KDC will be corrupted. The forward secrecy issue in cross-realm operations is a serious problem, it makes the whole web of trust as vulnerable as the weakest KDC. o Client centric exchanges : During 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 of intermediary realms increases, the delay introduced by the cross-realm messages can result in unacceptable delays due to network latency. This effect can be experienced even with devices with superior performance. Zrelli, et al. Expires September 5, 2007 [Page 9] Internet-Draft XTGSP March 2007 3. Terminology and notations 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 and notations are used in this document : Local realm: The realm where the client is physically (or topologically) located. The client can be a registered 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 TGS is the logical component of the KDC that delivers Service tickets and the associated service session key to clients. The TGS of the local realm is referred to as TGS-L and the TGS of the remote realm is referred to as TGS-R. Each TGS is registered in the database of its KDC as a service and shares a long key with it. AS: The authentication service (AS), is the part of the KDC that authenticates clients and delivers TGTs. Zrelli, et al. Expires September 5, 2007 [Page 10] Internet-Draft XTGSP March 2007 KDC: The Kerberos Key Distribution center, it is composed of two logical components: Authentication Server (AS) and Ticket Granting Service (TGS). The KDC of the local realm is referred to as KDC-L, while the KDC of a remote realm is referred to as KDC-R. cname: principal name of the client. sname: principal name of the service. srealm: Realm name of the realm offering the service. options: Ticket options times: Ticket start-time and lifetime K(X,Y): Represents a long-term key shared between the entities X and Y. For example, K(SVC,TGS-L) represents the long-term key shared between a certain service SVC and the local TGS. K(TGS- L,KDC-L) represents the long-term key shared between the TGS and the KDC of the local realm. Inter-realm key: A inter-realm key K(L,R) shared between the two realms L and R involves the registration of the TGS service of realm R (TGS-R) as a principal in realm L and the registration of the TGS service of realm L (TGS-L) as a principal in realm R. Both TGS-L/R and TGS-R/L share the same long term secret K(L,R) with KDC-R and KDC-L respectively. The inter-realm key has a life time, before using it the TGS MUST verify that the key is not expired. SK(X,Y): Represents a short-term session-key shared between the entities X and Y. For example, the session-key shared between a client C and a service SVC is represented as SK(C,SVC). TKT(X,Y,Z): Represents a Ticket delivered by Z to X, the service that with which this ticket will be used is Y. For example TKT(C,TGS-L,AS-L) represents a Ticket Granting Ticket (TGT) issued by AS-L (or KDC-L) for the client C to authenticate with the service TGS-L. Auth(X,Y): Represents an Authenticator built by X to authenticate to the entity Y. The authenticator is encrypted using a key shared between X and Y. This shared key is generally a short-term session key. Zrelli, et al. Expires September 5, 2007 [Page 11] Internet-Draft XTGSP March 2007 4. Overview of the XTGSP extension XTGSP is a protocol extension to the Kerberos protocol specification. It offers a new cross-realm protocol for Kerberos that addresses the issues stated in Section 2 In XTGSP, a client C MAY issue a TGS-REQ for a service SVC, registered in a remote realm R, to any KDC for which the client has a valid TGT (in most cases this corresponds to the KDC of the local realm). 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 XTGSP extension defines a protocol between two Kerberos key distribution centers (KDCs) that enables a Kerberos KDC (KDC-X) to build credentials even when the service is not registered in the KDC-X database. This allows clients to obtain credentials from their local KDC in a single round-trip without having to exchange messages with KDCs deployed in remote realms. The typical use of XTGSP is in remote access scenarios where the user has a TGT for the local TGS (TGS-L) and wishes to access a service deployed in a remote realm. When the client requests a service not registered in the local realm, from the local TGS, then TGS-L uses the XTGSP protocol with the TGS of the remote realm (TGS-R) where the service is registered. The execution of the XTGSP exchange enables the local TGS to obtain the necessary material needed to build the credentials requested by the client. More precisely, the local TGS needs to have a Ticket ``TKT(C,SVC-R,TGS-R)'', encrypted using the secret key of the remote service, and build an ``EncTGSRepPart'' (As defined in [RFC4120]) that contains the key K(C,SVC-R). EncTGSRepPart is built by TGS-L, it is encrypted using the session key ``K(C,TGS-L)''. The key ``K(C,SVC-R)'' and the associated ticket ``TKT(C,SVC-R,TGS-R)'' are built by the remote TGS and sent to the local TGS in a secure manner . Once these components are received, TGS-L can build a TGS-REP message containing the credentials requested by the client. The XTGSP protocol uses PKINIT [RFC4556] to maintain inter-realm keys used to secure the XTGSP exchanges. The PKINIT specification was designed for performing public-key authentication between a client and the KDC when the client and the KDC do not share long term secret key. The local TGS uses PKINIT when there is no inter-realm key, represented as K(L,R), between the local and the remote realm. Concerning the use of PKINIT, we distinguish two cases depending on Zrelli, et al. Expires September 5, 2007 [Page 12] Internet-Draft XTGSP March 2007 whether TGS-L and TGS-R share inter-realm key (represented as K(L,R)) or not. If the inter-realm key exists then it is used to secure the XTGSP exchange, and PKINIT is not used. If the key does not exist, then the the PKINIT extension is used to secure the XTGSP exchange and generate a new inter-realm key between TGS-L and TGS-R. Zrelli, et al. Expires September 5, 2007 [Page 13] Internet-Draft XTGSP March 2007 5. Details of the XTGSP protocol In the following we assume that a client C located in a realm L wishes to access a service SVC-R deployed in a remote realm R, and that the client C has a TGT for the TGS of the local realm L (TGS-L). We explain in this section how the XTGSP extension can be used to allow the client C to obtain a service ticket ``TKT(C,SVC-R,TGS-R)'' and the associated session from TGS-L. The operations of the XTGSP protocol differs depending on whether an inter-realm key between TGS-L and TGS-R exists. We distinguish two cases : Case 1 : When inter-realm key ``K(L,R)'' between the two realms exists o C -> TGS-L : TGS-REQ TGS-REQ = cname, sname, srealm, options, times, TKT(C,TGS-L,AS-L), Auth(C,TGS-L) The client starts by sending a TGS-REQ (as defined in [RFC4120]) to the local TGS (TGS-L) asking for credentials required to access a certain remote service (SVC-R). The TGS-REQ message includes a TGT for TGS-L ``TKT(C,TGS-L,KDC-L)'' and an Authenticator. The client asks its local KDC for service tickets independently whether these services belong to the local realm or not. The difference with [RFC4120] consists of the fact that the client MUST fill the cname field of the TGS-REQ message. [RFC4120] specifies that this field is left empty in TGS-REQ messages. In order to build the TGS-REQ message, the client needs to know the principal name of the desired service and the associated realm name. o TGS-L -> TGS-R : XTGSP-REQ XTGSP-REQ = TGS-REQ, Auth(TGS-L,TGS-R) TGS-L starts by verifying the authenticator and the TGT. If the verification succeeds then is processes the request as follows: If TGS-L received a TGS-REQ for a service that is registered in a remote realm R (information provided by the client in 'srealm') it initiates an XTGSP exchange by issuing an XTGSP-REQ message to the TGS of the remote realm (TGS-R). The XTGSP-REQ message consists of a copy of the client's TGS-REQ message and an Authenticator. The Authenticator contains a time-stamp and a check-sum over the TGS-REQ message. It is encrypted using the inter-realm key ``K(L,R)''. The Authenticator ensures replay protection as well Zrelli, et al. Expires September 5, 2007 [Page 14] Internet-Draft XTGSP March 2007 as message integrity and authentication. o TGS-R -> TGS-L : XTGSP-REP XTGSP-REP = TKT(C,SVC-R,TGS-R), EncTGSRepPart EncTGSRepPart = { SK(C,SVC-R), options, times }_K(L,R) The remote TGS verifies the authenticator and builds an XTGSP-REP message. The XTGSP-REP message consists of two main parts: a Ticket and an EncTGSRepPart (see [RFC4120] for details about these components). The Ticket (more precisely, the EncTicketPart of the Ticket) is encrypted using the secret key of the service SVC-R ``K(SVC-R,TGS-R)'', shared with TGS-R. The EncTGSRepPart is encrypted using the inter-realm key ``K(L,R)'' shared between TGS-L and TGS-R. Both the Ticket and the EncTGSRepPart contain a session-key ``SK(C,SVC-R)''. This session-key will be shared between the client and the service. o TGS-L -> C : TGS-REP TGS-REP = TKT(C,SVC-R,TGS-R), EncTGSRepPart EncTGSRepPart = { SK(C,SVC-R), options, times }_SK(C,TGS-L) TGS-L extracts and decrypts the EncTGSRepPart from the XTGSP-REP message using the inter-realm key ``K(L,R)'', then encrypts it using the TGS session key shared with the client ``SK(C,TGS-L)''. A TGS-REP message is then built using the newly generated EncTGSRepPart and the Ticket as received from TGS-R. Finally, the client processes this TGS-REP message as specified in [RFC4120]. Case 2 : When there is no inter-realm key shared between L and R o C -> TGS-L : TGS-REQ TGS-REQ = cname, sname, srealm, options, times, TKT(C,TGS-L,AS-L), Auth(C,TGS-L) The behavior of the client is the same whether the local and the remote realms share inter-realm key or not. The client thus sends TGS-REQ message as described in "Case 1". o TGS-L -> TGS-R : XTGSP-REQ XTGSP-REQ = TGS-REQ, PA-PK-AS-REQ When TGS-L receives a TGS-REQ for a service that is registered in Zrelli, et al. Expires September 5, 2007 [Page 15] Internet-Draft XTGSP March 2007 a remote realm R, it initiates an XTGSP exchange by issuing an XTGSP-REQ message to the TGS of the remote realm (TGS-R). The XTGSP-REQ consists of the client's TGS-REQ message to which a PA- PK-AS-REQ (a PKINIT request) is added. The PA-PK-AS-REQ contains a check-sum over the TGS-REQ message and time-stamps. It is signed using the public-key of TGS-L. The PA-PK-AS-REQ ensures replay protection as well as message integrity and authentication. o TGS-R -> TGS-L : XTGSP-REP XTGSP-REP = TKT(C,SVC-R,TGS-R), EncTGSRepPart, PA-PK-AS-REP EncTGSRepPart = { SK(C,SVC-R), options, times }_K(L,R) The remote TGS verifies the PA-PK-AS-REQ and builds an XTGSP-REP message which consists of two main parts: The Ticket and an EncTGSRepPart. The Ticket (more precisely, the EncTicketPart of the Ticket) is encrypted using the secret key of the service SVC (shared with TGS-R). The EncTGSRepPart is encrypted using a newly generated inter-realm key ``K(L,R)''. Both the Ticket and the EncTGSRepPart contain a session-key field. The remote TGS puts the key ``SK(C,SVC-R)'' in the key field of each component. The XTGSP-REP message also contains a PA-PK-AS-REP (a PKINIT reply). The PA-PK-AS-REP contains the newly generated inter-realm key ``K(L,R)''. It is encrypted using the public key of TGS-L, and signed using the private key of TGS-R. o TGS-L -> C : TGS-REP The local TGS decrypts the PA-PK-AS-REP using its public key and verifies the signature of TGS-R. The inter-realm key ``K(L,R)'' is then extracted from the PA-PK-AS-REP and used to decrypt the EncTGSRepPart of the XTGSP-REP message. The EncTGSRepPart is then encrypted using the session-key ``SK(C,TS-L)'' shared with the client. The EncTGSRepPart and the Ticket (as provided by the remote TGS) are used to build a TGS-REP message for the client. Zrelli, et al. Expires September 5, 2007 [Page 16] Internet-Draft XTGSP March 2007 6. Security considerations [RFC4120] highlights several security considerations. Most of these considerations apply to a Kerberos KDC implementing the XTGSP extension. The current version of the document does not analyze possible security threats and considerations introduced by the XTGSP extension. Zrelli, et al. Expires September 5, 2007 [Page 17] Internet-Draft XTGSP March 2007 7. Normative References [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4537] Zhu, L., Leach, P., and K. Jaganathan, "Kerberos Cryptosystem Negotiation Extension", RFC 4537, June 2006. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. Zrelli, et al. Expires September 5, 2007 [Page 18] Internet-Draft XTGSP March 2007 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 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 September 5, 2007 [Page 19] Internet-Draft XTGSP March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Zrelli, et al. Expires September 5, 2007 [Page 20]