NFSv4 M. Eisler Internet-Draft NetApp Intended status: Standards Track August 18, 2008 Expires: February 19, 2009 RPCSEC_GSS Version 2 draft-ietf-nfsv4-rpcsec-gss-v2-05.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/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 February 19, 2009. Abstract This Internet-Draft describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as Version 1 but adds support for channel bindings. Requirements Language 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 RFC 2119 [1]. Eisler Expires February 19, 2009 [Page 1] Internet-Draft RPCSEC_GSSv2 August 2008 Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 2. Channel Bindings Explained . . . . . . . . . . . . . . . . . . 3 3. The RPCSEC_GSSv2 Protocol . . . . . . . . . . . . . . . . . . 4 3.1. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . 4 3.2. New Version Number . . . . . . . . . . . . . . . . . . . . 5 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . 6 3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . 9 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 9 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Eisler Expires February 19, 2009 [Page 2] Internet-Draft RPCSEC_GSSv2 August 2008 1. Introduction and Motivation RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version 1 (RPCSEC_GSSv1) [2] except that support for channel bindings [3] has been added. The primary motivation for channel bindings is to securely take advantage of hardware assisted encryption that might exist at lower levels of the networking protocol stack, such as at the Internet Protocol (IP) layer in the form of IPsec (see [6] and [7] for information on IPsec channel bindings). The secondary motivation is that even if lower levels are not any more efficient at encryption than the RPCSEC_GSS layer, if encryption is occurring at the lower level, it can be redundant at the RPCSEC_GSS level. Once an RPCSEC_GSS target and initiator are mutually assured that they are each using the same secure, end to end channel, the overhead of computing message integrity codes (MICs) for authenticating and integrity protecting RPC requests and replies can be eliminated because the channel is performing the same function. Similarly, if the channel also provides confidentiality, the overhead of RPCSEC_GSS privacy protection can also be eliminated. The XDR description is provided in this document in a way that makes it simple for the reader to extract into a ready to compile form. The reader can feed this document into the following shell script to produce the machine readable XDR description of RPCSEC_GSSv2: #!/bin/sh grep "^ *///" | sed 's?^ *///??' I.e. if the above script is stored in a file called "extract.sh", and this document is in a file called "spec.txt", then the reader can do: sh extract.sh < spec.txt > rpcsec_gss_v2.x The effect of the script is to remove leading white space from each line of the specification, plus a sentinel sequence of "///". 2. Channel Bindings Explained If a channel between two parties is secure, there must be shared information between the two parties. This information might be secret or not. The requirement for secrecy depends on the specifics of the channel. For example, the shared information could be the concatenation of the public key of the source and destination of the channel (where each Eisler Expires February 19, 2009 [Page 3] Internet-Draft RPCSEC_GSSv2 August 2008 public key has a corresponding private key). Suppose the channel is not end-to-end, i.e. a man-in-the-middle (MITM) exists, and there are two channels, one from the initiator to the MITM, and one from the MITM to the target. The MITM cannot simply force each channel to use the same public keys, because a public key derives from a private key, and the key management system for each node will surely assign unique or random private keys. At most, the MITM can force one end of each channel to use the same public key. The MIC of the public keys from the initiator will not be verified by the target, because at least one of the public keys will be different. Similarly, the MIC of the public keys from the target will not be verified by the initiator because at least one of the public keys will be different. A higher layer protocol using the secure channel can safely exploit the channel to the mutual benefit of the higher level parties if each higher level party can prove: o They each know the channel's shared information. o The proof of the knowledge of the shared information is in fact being conveyed by each of the higher level parties, and not some other entities. RPCSEC_GSSv2 simply adds an optional round trip that has the initiator compute a GSS MIC on the channel binding's shared information, and sends the MIC to the target. The target verifies the MIC, and in turn sends its own MIC of the shared information to the initiator which verifies the target's MIC. This accomplishes three things. First the initiator and target are mutually authenticated. Second, the initiator and target prove they know the channel's shared information, and thus are using the same channel. Third, the first and second things are done simultaneously. 3. The RPCSEC_GSSv2 Protocol The RPCSEC_GSSv2 protocol will now be explained. The entire protocol is not presented. Instead the differences between RPCSEC_GSSv2 and RPCSEC_GSSv1 are shown. 3.1. Compatibility with RPCSEC_GSSv1 The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2. Eisler Expires February 19, 2009 [Page 4] Internet-Draft RPCSEC_GSSv2 August 2008 3.2. New Version Number /// enum rpc_gss_service_t { /// /* Note: the enumerated value for 0 is reserved. */ /// rpc_gss_svc_none = 1, /// rpc_gss_svc_integrity = 2, /// rpc_gss_svc_privacy = 3, /// rpc_gss_svc_channel_prot = 4 /* new */ /// }; /// /// enum rpc_gss_proc_t { /// RPCSEC_GSS_DATA = 0, /// RPCSEC_GSS_INIT = 1, /// RPCSEC_GSS_CONTINUE_INIT = 2, /// RPCSEC_GSS_DESTROY = 3, /// RPCSEC_GSS_BIND_CHANNEL = 4 /* new */ /// }; /// /// struct rpc_gss_cred_vers_1_t { /// rpc_gss_proc_t gss_proc; /* control procedure */ /// unsigned int seq_num; /* sequence number */ /// rpc_gss_service_t service; /* service used */ /// opaque handle<>; /* context handle */ /// }; /// /// const RPCSEC_GSS_VERS_1 = 1; /// const RPCSEC_GSS_VERS_2 = 2; /* new */ /// /// union rpc_gss_cred_t switch (unsigned int rgc_version) { /// case RPCSEC_GSS_VERS_1: /// case RPCSEC_GSS_VERS_2: /* new */ /// rpc_gss_cred_vers_1_t rgc_cred_v1; /// }; /// Figure 1 As is apparent from the above, the RPCSEC_GSSv2 credential has the same format as the RPCSEC_GSSv1 credential (albeit corrected so that the definition is in legal XDR description language that is also compatible with [8]. Hence the field "version", a keyword in [8], is replaced with rgc_version). By setting the rgc_version field to 2, this indicates that the initiator and target support channel bindings. Eisler Expires February 19, 2009 [Page 5] Internet-Draft RPCSEC_GSSv2 August 2008 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL /// struct rgss2_bind_chan_MIC_in_args { /// opaque rbcmia_bind_chan_hash<>; /// }; /// /// typedef opaque rgss2_chan_pref<>; /// typedef opaque rgss2_oid<>; /// /// struct rgss2_bind_chan_verf_args { /// rgss2_chan_pref rbcva_chan_bind_prefix; /// rgss2_oid rbcva_chan_bind_oid_hash; /// opaque rbcva_chan_mic<>; /// }; /// Figure 2 Once an RPCSEC_GSSv2 handle has been established over a secure channel, the initiator MAY issue RPCSEC_GSS_BIND_CHANNEL (Figure 1). Targets MUST support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be used. Unlike those two requests, the arguments of the NULL procedure are not overloaded, because the verifier is of sufficient size for the purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc were set to RPCSEC_GSS_DATA. The service field is set to rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT. The RPCSEC_GSS_BIND_CHANNEL request is similar to the RPCSEC_GSS_DATA request in that the verifiers of both contain MICs. As described in Section 5.3.1 of [2], when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC request is set to the output of GSS_GetMIC() on the RPC header. When gss_proc is RPCSEC_GSS_BIND_CHANNEL the verifier of an RPC request is set to the XDR encoding on a value of data type rgss2_bind_chan_verf_args, which includes a MIC as described below. The rgss2_bind_chan_verf_args data type consists of three fields: o rbcva_chan_bind_prefix. This is the channel binding prefix as described in [3] up to, but excluding the colon (ASCII 0x3A) that separates the prefix from the suffix. o rbcva_chan_bind_hash_oid. This is the object identifier (OID) of the hash algorithm used to compute rbcmia_bind_chan_hash. This field contains an OID encoded in ASN.1 as used by GSS-API in the mech_type argument to GSS_Init_sec_context ([4]). See [5] for the OIDs of the SHA one-way hash algorithms. Eisler Expires February 19, 2009 [Page 6] Internet-Draft RPCSEC_GSSv2 August 2008 o rbcva_chan_mic. This is the output of GSS_GetMIC() on the concatenation of the XDR encoded RPC header ("up to and including the credential" as per [2]) and the XDR encoding of an instance of type data rgss2_bind_chan_MIC_in_args. The data type rgss2_bind_chan_MIC_in_args consists of one field, rbcmia_bind_chan_hash, which is a hash of the channel bindings as defined in [3]. The channel bindings are a "canonical octet string encoding of the channel bindings", starting "with the channel bindings prefix followed by a colon (ASCII 0x3A)." The reason a hash of the channel bindings and not the actual channel bindings are used to compute rbcva_chan_mic is that some channel bindings, such as those composed of public keys, can be relatively large, and thus place a higher space burden on the implementations to manage. One way hashes consume less space. /// enum rgss2_bind_chan_status { /// RGSS2_BIND_CHAN_OK = 0, /// RGSS2_BIND_CHAN_PREF_NOTSUPP = 1, /// RGSS2_BIND_CHAN_HASH_NOTSUPP = 2 /// }; /// /// union rgss2_bind_chan_res switch /// (rgss2_bind_chan_status rbcr_stat) { /// /// case RGSS2_BIND_CHAN_OK: /// void; /// /// case RGSS2_BIND_CHAN_PREF_NOTSUPP: /// rgss2_chan_pref rbcr_pref_list<>; /// /// case RGSS2_BIND_CHAN_HASH_NOTSUPP: /// rgss2_oid rbcr_oid_list<>; /// }; /// /// struct rgss2_bind_chan_MIC_in_res { /// unsigned int rbcmr_seq_num; /// opaque rbcmr_bind_chan_hash<>; /// rgss2_bind_chan_res rbcmr_res; /// }; /// /// struct rgss2_bind_chan_verf_res { /// rgss2_bind_chan_res rbcvr_res; /// opaque rbcvr_mic<>; /// }; /// Figure 3 Eisler Expires February 19, 2009 [Page 7] Internet-Draft RPCSEC_GSSv2 August 2008 The RPCSEC_GSS_BIND_CHANNEL reply is similar to the RPCSEC_GSS_DATA reply in that the verifiers of both contain MICs. When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC reply is set to the output of GSS_GetMIC() on the seq_num of the credential of the corresponding request (as described in Section 5.3.3.2 of [2]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is set to the XDR encoding of an instance of data type rgss2_bind_chan_verf_res, which includes a MIC as described below. The data type rgss2_bind_chan_verf_res consists of two fields. o rbcvr_res. The data type of this field is rgss2_bind_chan_res. The rgss2_bind_chan_res data type is a switched union consisting of three cases switched on the status contained in the rbcr_stat field. * RGSS2_BIND_CHAN_OK. If this status is returned, the server accepted the channel bindings, and successfully verified rbcva_chan_mic in the request. No additional results will be in rbcvr_res. * RGSS2_BIND_CHAN_PREF_NOTSUPP. If this status is returned, the server did not support the prefix in the rbcva_chan_bind_prefix field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL request was rejected. The server returned a list of prefixes it does support in the field rbcr_pref_list. * RGSS2_BIND_CHAN_HASH_NOTSUPP. If this status is returned, the server did not support the hash algorithm identified in the rbcva_chan_bind_hash_oid field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL request was rejected. The server returned a list of OIDs of hash algorithms it does support in the field rbcr_oid_list. The array rbcr_oid_list MUST have one or more elements. o rbcvr_mic. The value of this field is equal to the output of GSS_GetMIC() on the XDR encoding of an instance of data type rgss2_bind_chan_MIC_in_res. The data type rgss2_bind_chan_MIC_in_res consists of three fields. * rbcmr_seq_num. The value of this field is equal the field seq_num in the RPCSEC_GSS credential (data type rpc_gss_cred_vers_1_t). * rbcmr_bind_chan_hash. This is the result of the one way hash of the channel bindings (including the prefix). If rbcr_stat is not RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm that is used to compute rbcmr_bind_chan_hash is that identified by the rbcva_chan_bind_oid_hash field in the arguments to Eisler Expires February 19, 2009 [Page 8] Internet-Draft RPCSEC_GSSv2 August 2008 RPCSEC_GSS_BIND_CHANNEL. If rbcr_stat is RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm used to compute rbcmr_bind_chan_hash is that identified by rbcr_oid_list[0] in the results. * rbcmr_res. The value of this field is equal to the value of the rbcvr_res field. 3.4. New Security Service - rpc_gss_svc_channel_prot The rpc_gss_svc_channel_prot service (Figure 1) is valid only if RPCSEC_GSSv2 is being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed successfully, and the secure channel still exists. When rpc_gss_svc_channel_prot is used, the RPC requests and replies are similar to those of rpc_gss_svc_none except that the verifiers on the request and reply always have the flavor set to AUTH_NONE, and the contents are zero length. Note that even though NULL verifiers are used when rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are used. In order to identify the principal sending the request, the same credential is used as before, except that service field is set to rpc_gss_svc_channel_prot. 4. Version Negotiation An initiator that supports version 2 of RPCSEC_GSS simply issues an RPCSEC_GSS request with the rgc_version field set to RPCSEC_GSS_VERS_2. If the target does not recognize RPCSEC_GSS_VERS_2, the target will return an RPC error per section 5.1 of [2]. The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 2 of a target with version 1 of the same target. The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 1 of a target with version 2 of the same target. 5. Implementation Notes Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been performed on an RPCSEC_GSSv2 context handle, the initiator's implementation may map application requests for rpc_gss_svc_none and rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And if the secure channel has privacy enabled, requests for rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot. Eisler Expires February 19, 2009 [Page 9] Internet-Draft RPCSEC_GSSv2 August 2008 6. Acknowledgements Nicolas Williams had the idea for extending RPCSEC_GSS to support channel bindings. Alex Burlyga and Lars Eggert reviewed the document and gave valuable feed back for improving its readability. 7. Security Considerations The base security considerations consist of: o All security considerations from [2]. o All security considerations from [3]. o All security considerations from the actual secure channel being used. Even though RPCSEC_GSS_DATA requests that use rpc_gss_svc_channel_prot protection do not involve construction of more GSS tokens, nonetheless, the target SHOULD stop allowing RPCSEC_GSS_DATA requests with rpc_gss_svc_channel_prot protection once the GSS context expires. With the use of channel bindings, it becomes extremely critical that the message integrity code (MIC) used by the GSS mechanism that RPCSEC_GSS is using be difficult to forge. While this requirement is true for RPCSEC_GSSv1, and indeed any protocol that uses GSS MICs, the distinction in the seriousness is that for RPCSEC_GSSv1, forging a single MIC at most allows the attacker to succeed in injecting one bogus request. Whereas, with RPCSEC_GSSv2 combined with channel bindings, by forging a single MIC all the attacker will succeed in injecting bogus requests as long as the channel exists. An example illustrates. Suppose we have an RPCSEC_GSSv1 initiator, a man in the middle (MITM), an RPCSEC_GSSv1 target, and an RPCSEC_GSSv2 target. The attack is as follows. o The MITM intercepts the initiator's RPCSEC_GSSv1 RPCSEC_GSS_INIT message and changes the version number from 1 to 2 before forwarding to the RPCSEC_GSSv2 target, and changes the reply's version number from 2 to 1 before forwarding to the RPCSEC_GSSv1 initiator. Neither the client nor the server notice. o Once the RPCSEC_GSS handle is in an established state, the initiator sends its first RPCSEC_GSS_DATA request. The MITM constructs an RPCSEC_GSS_BIND_CHANNEL request, using the message integrity code (MIC) of the RPCSEC_GSS_DATA request. It is likely the RPCSEC_GSSv2 target will reject the request. The MITM Eisler Expires February 19, 2009 [Page 10] Internet-Draft RPCSEC_GSSv2 August 2008 continues to re-iterate each time the initiator sends another RPCSEC_GSS_DATA request. With enough iterations, the probability of a MIC from an RPCSEC_GSS_DATA being successfully verified in the forged RPCSEC_GSS_BIND_CHANNEL increases. Once the MITM succeeds, it can send RPCSEC_GSS_DATA requests with a security service of rpc_gss_svc_channel_prot, which does not have MICs in the RPC request's verifier. The implementation of RPCSEC_GSSv2 can use at least two methods to thwart these attacks. o The target SHOULD require a stronger MIC (e.g. if HMACs are used for the MICs, require the widest possible HMAC in terms of bit length that the GSS mechanism supports) when sending an RPCSEC_GSS_BIND_CHANNEL request instead of an RPCSEC_GSS_DATA request. If HMACs are being used, and the target expects N RPCSEC_GSS_DATA requests to be sent on the context before it expires, then the target SHOULD require an HMAC for RPCSEC_GSS_BIND_CHANNEL that is log base 2 N bits longer than what it normally requires for RPCSEC_GSS_DATA requests. If a long enough MIC is not available, then the target could artificially limit the number of RPCSEC_GSS_DATA requests it will allow on the context before deleting the context. o Each time an RPCSEC_GSSv2 target experiences a failure to verify the MIC of an RPCSEC_GSS_BIND_CHANNEL request, it SHOULD reduce the lifetime of the underlying GSS context, by a significant fraction, thereby preventing the MITM from using the established context for its attack. A possible heuristic is that the if the target believes the possibility that failure to verify the MIC was because of an attack is X percent, then contexts lifetime would be reduced by X percent. For simplicity, an implement might set X to be 50 percent, so that the context lifetime is halved on each failed verification of an RPCSEC_GSS_BIND_CHANNEL request and thus rapidly reduced to zero on subsequent requests. For example, with a context like time of 8 hours (or 28800 seconds), 15 failed attempts by the MITM would cause the context to be destroyed. A method of mitigation that was considered was to protect the RPCSEC_GSS version number with RPCSEC_GSSv2's RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT tokens. Thus the version number of RPCSEC_GSS would be in the tokens. This method does not completely mitigate the attack; it just moves the MIC guessing to the RPCSEC_GSS_INIT message. In addition without changing GSS, or the GSS mechanism, there is no way to include the RPCSEC_GSS version number in the tokens. So for these reasons this method was not selected. Eisler Expires February 19, 2009 [Page 11] Internet-Draft RPCSEC_GSSv2 August 2008 8. IANA Considerations None. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997. [3] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. [4] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [5] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005. 9.2. Informative References [6] Williams, N., "IPsec Channels: Connection Latching", draft-ietf-btns-connection-latching-07 (work in progress), April 2008. [7] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2 and Public Keys", draft-williams-ipsec-channel-binding-01 (work in progress), April 2008. [8] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995. Eisler Expires February 19, 2009 [Page 12] Internet-Draft RPCSEC_GSSv2 August 2008 Author's Address Mike Eisler NetApp 5765 Chase Point Circle Colorado Springs, CO 80919 US Phone: +1-719-599-9026 Email: mike@eisler.com Eisler Expires February 19, 2009 [Page 13] Internet-Draft RPCSEC_GSSv2 August 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Eisler Expires February 19, 2009 [Page 14]