Network Working Group S. Farrell, Ed. Request for Comments: 3767 Trinity College Dublin Category: Standards Track June 2004 Securely Available Credentials Protocol Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004).
AbstractThis document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Protocol. . . . . . . . . . . . . . . . . . . . . . . . . 3 3. BEEP Profile for SACRED. . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A: XML Schema . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B: An Example of Tuning with BEEP . . . . . . . . . . . . 20 Appendix C: Provision SACRED using other Protocols . . . . . . . . 23 Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 25
RFC3760]. Many user-chosen passwords are vulnerable to dictionary attacks. So the SACRED protocol is designed to give no information with which an attacker can acquire information for launching a dictionary attack, whether by eavesdropping or by impersonating either the client or server. The protocol also allows a user to create or delete an account, change her account password and/or credentials, and upload the new values to the server. The protocol ensures that only someone that knew the old account password is able to modify the credentials as stored on the credential server. The protocol does not preclude configuring a server to disallow some operations (e.g. credential upload) for some users. The account management operations as a whole are optional implementations for both credential servers and clients. Note that there are potentially two "passwords" involved when using this protocol - the first used to authenticate the user to the credential server, and the second to decrypt (parts of) the credential following a download operation. Where the context requires it, we refer to the former as the account password and the latter as the credential password. Using a protocol such as this is somewhat less secure than using a smart card, but can be used until smart cards and smart card readers on workstations become ubiquitous, and can be useful even after smart cards are ubiquitous, as a backup strategy when a user's smart card is lost or malfunctioning. The protocol sets out to meet the requirements in [REQS]. Cryptographic credentials may take the form of private keys, PKCS #15 [PKCS15], or structures. As stated, a profile based on BEEP [BEEP] is specified for message transport and security (integrity,
authentication, and confidentiality). In that case, the security requirements are met by mandating support (via BEEP) for TLS [TLS] and/or DIGEST-MD5 [DIGEST-MD5]. We assume the only authentication information available to the user is a username and password. 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]. XMLSCHEMA]. Appendix A provides an XML schema for these elements. The approach taken here is to define SACRED elements that are compatible with the elements used in [XKMS] and [XMLDSIG], so that an implementation of this protocol can easily also support XKMS, and vice versa. It is also intended that other SACRED protocol instances (e.g. using a different authentication scheme, credential format, or transport protocol) could re-use many of the definitions here.
Clients MUST be able to select one from a list of Realms and MUST be able to disregard any other information present (allowed for extensibility). SASL] mechanism used. The client sends a CreateAccountRequest, which contains the account name (e.g. username). It also contains the elements required to create an account for a particular authentication mechanism. The actual information is defined according to the authentication mechanism. For DIGEST-MD5, this consists of the password verifier (the hashed username, password and realm) and the chosen realm. Although more than one set of such data is allowed by the data structures defined in the appendix, clients SHOULD only include one here. The server responds with an error or acknowledgement message.
The client sends a ModifyAccountRequest message, which contains the elements required to change the authentication information for the account, for a particular authentication mechanism. The actual information is defined according to the authentication mechanism. For [DIGEST-MD5], it will consist of a realm and password verifier value. Once the account information has been changed, the server will respond with an error or acknowledgement message.
The LastModified value in the UploadRequest MUST be the value which was most recently received in a corresponding DownloadResponse for that credential. This means the clients are strongly RECOMMENDED to only produce an UploadRequest based on recently downloaded credentials, since otherwise the LastModified value may be out of date. The LastModified value can also be of use in detecting conflicts. For example, download to platform A, download to platform B, update from B, update from A. The server could detect a conflict on the second upload. In this case the server MUST respond with a BEEP error (which SHOULD be StaleCredential). The server replaces the provided LastModified value with the current time at the server before storing the credential. (Note that this means that it would be unwise for a client to include the LastModified field in a ClientInfo digital signature which is calculated over the CredentialType.) The server responds with an error or acknowledgement message.
The client sends a DeleteRequest message to the server which can contain either a CredentialSelector or an All element. If the DeleteRequest contains an All element, then all of the credentials associated with that account are deleted. If the DeleteRequest contains a CredentialSelector, then the request MAY include a LastModified value. If the LastModified value is present in the DeleteRequest, then it MUST be the value which was most recently received in a corresponding DownloadResponse for that credential. If the value does not match, then the server MUST NOT delete the credentials. If no "matching" credential exists, the server returns an error. The server responds to this request with an error or acknowledgement message.
The mandatory-to-implement TLS cipher suite for SACRED is TLS_RSA_WITH_3DES-EDE_CBC_SHA. Implementations SHOULD also support TLS_RSA_WITH_AES_128_CBC_SHA [TLSAES]. When performing mutual authentication using DIGEST-MD5 for the client, DIGEST-MD5 MUST only be used "within" a TLS server- authenticated "pipe", and MUST only be used for client authentication. That is, we do not use the DIGEST-MD5 security services (confidentiality, integrity etc.). XKMS] and [XBULK]. Where no specific response message is defined for an operation (e.g. for UploadRequest), then the transport will indicate success or failure. All of the response messages defined here MAY contain a Status string, containing a value intended for human consumption.
BEEP] profile. Future memos may define alternative versions of the BEEP profile for SACRED. When a BEEP peer sends its greeting, it indicates which profiles it is willing to support. Accordingly, when the BEEP client asks to start a channel, it indicates the versions it supports, and if any of these are acceptable to the BEEP server; the latter specifies which profile it is starting. Profile Identification: http://iana.org/beep/sacred Messages Exchanged during Channel Creation: InfoRequest, CreateAccountRequest, RemoveAccountRequest, ModifyAccountRequest, DownloadRequest, UploadRequest, DeleteRequest, InfoResponse,
DownloadResponse, error, ok Messages starting one-to-one exchanges: InfoRequest, CreateAccountRequest, RemoveAccountRequest, ModifyAccountRequest, DownloadRequest, UploadRequest, DeleteRequest Messages in positive replies: ok, InfoResponse, DownloadResponse Messages in negative replies: error Messages in one-to-many changes: none Message Syntax: c.f.,Section 3 Message Semantics: c.f., Section 2 Contact Information: c.f., the editor's address section of this memo Section 2.3.1), before starting the SACRED profile, the BEEP session will likely be tuned using either http://iana.org/beep/TLS or http://iana.org/beep/TLS followed by http://iana.org/SASL/DIGEST-MD5 Appendix B gives an example of tuning a BEEP session using DIGEST- MD5 (i.e. it shows how to turn on BEEP security). Regardless, upon completion of the negotiation process, a tuning reset occurs in which both BEEP peers issue a new greeting. Consult Section 3 of [BEEP] for an example of how a BEEP peer may choose to issue different greetings based on whether confidentiality is in use.
Any of the messages listed in section 3.2 below may be exchanged during channel initialization (c.f., Section 184.108.40.206 of [BEEP]), e.g., C: <start number='1'> C: <profile uri='http://iana.org/beep/sacred'> C: <![CDATA[<DownloadRequest ...>]]> C: </profile> C: </start> S: <profile uri='http://iana.org/beep/sacred'> S: <![CDATA[<DownloadResponse ...>]]> S: </profile> Note that BEEP imposes both encoding and length limitations on the messages that are piggybacked during channel initialization. Section 6.4 of [BEEP]): Role MSG RPY ERR ---- --- --- --- I InfoRequest InfoResponse error I CreateAccountRequest ok error I RemoveAccountRequest ok error I ModifyAccountRequest ok error I DownloadRequest DownloadResponse error I UploadRequest ok error I DeleteRequest Ok error Section 220.127.116.11 of [BEEP] is used to convey error information. Typically, after flagging an error, a peer will initiate a graceful release of the BEEP session. The following BEEP error reply codes from [BEEP] are to be used: code Meaning ==== ======= 421 service not available 450 requested action not taken (e.g., lock already in use) 451 requested action aborted (e.g., local error in processing)
454 temporary authentication failure 500 general syntax error (e.g., poorly-formed XML) 501 syntax error in parameters (e.g., non-valid XML) 504 parameter not implemented 530 authentication required 534 authentication mechanism insufficient (e.g., too weak, sequence exhausted, etc.) 535 authentication failure 537 action not authorized for user 538 authentication mechanism requires encryption 550 requested action not taken (e.g., no requested profiles are acceptable) 553 parameter invalid 554 transaction failed (e.g., policy violation) The following SACRED-specific error reply codes can also be used: code Meaning ==== ======= 555 Extension (ProcessInfo) used not supported 556 Required extension (ProcessInfo) not present 557 StaleCredential (A bad LastModified value was contained in an UploadRequest.) Section 4. http://iana.org/beep/sacred The sacred protocol SHOULD be run over port 1118. The GSSAPI service name (required when using SASL) for this protocol SHALL be "sacred".
REQS] calls for specifications to state how they address the vulnerabilities listed below. V1. A passive attacker can watch all packets on the network and later carry out a dictionary attack. - The use of DIGEST-MD5 and/or TLS counters this vulnerability. V2. An attacker can attempt to masquerade as a credential server in an attempt to get a client to reveal information online that allows for a later dictionary attack. - The use of server or mutual authentication counters this vulnerability. V3. An attacker can attempt to get a client to decrypt a chosen "ciphertext" and get the client to make use of the resulting plaintext - the attacker may then be able to carry out a dictionary attack (e.g. if the plaintext resulting from "decryption" of a random string is used as a DSA private key). - The use of server or mutual authentication counters this vulnerability. V4. An attacker could overwrite a repository entry so that when a user subsequently uses what they think is a good credential, they expose information about their password (and hence the "real" credential). - Server implementations SHOULD take measures to protect the database. Clients MAY use the ClientInfo field to store e.g. a signature over the Credential, which they then verify before using the private component. V5. An attacker can copy a credential server's repository and carry out a dictionary attack. - Server implementations SHOULD take measures to protect the database. V6. An attacker can attempt to masquerade as a client in an attempt to get a server to reveal information that allows for a later dictionary attack. - The mutual authentication requirements of this protocol counter this to a great extent. Additionally, credential servers MAY choose to provide mechanisms that protect against online dictionary attacks against user account passwords, either by repeated access attempts to a single user account (varying the password) or by attempting to access many user accounts using the same password. V7. An attacker can persuade a server that a successful login has occurred, even if it hasn't. - Client authentication prevents this.
V8. (Upload) An attacker can overwrite someone else's credentials on the server. - Only if they know the account password already (thanks to mutual authentication). V9. (When using password-based authentication) An attacker can force a password change to a known (or "weak") password. - Client authentication counters this. V10. An attacker can attempt a man-in-the-middle attack for lots of reasons... - Mutual authentication and the encryption of subsequent messages prevents this. V11. User enters password instead of name. - Since the DIGEST-MD5 mechanism is only used after TLS tuning, the user's name is also protected. V12. An attacker could attempt various denial-of-service attacks. - No specific countermeasures against DoS are proposed. If the CreateAccountRequest message were sent over a cleartext channel (or otherwise exposed), then an attacker could mount a dictionary attack and recover the account password. This is why the server authenticated TLS transport is REQUIRED for this operation. If someone steals the server database they can launch a dictionary attack. If the dictionary attack is successful, the attacker can decrypt the user's credentials. An attacker that has learned the user's account password can also upload new credentials, assuming the user is authorized to modify the credentials, because someone who knows the user's account password is assumed to be the user. However, if someone steals the server database and is unsuccessful at obtaining the user's account password through a dictionary attack, they will be unable to upload new credentials. Credential servers SHOULD incorporate measures that act to counter denial of service attacks. In particular, they SHOULD drop inactive connections and minimize the use of resources by un-authenticated connections. A number of recommendations are listed at [DDOS]. Various operations in the SACRED protocol depend upon server authentication being provided by server authenticated TLS. SACRED clients SHOULD take care that the correct server is at the far end of the TLS "pipe" by performing the checks which are listed in section 3.1 of RFC 2818 [RFC2818]. Clients SHOULD also include the optional BEEP serverName field in their "start" message and SHOULD then ensure that the BEEP serverName is consistent with the checks on the TLS server described in RFC 2818. Failure to carry out these checks could allow a spoof server access to a user's credential.
If the SACRED account password were to be used in some other, less secure protocol, using DIGEST-MD5, then it might appear to be the case that a man-in-the-middle (MITM) attack could be mounted. However, this is not the case since the DIGEST-MD5 client hash includes a client-selected "digest-uri-value", which in SACRED's case will be "sacred/<serverName>". In a MITM attack, those values will be something else. A MITM attack as described is therefore thwarted, because digest-uri-value wouldn't match what the SACRED server is expecting. [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000. [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000. [REQS] Arsenault, A. and S. Farrell, "Securely Available Credentials - Requirements", RFC 3157, August 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 2246, January 1999. [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [XMLDSIG] Eastlake, 3rd, D., Reagle, J. and D. Solo, "(Extensible Mark-Up Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. [XMLSCHEMA] "XML Schema Part 1: Structures", D. Beech, M. Maloney, N. Mendelsohn, and H. Thompson. W3C Recommendation, May 2001. Available at http://www.w3.org/TR/2001/REC- xmlschema-2-20010502/
[DDOS] "Recommendations for the Protection against Distributed Denial-of-Service Attacks in the Internet", http://www.iwar.org.uk/comsec/resources/dos/ddos_en.htm [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. [RFC3760] Gustafson, D., Just, M. and M. Nystrom, "Securely Available Credentials - Credential Server Framework," RFC 3760, April 2004. [XKMS] Hallam-Baker, P. (ed), "XML Key Management Specification", http://www.w3.org/TR/xkms2/ [XBULK] Hughes, M (ed), "XML Key Management Specification - Bulk Operation", http://www.w3.org/TR/xkms2-xbulk/ Acknowledgements Radia Perlman (firstname.lastname@example.org) and Charlie Kaufman (email@example.com) co-authored earlier versions of this document. Michael Zolotarev (firstname.lastname@example.org) did much of the initial work, adapting an earlier version to the use of SRP (though SRP was subsequently dropped, much of the framework survives). Marshall Rose (email@example.com) helped out a lot, in particular, with the BEEP profile. And the following people were actively involved in the mailing list discussions leading to this document: David Chizmadia, Dave Crocker (firstname.lastname@example.org), Lawrence Greenfield (email@example.com), Dale Gustafson (firstname.lastname@example.org), Mike Just (email@example.com), John Linn (firstname.lastname@example.org), Neal McBurnett (email@example.com), Keith Moore (firstname.lastname@example.org), RL "Bob" Morgan (email@example.com), Magnus Nystrom (firstname.lastname@example.org), Eamon O'Tuathail (email@example.com), Gareth Richards (firstname.lastname@example.org) Of course, any and all errors remain the editor's responsibility.
</complexType> </element> <any namespace="##other"/> </choice> </complexType> <element name="AuthParams" type="sacred:AuthParamsType"/> <!-- Protocol messsages --> <!-- "account handling" operations --> <!-- Information request --> <element name="InfoRequest"/> <element name="InfoResponse"> <complexType> <sequence> <element name="Status" type="string" minOccurs="0"/> <element name="ServerId" type="string"/> <element ref="sacred:AuthParams"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- Create Account Request --> <element name="CreateAccountRequest"> <complexType> <sequence> <element name="UserId" type="string"/> <element ref="sacred:AuthInfo"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- remove account request --> <element name="RemoveAccountRequest"> <complexType> <sequence> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- password change request --> <element name="ModifyAccountRequest"> <complexType> <sequence> <element ref="sacred:AuthInfo"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- "run-time" operations -->
<!-- DownLoad Request --> <element name="DownloadRequest"> <complexType> <sequence> <element name="CredentialSelector" type="string" minOccurs="0"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- Download Response --> <element name="DownloadResponse"> <complexType> <sequence> <element name="Status" type="string" minOccurs="0"/> <element name="Credential" type="sacred:CredentialType" maxOccurs="unbounded"/> </sequence> </complexType> </element> <!-- Upload request --> <element name="UploadRequest"> <complexType> <sequence> <element name="Credential" type="sacred:CredentialType"/> </sequence> </complexType> </element> <element name="DeleteRequest"> <complexType> <sequence> <choice> <sequence> <element name="CredentialSelector" type="string"/> <element name="LastModified" type="dateTime" minOccurs="0"/> </sequence> <element name="All"/> </choice> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- Credential related structures --> <!-- A new ds:KeyInfo thing --> <element name="SacredPKCS15" type="base64Binary"/> <!-- credential --> <complexType name="CredentialType">
<sequence> <element name="CredentialSelector" type="string"/> <element name="LastModified" type="dateTime"/> <element name="Payload" type="ds:KeyInfoType" minOccurs="0"/> <element name="TimeToLive" type="string" minOccurs="0"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> <element ref="sacred:ClientInfo" minOccurs="0"/> </sequence> </complexType> </schema>
I: </profile> I: </start> I: END ... the listener creates the channel and piggybacks its readiness to start TLS ... L: RPY 0 1 . 233 112 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/TLS'> L: <proceed /> L: </profile> L: END ... upon receiving the reply, the initiator starts up TLS ... ... successful transport security negotiation ... ... a new greeting is sent (cf., Section 9 of RFC 3080), note that the listener no longer advertises TLS (we're already running it) L: RPY 0 0 . 0 186 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' /> L: <profile uri='http://iana.org/beep/sacred' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END ... the initiator starts a channel for DIGEST-MD5 and piggybacks initialization information for the mechanism ... I: MSG 0 1 . 52 178 I: Content-Type: application/beep+xml I: I: <start number='1'> I: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'> I: <blob> ... </blob> I: </profile>
I: </start> I: END ... the listener creates the channel and piggybacks a challenge ... L: RPY 0 1 . 186 137 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'> L: <blob> ... </blob> L: </profile> L: END ... the initiator sends a response to the challenge ... I: MSG 1 0 . 0 58 I: Content-Type: application/beep+xml I: I: <blob> ... </blob> I: END ... the listener accepts the challenge and tells the initiator that it is now authenticated ... L: RPY 1 0 . 0 66 L: Content-Type: application/beep+xml L: L: <blob status='complete' /> L: END ... the initiator starts a channel for SACRED and piggybacks its initial SACRED request ... I: MSG 0 2 . 230 520 I: Content-Type: application/beep+xml I: I: <start number='3'> I: <profile uri='http://iana.org/beep/sacred' /> I: <?xml version="1.0" encoding="UTF-8"?> I: <sacred:DownloadRequest I: xmlns:sacred="urn:sacred-2002-12-19" I: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" I: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"> I: <CredentialSelector> I: magnus-credentials</CredentialSelector> I: </sacred:DownloadRequest> I: </start>
I: END ... the listener creates the channel and piggybacks the response to the initial SACRED request L: RPY 0 2 . 323 805 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/sacred' /> L: <?xml version="1.0" encoding="UTF-8"?> L: <sacred:DownloadResponse L: xmlns:sacred="urn:sacred-2002-12-19" L: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" L: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"> L: <Status>Success</Status> L: <Credential> L: <CredentialSelector> L: magnus-credential</CredentialSelector> L: <LastModified>2002-11-22T00:00:08Z</LastModified> L: <Payload> L: <sacred:SacredPKCS15 L: xmlns:sacred="urn:sacred-2002-12-19">GpM7 L: </sacred:SacredPKCS15> L: </Payload> L: </Credential> L: </sacred:DownloadResponse> L: </profile> L: END Section 2.3. For example, if SACRED is provisioned as the payload of an application protocol that supports SASL and TLS, then the appropriate SASL and/or TLS negotiation must successfully occur before exchanging Sacred PDUs. Alternatively, if the application protocol doesn't support SASL, then one or more PDUs are defined to facilitate a SASL negotiation, and the appropriate negotiation must occur before exchanging Sacred PDUs.
Full 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. 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. 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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.