--- /dev/null
+
+
+
+
+
+
+Network Working Group Ken'ichi Kamada
+INTERNET-DRAFT Shoichi Sakane
+Expires: January 10, 2008 Yokogawa Electric Corporation
+ July 9, 2007
+
+
+ Client-Friendly Cross-Realm Model for Kerberos 5
+ draft-kamada-krb-client-friendly-cross-02.txt
+
+
+
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft expires on January 10, 2008.
+
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+Kamada and Sakane [Page 1]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+Abstract
+
+ This document proposes a cross-realm traversal model, which is
+ suitable for resource-limited clients, for Kerberos Version 5. This
+ model provides a way to move the cost of consecutive Ticket-Granting
+ Service (TGS) exchanges from clients to Key Distribution Centers
+ (KDCs) and a way to reduce the traversal cost by generating a direct
+ inter-realm relationship between two realms. The document describes
+ behavior of clients and KDCs, but does not specify any wire format,
+ which need to be specified separately.
+
+
+Table of Contents
+
+ 1. Introduction ................................................. 3
+ 2. Problems on Client Performance ............................... 3
+ 2.1. Long Authentication Path ................................ 4
+ 2.2. Client-Centric Ticketing ................................ 4
+ 3. Proposal of Client-Friendly Cross-Realm Model ................ 4
+ 3.1. Temporary Inter-Realm Relationship Generation Mode ...... 5
+ 3.2. Attorney Ticketing Mode ................................. 6
+ 3.3. Combination of the Two Modes ............................ 7
+ 4. Advantage of The Proposed Model for Deployment ............... 8
+ 4.1. Compatibility with Traditional Kerberos Deployment ...... 8
+ 4.2. Orthogonality of the Two Modes .......................... 8
+ 5. Front-End Protocol for Attorney Ticketing Mode ............... 9
+ 6. Related Protocols Currently Proposed ......................... 10
+ 6.1. PKCROSS ................................................. 10
+ 6.2. XTGS .................................................... 10
+ 7. Interoperability Considerations .............................. 10
+ 8. Security Considerations ...................................... 11
+ 8.1. Denial of Service (DoS) ................................. 11
+ 8.2. Ticketing Policy ........................................ 11
+ 9. IANA Considerations .......................................... 12
+ 10. Acknowledgments .............................................. 12
+ 11. References ................................................... 12
+ 11.1. Normative References ................................... 12
+ 11.2. Informative References ................................. 12
+ Authors' Addresses ............................................... 13
+ Full Copyright Statement ......................................... 13
+ Intellectual Property Statement .................................. 13
+
+
+
+
+
+
+
+
+
+
+Kamada and Sakane [Page 2]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+1. Introduction
+
+ Kerberos Version 5 [RFC4120] has a concept of cross-realm
+ authentication so that principals in different realms can
+ authenticate each other. However in the current cross-realm model,
+ each client has to traverse the authentication path, and the burden
+ of the traversal is not negligible for clients with limited
+ resources, e.g., computational speed or power supply [CRPS].
+
+ In the current cross-realm operation, a client obtains a service
+ ticket for a remote principal in the following steps:
+
+ 1) N TGSes to get cross-realm TGTs in order to traverse the
+ intermediate realms, where N is the number of transit, and
+
+ 2) One TGS to get the final service ticket.
+
+ That is, the client needs to perform N + 1 transactions to obtain a
+ ticket for the remote service.
+
+ This document proposes a new cross-realm model, which consists of
+ "temporary inter-realm relationship generation mode" and "attorney
+ ticketing mode". The former is intended to reduce transit cost
+ itself, and the latter is to move the cost from clients to KDCs. The
+ document describes behavior of clients and KDCs, but does not specify
+ any wire format, which need to be specified separately.
+
+ Terms defined in section 1.7 of RFC 4120 are used throughout this
+ document.
+
+
+2. Problems on Client Performance
+
+ In the current model of cross-realm operation, a client has to
+ transit all realms on the path to the destination realm. When the
+ source realm and the destination realm have a direct inter-realm
+ relationship, a client is able to obtain a service ticket with two
+ TGS transactions (one for a cross-realm TGT and another for the
+ service ticket). When the realms have a multi-hop relationship, a
+ client must transit the intermediate realms before it obtains the
+ service ticket. That is, the client's task increases in proportion
+ to the distance of the relationship.
+
+ Two issues can be observed here behind the client load, which are
+ described in the following subsections.
+
+
+
+
+
+
+Kamada and Sakane [Page 3]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+2.1. Long Authentication Path
+
+ When a client wants to get a service ticket for a remote realm, it
+ must transit to the remote realm by traversing the intermediate
+ realms on the authentication path to the remote realm. The result of
+ traversal is cached as a cross-realm TGT, but it is nothing more than
+ a per-client optimization. Thus all clients accessing a remote realm
+ must pay the cost separately, even if their resources are limited.
+ For a long authentication path, the cost of the whole system becomes
+ large.
+
+2.2. Client-Centric Ticketing
+
+ In Kerberos, any service tickets or cross-realm TGTs are issued via
+ TGS, where a client present a ticket for the TGS and obtains a next
+ ticket. Currently, all TGS transactions are initiated by the client
+ and it needs to get all necessary cross-realm TGTs iteratively before
+ the final service ticket. This process is a burden to a resource-
+ limited client.
+
+
+3. Proposal of Client-Friendly Cross-Realm Model
+
+ In this section, two modes of operation are introduced, "Temporary
+ Inter-Realm Relationship Generation Mode" and "Attorney Ticketing
+ Mode", to solve the issues described in the previous section. These
+ two modes are designed to be independent, that is, can be used
+ separately or in combination.
+
+ Temporary Inter-Realm Relationship Generation Mode solves the issue
+ of the long authentication path. In this mode, if the source realm
+ and the destination realm do not have a direct inter-realm
+ relationship, the source KDC traverses the authentication path by
+ itself, contacts with the remote KDC, and generates a direct inter-
+ realm relationship between them. After that, the source KDC can
+ issue direct inter-realm TGTs for the destination realm. The purpose
+ of this mode is to reduce the traversal cost itself by caching the
+ result of traversal.
+
+ Attorney Ticketing Mode solves the issue of the client-centric
+ ticketing. Consecutive TGS transactions to get cross-realm TGTs
+ and/or a final service ticket are initiated by a client in the
+ traditional Kerberos, whereas a KDC undertake that process in this
+ mode. The purpose of this mode is to shift the cost of TGSes from a
+ client to a KDC. This does not reduce the cost itself.
+
+
+
+
+
+
+Kamada and Sakane [Page 4]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+3.1. Temporary Inter-Realm Relationship Generation Mode
+
+ Temporary inter-realm relationship generation mode enables a KDC to
+ issue an inter-realm TGT directly to a remote KDC with which the KDC
+ doesn't preshare an inter-realm key. To issue an inter-realm TGT
+ directly, a temporary inter-realm key needs to be provided somehow.
+ To achieve that, the local KDC obtains a special ticket for the
+ remote KDC and uses its session key as an inter-realm key. This
+ methodology was introduced by PKCROSS [PKCROSS]. In this document,
+ that special ticket is called as an "inter-KDC ticket", and an inter-
+ realm TGT generated from an inter-KDC ticket is called as a "direct
+ inter-realm TGT".
+
+ How does the local KDC reach the remote KDC is out of scope of this
+ model, but we can easily come up with 1) traversing a long
+ authentication path if available or 2) using PKINIT. In the context
+ of this model, PKCROSS is interpreted as a combination of this mode
+ and PKINIT.
+
+ This document does not standardize a specific protocol, but an inter-
+ KDC ticket will have the following form:
+
+ - its sname has a special form (PKCROSS proposes
+ "pkcross/realm@REALM", but it would be better to use a more
+ general name than "pkcross"),
+
+ and a direct inter-realm TGT will have the following form:
+
+ - its TicketExtensions field [KRBEXT] contains the inter-KDC ticket,
+ and
+
+ - it is protected by the session key (or the sub-session key) of the
+ inter-KDC ticket.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamada and Sakane [Page 5]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+ client C KDC-L KDC-I KDC-R
+ -------- ----- ----- -----
+
+ 1. --------TGS-REQ-------->
+ 2. [Reach to KDC-R in any way.]
+ [Below is an example of PKCROSS.]
+ ------------PKINIT------------>
+ <----------XTKT(L,R)-----------
+ 3. <--TKT(C,R)w/XTKT(L,R)--
+ 4. ----------------------TGS-REQ------------------------>
+ 5. <---------------------TKT(C,S)------------------------
+
+ [Note: TKT(x,y) means a ticket whose cname is x and sname is y. ]
+ [ XTKT is an inter-KDC ticket. See PKCROSS. ]
+ [ The client C and KDC-L belong to the local realm L. ]
+ [ The KDC-I is a KDC of an intermediate realm I. ]
+ [ The KDC-R is a KDC of the remote realm R. ]
+
+ 1. The client C sends a normal TGS-REQ to KDC-L, requesting
+ a cross-realm TGT to KDC-R.
+ 2. KDC-L reaches KDC-R in any way and obtains a XTKT.
+ There is no standardized way to achieve this step yet.
+ PKCROSS is one candidate. We could also standardize a way
+ in which KDC-L normally transits to KDC-R and obtains an XTKT.
+ 3. KDC-L generates a cross-realm TGT that is from C to KDC-R
+ and returns to it to C.
+ 4. The same with the traditional cross-realm TGS.
+ 5. The same with the traditional cross-realm TGS.
+
+ Figure 1: Message Flow of Temporary Inter-Realm Relationship
+ Generation
+
+3.2. Attorney Ticketing Mode
+
+ Traditionally, a Kerberos client repeats TGS transactions until it
+ gets the final ticket. For example, it has a TGT for its own realm
+ and wants to get a ticket for a service in 3-hop neighbor realm, then
+ it will:
+
+ 1) Present the TGT and get a cross-realm TGT for the next realm,
+
+ 2) Present the 1st cross-realm TGT and get a cross-realm TGT for the
+ 2nd next realm,
+
+ 3) Present the 2nd cross-realm TGT and get a cross-realm TGT for the
+ final realm, and
+
+
+
+
+
+Kamada and Sakane [Page 6]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+ 4) Present the final cross-realm TGT and get a service ticket.
+
+ Attorney ticketing mode enables the client to delegate the KDC to
+ perform all transactions listed above on behalf of the client. An
+ example message flow is shown in Figure 2. The client entrust the
+ KDC with its TGT (step 1). The KDC "impersonates" the client and
+ performs all necessary TGS transactions (steps 2 to 4), and returns
+ the final ticket to the client (step 5).
+
+ client C KDC-L KDC-I KDC-R
+ -------- ----- ----- -----
+
+ 1. --------TGS-REQ-------->
+ 2. TKT(C,I)
+ 3. ----TGS-REQ---->
+ <---TKT(C,R)----
+ 4. ------------TGS-REQ----------->
+ <-----------TKT(C,S)-----------
+ 5. <-------TKT(C,S)--------
+
+ 1. The client C sends a special TGS-REQ, which indicates attorney
+ ticketing mode requesting a service ticket for a server S
+ instead of a cross-realm TGT, to KDC-L.
+ 2. KDC-L internally generates a cross-realm TGT that is from C
+ to KDC-I, but does not return it to C.
+ 3. KDC-L uses the generated cross-realm TGT by itself, and sends
+ a TGS-REQ to KDC-I, which requests a cross-realm TGT from C
+ to KDC-R.
+ 4. KDC-L use the obtained cross-realm TGT by itself, and sends
+ a TGS-REQ to KDC-R, which requests a service ticket from C
+ to S.
+ 5. KDC-L returns the final service ticket to C.
+
+ Figure 2: Message Flow of Attorney Ticketing Mode
+
+3.3. Combination of the Two Modes
+
+ Figure 3 shows a typical message flow when the temporary inter-realm
+ relationship generation mode and the attorney ticketing mode are used
+ in combination. The figure shows the case of the initial contact, so
+ a transaction to obtain an inter-KDC ticket is shown (step 2), but it
+ is infrequently used because the XTKT is cached. Usually, only two
+ round-trips do all the work.
+
+
+
+
+
+
+
+
+Kamada and Sakane [Page 7]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+ client C KDC-L KDC-I KDC-R
+ -------- ----- ----- -----
+
+ 1. --------TGS-REQ-------->
+ 2. [Temporary inter-realm relationship
+ generation mode runs here.]
+ ------------PKINIT------------>
+ <----------XTKT(L,R)-----------
+ 3. [Attorney ticketing mode runs here.]
+ TKT(C,R)w/XTKT(L,R)
+ 4. ------------TGS-REQ----------->
+ <-----------TKT(C,S)-----------
+ 5. <-------TKT(C,S)--------
+
+ Figure 3: Message Flow When Temporary Inter-Realm Relationship
+ Generation Mode and Attorney Ticketing Mode
+ Are Combined
+
+
+4. Advantage of The Proposed Model for Deployment
+
+4.1. Compatibility with Traditional Kerberos Deployment
+
+ Temporary inter-realm relationship generation involves only KDCs.
+ From the viewpoint of a client (and a server), it seems that there is
+ a direct inter-realm relationship between two realms. This means
+ that temporary inter-realm relationship generation mode needs to be
+ deployed only in KDCs. This property is advantageous, because it
+ does not affect large installed base of clients. One impeding factor
+ in practice is that some existing implementations cannot handle
+ ticket extensions transparently. This is further discussed in
+ Interoperability Considerations section.
+
+ Attorney ticketing mode involves only a client and its local KDC.
+ From the viewpoint of the remote KDC, TGS-REQs from a KDC as an
+ attorney cannot be distinguished from those from a "genuine" client
+ (except caddr; see Interoperability Considerations section).
+ Resulting service ticket is identical to the traditional one, so the
+ remote server has nothing to do with this mode. In short, attorney
+ ticketing mode can be deployed in local realm, independently of the
+ remote deployment. The merit of this property is large, because
+ remote realms are often in different administration.
+
+4.2. Orthogonality of the Two Modes
+
+ Temporary inter-realm relationship generation mode and attorney
+ ticketing mode are independent concepts. Both can be implemented
+ separately or can be used in combination. When they are combined,
+
+
+
+Kamada and Sakane [Page 8]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+ the load of clients are shifted to KDCs and additional load of KDCs
+ are minimized, thus efficient cross-realm environment is achieved.
+
+
+5. Front-End Protocol for Attorney Ticketing Mode
+
+ This document does not specify wire-level protocol, which will be
+ done in another document. This section provides some candidates for
+ the protocol, which is used to request attorney ticketing mode from a
+ KDC (Figure 4). This protocol can be used for other than attorney
+ ticketing mode, as long as the KDC's behavior for clients is
+ identical to the mode.
+
+ +------+ +-------+
+ |client|------------>| KDC |-------------> cross-realm cloud
+ +------+ +-------+ Cross-realm
+ Front-end protocol traversal by KDC
+ to request a final (Attorney Ticketing Mode)
+ ticket in one shot
+ or
+
+ -------------> remote KDC (directly)
+ XTGSP
+
+ or
+
+ ------------->
+ Whatever the KDC chooses
+
+ Figure 4: Front-End Protocol for Attorney Ticketing Mode
+
+ Candidate 1: Implicit Signaling
+
+ A client simply requests a final ticket to the local KDC. If the
+ KDC supports this implicit protocol, it will process the request.
+ If not, KDC_ERR_S_PRINCIPAL_UNKNOWN will be returned. A possible
+ drawback is that if a requested final ticket is for a TGS, the KDC
+ does not know whether the client expects normal mode or attorney
+ mode. In addition, implicit signaling can conflict with future
+ extensions.
+
+ Candidate 2: Explicit Signaling
+
+ A flag in KDCOptions or pre-authentication can be used to request
+ attorney mode.
+ [[what happens if not supported?]]
+
+
+
+
+
+Kamada and Sakane [Page 9]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+6. Related Protocols Currently Proposed
+
+6.1. PKCROSS
+
+ PKCROSS will be usable as a protocol for temporary inter-realm
+ relationship generation mode.
+
+6.2. XTGS
+
+ The purpose of XTGS protocol is similar to that of this model, but
+ the behavior is somewhat different [XTGS]. If XTGS is viewed from
+ the perspective of this model, it blends the two modes indivisibly to
+ reduce the number of messages between KDCs as far as possible at the
+ price of the abstraction of cross-realm TGTs and inter-KDC tickets.
+
+ Once a front-end (i.e., between a client and a KDC) protocol to
+ request attorney ticketing mode is standardized, XTGS can be used as
+ an opaque back-end.
+
+
+7. Interoperability Considerations
+
+ User-to-user mode
+ The protocol for the attorney mode should be able to indicate
+ user-to-user authentication.
+
+ The addresses field in TGS-REQ
+ This field is copied into the caddr field in EncTicketPart, so if
+ this field is used in a TGS-REQ, the resulting ticket can be used
+ only from the specified addresses. When the local KDC receives a
+ TGS-REQ requesting attorney mode, it should copy the addresses
+ field only into the final TGS-REQ in the attorney process. It
+ must not copy the field into TGS-REQs to intermediate KDCs,
+ because resulting tickets are to be used by the local KDC instead
+ of the client.
+
+ Opacity of ticket extensions
+ The ticket extensions defined in rfc1510ter [KRBEXT] extends the
+ Ticket ASN.1 type, which is visible to clients. This is not a
+ problem if a client implementation treats a Ticket as an opaque
+ data, and there are such implementations, but unfortunately the
+ major free implementations do not. On the other hand, there is a
+ proposal of etype-based ticket extensions [TKTEXTALT]. It
+ encapsulates cleartext bits in the enc-part component of a Ticket.
+ It should not have any problems of opacity.
+
+ [[negotiation of various parameters]]
+
+
+
+
+Kamada and Sakane [Page 10]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+ [[If there are multiple authentication paths and a client has enough
+ knowledge, it could choose which path to take. With attorney
+ ticketing mode, it cannot because it is up to the KDC to select the
+ path. Is this a problem? With temporary inter-realm relationship
+ generation mode, it can as before.]]
+
+ [[co-existence with the plain Kerberos; attorney ticketing mode
+ client vs. non-attorney KDC; inter-realm generating local KDC vs.
+ non-generating remote KDC]]
+
+ [[anything to do with referral?]]
+
+ [[when a KDC in attorney mode receives a KRB-ERROR?]]
+
+
+8. Security Considerations
+
+8.1. Denial of Service (DoS)
+
+ A KDC that implements attorney ticketing mode needs to initiate
+ multiple TGS-REQ upon a request from a client. This means that the
+ KDC will have some states in it and may suffer from DoS attacks.
+
+ Fortunately, attorney ticketing mode can be requested in TGS-REQ,
+ which is only available to authenticated clients, thus, any untrusted
+ party cannot exploit this statefulness.
+
+8.2. Ticketing Policy
+
+ Attorney ticketing mode changes nothing about the messages sent to
+ the intermediate and remote KDCs. Those KDCs will not notice the
+ difference and their ticketing process have nothing to be changed.
+
+ Temporary inter-realm relationship generation mode dynamically
+ generates new authentication paths. This means that KDCs that are
+ involved in the transit of a client are different from those that
+ would be involved if this mode were not used.
+
+ - Parameters of cross-realm TGTs (lifetime and flags) for a new
+ relationship need to be dynamically transferred (a la PKCROSS).
+
+ - How to handle the transited fields in inter-KDC tickets, direct
+ inter-realm tickets, and service tickets?
+
+ - Where the remote KDC adds AuthorizationData and the end-server
+ checks it: there is no problem because it is a local matter of the
+ remote realm.
+
+
+
+
+Kamada and Sakane [Page 11]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+ - Where an intermediate KDC adds AuthorizationData: traditionally it
+ is added in a cross-realm TGT and propagated to the service
+ ticket; now it will be propagated to the inter-KDC ticket. Should
+ AuthorizationData in an inter-KDC ticket be copied into a cross-
+ realm TGT or not? Even if it is copied, AuthorizationData on
+ inter-KDC ticket cannot represent per-client information, so if it
+ is necessary, temporary inter-realm relationship generation mode
+ must not be used.
+
+
+9. IANA Considerations
+
+ This document has no actions for IANA.
+
+
+10. Acknowledgments
+
+ The authors would like to acknowledge Saber Zrelli, Masahiro
+ Ishiyama, Atsushi Inoue, Kazunori Miyazawa, and Nobuo Okabe for
+ contributions to this document.
+
+
+11. References
+
+11.1. Normative References
+
+ [KRBEXT] Yu, T., "The Kerberos Network Authentication Service
+ (Version 5)", draft-ietf-krb-wg-rfc1510ter-04, Work in
+ Progress, March 2007.
+
+ [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+ Kerberos Network Authentication Service (V5)", RFC
+ 4120, July 2005.
+
+11.2. Informative References
+
+ [CRPS] Sakane, S., Zrelli, S., M. Ishiyama, "Problem statement
+ on the cross-realm operation of Kerberos in a specific
+ system", draft-sakane-krb-cross-problem-statement-02,
+ Work in Progress, April 2007.
+
+ [PKCROSS] Hur, M. et al., "Public Key Cryptography for Cross-
+ Realm Authentication in Kerberos", draft-ietf-cat-
+ kerberos-pk-cross-08 (expired), Work in Progress,
+ November 2001.
+
+ [TKTEXTALT] Message-ID: <tslfy54akcb.fsf@mit.edu>.
+
+
+
+
+Kamada and Sakane [Page 12]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+ [XTGS] Zrelli, S. et al., "XTGSP, the Inter-TGS protocol for
+ cross-realm operations in Kerberos", draft-zrelli-krb-
+ xtgsp-01, Work in Progress, March 2007.
+
+Authors' Addresses
+
+ Ken'ichi Kamada
+ Shoichi Sakane
+ Yokogawa Electric Corporation
+ 2-9-32 Nakacho, Musashino-shi,
+ Tokyo 180-8750 Japan
+ E-mail: Ken-ichi.Kamada@jp.yokogawa.com,
+ Shouichi.Sakane@jp.yokogawa.com
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+
+
+Kamada and Sakane [Page 13]
+\f
+Internet-Draft Client-Friendly Cross-Realm July 2007
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamada and Sakane [Page 14]
+\f
git.samba.org / samba.git / blobdiff