PANA Working Group H. Tschofenig Internet-Draft Siemens Expires: January 10, 2005 V. Sankhla University of Southern California July 12, 2004 Bootstrapping Kerberos draft-tschofenig-pana-bootstrap-kerberos-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document proposes a mechanism to obtain a Kerberos Ticket Granting Ticket based on a successful EAP authentication and key agreement message exchange. The initial network access authentication procedure based on EAP is ideal for this purpose. This proposal allows Kerberos to be used within a local network without relying on a global Kerberos infrastructure. It should allow an incremental deployment of Kerberos and a wider distribution of Kerberos into roaming environments. Tschofenig & Sankhla Expires January 10, 2005 [Page 1] Internet-Draft Bootstrapping Kerberos July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 5 4. Solution Approach . . . . . . . . . . . . . . . . . . . . . 6 5. What are the advantages? . . . . . . . . . . . . . . . . . . 11 6. What are the disadvanges? . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1 Normative References . . . . . . . . . . . . . . . . . . . 17 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . 20 Tschofenig & Sankhla Expires January 10, 2005 [Page 2] Internet-Draft Bootstrapping Kerberos July 2004 1. Introduction Kerberos (see [RFC1510] and [I-D.ietf-krb-wg-kerberos-clarifications]) is a well-known security protocol which provides authentication, authorization and key distribution and is used to secure a number of protocols - a list too large to mention here. It is widely deployed in enterprise networks where cross-realm authentication is not required at all or only to a certain extend (in a environment with a hierarchical organizational structure). In mobility environments Kerberos is, unfortunately, not widely deployed since AAA protocols (such as RADIUS and DIAMETER), which have different cross-realm (or inter-domain) signaling message exchanges, are heavily used. The security properties of AAA protocols and Kerberos also differ. The EAP key management framework is described in [I-D.ietf-eap-keying]. This proposal tries to combine the two protocols: Kerberos is used within the local network and the AAA protocol is used as part of the network access authentication and for communication between the visited network and the home network. Tschofenig & Sankhla Expires January 10, 2005 [Page 3] Internet-Draft Bootstrapping Kerberos July 2004 2. 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]. Tschofenig & Sankhla Expires January 10, 2005 [Page 4] Internet-Draft Bootstrapping Kerberos July 2004 3. Problem Statement RADIUS [RFC2865] and DIAMETER [RFC3588] are used in an environment where accounting and charging is an important functionality. Kerberos was never designed to provide these features. Kerberos provides cross-realm functionality in a way which is different to EAP/AAA protocols. Even though the cross-realm authentication approach used by Kerberos might provide better security properties (such as denial of service protection) the EAP/AAA is gaining importance. By combining the functionality of AAA protocols (cross-realm/ inter-domain behavior, accounting functionality and the existing AAA infrastructure) with the benefits of Kerberos (support by a number of existing protocols, authorization capabilities, key distribution and protection of messages) a number of advantages can be achieved. Section 3.4.4 of [I-D.iab-research-funding] points to the importance of providing solutions for inter-realm Kerberos deployments: 'The need for scalable inter-domain user authentication is increasingly acute as ad-hoc computing and mobile computing become more widely deployed. Thus, work on scalable mechanisms for mobile, ad-hoc, and non-hierarchical inter-domain authentication would be very helpful.' Tschofenig & Sankhla Expires January 10, 2005 [Page 5] Internet-Draft Bootstrapping Kerberos July 2004 4. Solution Approach At its abstract level this proposal suggests to start with a regular AAA communication which might inludes the usage of EAP [I-D.ietf-eap-rfc2284bis]. EAP acts as a container for a number of authentication and key agreement mechanisms. The AAA infrastructure is used to route, to transport and to secure AAA messages and their payloads. As a result of the network access authentication the user is authenticated to its home AAA server (in the subscription based scenario) and the AAA protocol is ready to exchange collected accounting records. In addition to this exchange the visited network (to which the user's device is attached) receives the gurantee through the execution of the AAA protocol and the AAA infrastructure (roaming agreements etc.) that the home network can be hold liable for the payment for the consumed resources by the end user. Subsequently to a successful authentication and authorization the AAA protocol does not only transmit a session key to the AAA attendant but also creates a Kerberos Ticket Granting Ticket (TGT). This TGT is only valid for the local network and is sent to the end host. The session key is only sent to the Authenticator and not to the end host whereas the TGT has to be made available to the end host itself. A protocol between the end host and the Authenticator is therefore required to carry the TGT. Using the obtained TGT the user is able to request further service tickets using a standard Kerberos service ticket request. A user might also request service tickets for various applications, to secure infrastructure services (DHCP, SLP, DNS, etc.), to secure QoS signaling protocols (see [RFC3182] for RSVP security based on Kerberos) or might even request a service ticket to subsequently execute KINK [I-D.ietf-kink-kink] for the purpose of establishing IPsec security associations. Figure 1 shows a typical message exchange executed when an end host moves to a new network. First, in step (1) some sort of address configuration procedure takes place. If the network access authentication procedure is executed as part of the link layer protocol as for example in IEEE 802.11 then address configuration is executed after step (2). The network access procedure (2) might require many roundtrips depending on the authentication and key exchange protocol used. Finally, after a sucessful completion of the protocol exchange a TGT is attached to the final message and send to the end host in step (3). This requires an additional Radius/ Diameter attribute to carry the TGT from the local AAA server (if we assume that it is created at the local AAA server), which is assumed to be co-located with the Kerberos Authentication Server (labeled as KDC in Figure 1). Co-locating these two entities is done mainly for Tschofenig & Sankhla Expires January 10, 2005 [Page 6] Internet-Draft Bootstrapping Kerberos July 2004 simplicity reasons since an additional protocol would be required for commuication rather than an API call. The TGT must, additionally, be sent from the AAA attendant to the end host. Subsequently Kerberos service tickets can be requested using the standard Kerberos message exchange (step (4)). FOR DISCUSSION: Should we create o a Ticket Granting Ticket which is sent to the end host or o bootstrap a security association (and in particular a session key) which is then used by the end host to request the Ticket Granting Ticket. The latter approach would not modify the inital TGT Kerberos exchange. Further issues are discussed in Section 8. EAP acts as a container for a number of authentication and key exchange protocols. As such some observations have to be made concerning the properties of the used mechanisms: Since the Ticket Granting Ticket has to include the AAA distributed session key (key field in the encrypted part of the ticket) this proposal requires an EAP mechanism which provides session key distribution. This session key is then used by the end host to create an Authenticator for a subsequent service ticket requests. Tschofenig & Sankhla Expires January 10, 2005 [Page 7] Internet-Draft Bootstrapping Kerberos July 2004 +----+ +----------+ +------+ +----+ | | | AAA | |AAAL +| | | |Host| | Attendant| | KDC | |AAAH| +-+--+ +-----+----+ +--+---+ +-+--+ | | | | +-----------------+ | | | | Address | | | | | Configuration | | | | | Procedure (1) | | | | +-----------------+ | | | | | | | +--+-------------------+----------------+----------------+--+ | | Network Access Authentication | | | | and | | | | Session key distribtion based on | | | |<------------- successful authentication (2) ------>| | | | | | | | Ticket Granting Ticket | | | | Delivery (3) | | | |<-----------------------------------+ | | | | | | +--+-------------------+----------------+----------------+--+ | | | | +-------------------+----------------+ | | Standard Kerberos Service Ticket | | | Request/Reply (TGS_REQ/TGS_REP) | (4) | +-------------------+----------------+ | | | | | Figure 1: Message Flow Figure 2 shows a Ticket Granting Ticket with the relevant fields. The ticket consists of two parts - one unencrypted and an encrypted part. The unencrypted part contains only information for the recepient (in our case for the Ticket Granting Server) to be able to recognize a ticket for which a key to decrypt the ticket is available. In the described case these fields contain the ticket version number, the realm name of the visited network and the principal name of the Ticket Granting Server (TGS). The remaining fields of the ticket are encrypted with the key known only to the TGS and the Authentication Server (AS). Note that the AS is co-located with the local AAA server in our scenario. The encrypted part of the ticket contains information about the user's realm and its identity which are obtained from the initial authentication procedure. The flags field contains a flag which provides an indication of this Kerberos bootstrapping procedure to differentiate it to a regular AS_REQ/AS_REP exchange. The key field is important since it contains the session key distributed during the initial authentication Tschofenig & Sankhla Expires January 10, 2005 [Page 8] Internet-Draft Bootstrapping Kerberos July 2004 procedure as described in Figure 1 in step (2). This session key is subsequently only relevant for the TGS. For service authentication between the end host and application servers and new service ticket has to be requested from the TGS using a standard Kerberos TGS_REQ/ TGS_REP message exchange. Note that a protocol is required to carry the EAP messages and the TGT from the AAA attendant to the end host. Such a protocol is required to exchange the necessary parameters. This document does not mandate a particular protocol. However, PANA [I-D.ietf-pana-pana] is suitable for this purpose since it is a flexbile and extensible protocol and allows the secure exchange of parameters between the end host and the network. +-------------------------------------------------+ Unencrypted | Ticket Version Number | part of | Realm that issued a ticket | the ticket | Server's Principal Name (sname) | +-------------------------------------------------+ | Flags | | Key | | Realm in which the client is registered (crealm)| | Client's principal identifier (cname) | Encrypted | Transited Realms | part of | Time of initial authentication (authtime) | the ticket | Starttime | (with a key known | Endtime | to the TGS) | Renew-till | | Hostaddress(es) (caddr) | | Authorization-data | +-------------------------------------------------+ Figure 2: Ticket Granting Ticket Content It is important to highlight that the proposal described in this document makes an assumption which has to be satisified in order for this bootstrapping mechanism to work: The authentication and key exchange protocol shown in Figure 1 (step 2) assumes that a session key is distributed and after a successful protocol execution established between the end host and the AAA attendant. The session key distribution with the help of AAA also allows the local AAA server to learn the session key. Since the Ticket Granting Ticket requires a session key to be placed in the Key field as shown in Figure 2. Hence authentication and key exchange protocol which do not establish a session key between the end host and the local network (AAA attendant/local AAA server) cannot be used Tschofenig & Sankhla Expires January 10, 2005 [Page 9] Internet-Draft Bootstrapping Kerberos July 2004 for bootstrapping a Kerberos Ticket Granting Ticket. Additionally it should be noted that the proposed bootstrapping protocol does not necessarily require the execution of a EAP protocol. Protocols such as described in [I-D.perkins-aaav6], in [I-D.mun-aaa-dbu-mobileipv6] and in [I-D.le-aaa-diameter-mobileipv6] would also provide the desired functionality without relying on EAP methods for authentication. Instead a custom authenthication and key exchange protocol is defined. Even the protocols developed in the SACRED working group would provide the necessary pre-requisity to return a Ticket Granting Ticket and to use this proposal. To focus on an increasingly common deployment environment we have focused on EAP. Tschofenig & Sankhla Expires January 10, 2005 [Page 10] Internet-Draft Bootstrapping Kerberos July 2004 5. What are the advantages? The authors think that this proposal has the following advantages: o A large number of protocols support Kerberos as an authentication and key distribution protocol. Enabling Kerberos to be used for these environments would also enable these protocols to be secured with Kerberos. o Initial cross-realm/inter-domain authentication can be done using an arbitrary protocol (in case of EAP). o Kerberos relies on symmetric keys (ignoring PKINIT [I-D.ietf-cat-kerberos-pk-init] and PKCROSS [I-D.ietf-cat-kerberos-pk-cross]) for authentication and key distribution. The usage of symmetric keys is highly efficient and the risk of denial of service attacks often found in public key based protocols is reduced. o Kerberos tickets are designed to allow authorization information to be added to the ticket itself. Authorization information can be added by the KDC and allows services to base their access control policies not only on the identity of the principal. o When passwords are used with Kerberos (without PKINIT or other mechanisms) then there might be a vulnerability to dictionary attacks. Replacing the AS exchange with an EAP authentication this vulnerability can be prevented. Note that this assumes that the chosen EAP method is not vulnerable to dictionary attacks. o Some EAP methods provide user identity confidentiality of the EAP peer against either active or passive adversaries. If a Kerberos Ticket Granting Ticket is created with the help of the EAP derived key and the user identity is not copied to the Ticket Granting Ticket then there is no indication for an eavesdropper about the identity of a user. This approach therefore adds user identity confidentiality to Kerberos. Tschofenig & Sankhla Expires January 10, 2005 [Page 11] Internet-Draft Bootstrapping Kerberos July 2004 6. What are the disadvanges? Despite the advantages listed in the previous section there are some disadvantages or constraints with the following proposal: o A Kerberos implementation has to be supported by end hosts. o Kerberos heavily relies on timestamps. If the clocks of the end host and the various servers in the access network suffer from a clock-drift then some procedure is required for clock- synchronization. Such procedures are for example described in[I-D.ietf-krb-wg-kerberos-clarifications]. It requires further investigation whether a secure time distribution mechanism should be included in this proposal. Tschofenig & Sankhla Expires January 10, 2005 [Page 12] Internet-Draft Bootstrapping Kerberos July 2004 7. Security Considerations The security of the proposed mechanism relies on the selected EAP mechanism, on Kerberos and on the AAA key distribution mechanism. A security analysis of different EAP methods is outside the scope of this document. It is assumed that the AAA key distribution mechanism, the selected EAP method and Kerberos is secure. Hence this section can only describe threats related to the proposed distribution of the TGT. Stealing of the TGT: An adversary might eavesdrop on the wireless link between the end host and the AAA attendant to learn the exchanged TGT. Without confidentiality protection of the TGT an adversary might be able to retrieve the TGT. Since the TGT is encrypted with the key of the ticket granting server (TGS). It is assumed that this key has sufficient length.This assures that an adversary is able to learn the encrypted content of the ticket. Hence we can conclude that an adversary might not be able to request further service tickets only based on the knowledge of the ticket granting ticket. This is inline with the basic principles of Kerberos. Modification of the TGT: An adversary might want to modify the content of the TGT. A TGS would immediately detect such a modification because most parts of the ticket are encrypted. The unencrypted parts only contain information about the TGS and its realm and are useless for an adversary. Replay of the TGT: An adverary (malicious end host) might want to reuse a TGT of a previous message exchange. Since the TGT contains a lifetime field it is not possible to use TGTs with an expired lifetime. In order to request a service ticket the end host has to know the session key to build an Authenticator. Tschofenig & Sankhla Expires January 10, 2005 [Page 13] Internet-Draft Bootstrapping Kerberos July 2004 8. Open Issues This section lists some open issues which have been identified during the work on this approach: o Packet formats (e.g., AAA AVP, PANA AVPs, etc.) are missing. o As an alternative to provide the end host (i.e., user) with a TGT it would be possible to create a tentaive user account at the KDC. This allows the end host to request a TGT and subsequently service tickets. This approach would not require a TGT to be transferred to the end host with the initial AAA exchange. o In order to provide a service ticket to run KINK for achieving secure network access an additional roundtrip is required. Solutions are possible which allow the establishment of an IPsec security association with a fewer number of roundtrips. o Should it be possible to request more than a TGT (for example a service ticket for secure network access) with the help of this proposal? o It might be helpful to have a flag inside the ticket to indicate that the ticket presented to a server was not obtained by a regular AS exchange but rather with this bootstapping mechanism. o It would also be possible to provide the client with a secure network time by protecting the timestamp as part of a PANA exchange. o Should the proposed extension return a full AS_REP instead of only the TGT? This would allow the end host to learn the current time based on the information inside the ticket. The TGT also contains time information but it is not accessible for the end host (i.e. it is included in the encrypted part). o In this proposal the TGT is created at the local AAA server. Therefore the local AAA server needs to wait until a succuessful network access authentication indication is available. The EAP-Success message indicates a succesful EAP method protocol run. Hence, it is necessary for the AAA server to bind the EAP run to the TGT. Furthermore, the local AAA server needs to inspect the session key transferred with the AAA attribute in order to create the TGT. More details need to be provided. It might be possible to create the TGT at the Authenticator itself rather than in the local AAA server. This would, however, cause an increase in the number of entities which need to be trusted by the KDC. Tschofenig & Sankhla Expires January 10, 2005 [Page 14] Internet-Draft Bootstrapping Kerberos July 2004 o Finally, it might be possible to replace this entire bootstrapping mechanism with a new AS_REQ/AS_REP protocol exchange which uses EAP. This exchange could use EAP and the KDC would act as the Authenticator in the EAP architecture. The main advantage of this approach is achieved by protocol separation. A full EAP roundtrip might not be required since the local AAA server might have stored the session key of the previous protocol run already. o Some discussions with regard to the EAP keying framework should go in Section 7. A future version of this document will contain a formal verification of the proposed approach. o The relationship with the work done in the 3GPP Bootstrapping architecture and the SACRED work needs to be described. Tschofenig & Sankhla Expires January 10, 2005 [Page 15] Internet-Draft Bootstrapping Kerberos July 2004 9. Acknowledgments We would like to thank Guenther Horn, Dirk Kroeselberg and Wolfgang Buecker for their comments to this draft. Furthermore, Hannes Tschofenig would like to thank Derek Atkins for discussions with an older version of this draft (more than a year ago). Jorge Cuellar encourage us to publish this document. Tschofenig & Sankhla Expires January 10, 2005 [Page 16] Internet-Draft Bootstrapping Kerberos July 2004 10. References 10.1 Normative References [I-D.ietf-eap-rfc2284bis] Blunk, L., Carlson, J. and B. Aboba, "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004, . [I-D.ietf-pana-pana] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-04 (work in progress), May 2004, . [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003, . 10.2 Informative References [I-D.iab-research-funding] Atkinson, R. and S. Floyd, "IAB Concerns & Recommendations Regarding Internet Research & Evolution", draft-iab-research-funding-03 (work in progress), May 2004, . [I-D.ietf-cat-kerberos-pk-cross] Tsudik, G., Neuman, C., Sommerfeld, B., Tung, B., Hur, M., Ryutov, T. and A. Medvinsky, "Public Key Cryptography for Cross-Realm Authentication in Kerberos", draft-ietf-cat-kerberos-pk-cross-08 (work in progress), November 2001, . [I-D.ietf-cat-kerberos-pk-init] Tschofenig & Sankhla Expires January 10, 2005 [Page 17] Internet-Draft Bootstrapping Kerberos July 2004 Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, J. and J. Trostle, "Public Key Cryptography for Initial Authentication in Kerberos", draft-ietf-cat-kerberos-pk-init-19 (work in progress), April 2004, . [I-D.ietf-eap-keying] Aboba, B., "EAP Key Management Framework", draft-ietf-eap-keying-01 (work in progress), October 2003, . [I-D.ietf-kink-kink] Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", draft-ietf-kink-kink-05 (work in progress), January 2003, . [I-D.ietf-krb-wg-kerberos-clarifications] Neuman, C., "The Kerberos Network Authentication Service (V5)", draft-ietf-krb-wg-kerberos-clarifications-05 (work in progress), February 2004, . [I-D.le-aaa-diameter-mobileipv6] Faccin, S., "Diameter Mobile IPv6 Application", draft-le-aaa-diameter-mobileipv6-03 (work in progress), April 2003, . [I-D.mun-aaa-dbu-mobileipv6] Kim, M. and Y. Mun, "Dynamic Binding Update using AAA", draft-mun-aaa-dbu-mobileipv6-00 (work in progress), December 2002, . [I-D.perkins-aaav6] Perkins, C., Flykt, P. and T. Eklund, "AAA for IPv6 Network Access", draft-perkins-aaav6-06 (work in progress), May 2003, . [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001, . Tschofenig & Sankhla Expires January 10, 2005 [Page 18] Internet-Draft Bootstrapping Kerberos July 2004 Authors' Addresses Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.com Vishal Sankhla University of Southern California 1860N, Fuller Avenue, Apt 117 Los Angeles, California 90046 USA EMail: sankhla@usc.edu Tschofenig & Sankhla Expires January 10, 2005 [Page 19] Internet-Draft Bootstrapping Kerberos July 2004 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 (2004). 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. Tschofenig & Sankhla Expires January 10, 2005 [Page 20]