SIP Working Group L. Veltri Internet-Draft Univ. of Parma Intended status: Informational S. Salsano Expires: October 29, 2008 A. Polidoro Univ. of Rome Tor Vergata April 27, 2008 HTTP digest authentication using alternate password storage schemes draft-veltri-sip-alt-auth-00 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 October 29, 2008. Veltri, et al. Expires October 29, 2008 [Page 1] Internet-Draft SIP auth. using alternate schemes April 2008 Abstract This document proposes to extend the HTTP Digest Authentication by adding a set new algorithms. These algorithms use different hash functions and combination of various information such as user name, realm, password, salt, and/or other data, in order to achieve compatibility with existing mechanisms used to store user credentials in various authentication/autorization servers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. HTTP Digest Authentication for SIP . . . . . . . . . . . . . . 4 3. New extensible authentication scheme . . . . . . . . . . . . . 8 3.1. First solution . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Second solution . . . . . . . . . . . . . . . . . . . . . 13 4. Security considerations . . . . . . . . . . . . . . . . . . . 17 5. Informative References . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Veltri, et al. Expires October 29, 2008 [Page 2] Internet-Draft SIP auth. using alternate schemes April 2008 1. Introduction According to the current SIP specification [RFC3261], the SIP protocol uses the HTTP Digest Authentication defined in [RFC2617] as default mechanism for authenticating and authorizing User Agent Clients (UACs) against remote User Agent Servers (UASs) or intermediate proxys. HTTP Digest Authentication is a challenge- response authentication method and requires that both the supplicant (i.e. the UAC) and the authenticator (i.e. the UAS or the proxy) access the clear-text user password or a non-revertible function (hash-derived) of the password and other information. The HTTP Digest Authentication [RFC2617] specifically define also an authentication scheme named MD5 that requires the UAs and proxys to compute or retrive from a database the MD5 digest of a concatenation (colon-separated) of username, realm, and password. Unfortunately other user authentication/authorization mechanisms use different and non compatible mechanisms to store non-revertible hashes of passwords. This prevents using an existing database of user credentials to offer SIP based services requiring authentication. This document tries to extend the stantard SIP/HTTP Digest Authentication mechanism in order to consider other password-storing schemes that do not naturally cooperate with the current HTTP Digest Authentication scheme. Examples of such password-storing schemes are those generally used in LDAP servers, Unix shadow/password files, Apache's htpasswd file, or SQL-based storage systems used by other specific applications. Veltri, et al. Expires October 29, 2008 [Page 3] Internet-Draft SIP auth. using alternate schemes April 2008 2. HTTP Digest Authentication for SIP HTTP Digest Authentication [RFC2617] is a general challenge-response mechanism in which a UAS authenticates a UAC based on a shared secret. The challenge response is computed through the use of a one- way function based on various user's credentials. The standard also specifies the use of a particular function (in turn based on the MD5 hash function) that requires that both the client and server knows the user secret (normally a password) or, at least, the hash of the concatenation of the user name, the realm, and the password. When the HTTP Digest Authentication [RFC2617] is used in SIP, an UAS that receives a SIP request (example a REGISTER) may challenge the UAC by sending a 401 "Unauthorized" error response (or 407 "Proxy Authentication Required" for proxy authentication) containing a fresh random nonce value as challenge. Both the UAC and the UAS share a secret (usually a password) and they use this secret, together with the nonce value, realm, and other information, respectively to compute the challenge response (the UAC) and to verify such the response (the UAS). The UAS sends the challenge in the 401 "Unauthorized" SIP response within a WWW-Authenticate header field (Proxy-Authenticate header for proxy authentication), then the UAC sends the challenge response in a new request message within a Authorization header field (Proxy-Authorization header for proxy authentication), and finally the UAS sends the authentication and authorization result with a new response message (2xx if it successed). According to [RFC2617] the challenge response is computed as: response = KD(H(A1), nonce:nc:cnonce:qop:H(method:uri)) where KD(secret,data) is a general two-parameters digest algorithm applied to "data" with secret "secret", while H(data) is a digest algorithm applied to "data", and A1 is a quantity that should take into account user credentials. As specified in [RFC2617], by default or in case of "algorithm=MD5, the KD(,) H(), and A1 are respectively: KD(secret, data) = MD5(secret:data) H(data) = MD5(data) A1 = username:realm:passwd Particularly, the first term of KD(,) (indicated as "secret") and computed as H(A1) becomes: Veltri, et al. Expires October 29, 2008 [Page 4] Internet-Draft SIP auth. using alternate schemes April 2008 secret = H(A1) = MD5(username:realm:passwd) Note that both the requestor (the UAC) and the auhenticator (the UAS) do not need to know the user password (eventually retrieved from a local archive), but rather this "secret" i.e. a digest function of username, realm and password itself. Unfortunately, current user's credential databases or storage systems often protect user's password by implementing one-way cryptographic algorithms different from the MD5 hashing mechanism specified for the HTTP Digest Authentication. For example, in LDAP (Lightweight Directory Access Protocol) servers, password values can be stored as plaintext or as one of a variety of hashes. [RFC3112] specifically describes the "MD5" and "SHA1" schemes for a LDAP directory. The MD5 scheme computes the hashed- protected password as the base64 encoding of an MD5 [RFC1321] digest of the concatenation the user password and salt that must be at least 64 bit long. The SHA1 scheme computes the hashed-protected password in the same way, by using SHA1 [RFC3174] hash function instead of MD5. These two hash-protected password schemes are also referred as: o SSHA - Salted SHA-1 based hash o SMD5 - Salted MD5 based hash Other hash-protected password schemes normally supported by an LDAP server are: o SHA - SHA-1 based hash. o MD5 - MD5 based hash. o CRYPT - Unix crypt() hash, based on DES, also referred as UNIX; see later. Note that these three schemes are weaker than the previous two, due to the absence of a security salt value. In some lucky cases a LDAP server may also support other schemes that use pre-calculated hash values compatible with HTTP Digest Authentication. An other example is the Unix system in which passwords are usually stored in the "/etc/shadow" file or, in older Unix versions, in the "/etc/password" file. In both cases, passwords are normally stored encrypted (actually hashed) with a one-way algorithm generally referred as "crypt", together with a salt value and an indication of Veltri, et al. Expires October 29, 2008 [Page 5] Internet-Draft SIP auth. using alternate schemes April 2008 the used algorithm. The traditional crypt algorithm implementation uses a modified form of the DES algorithm that performs 25 DES passes to encrypt an all-bits-zero block using with a 56-bit key formed by the first 7 password characters. A 12-bit salt is used to perturb the original DES algorithm. The salt and the final ciphertext are base64-encoded into a printable string stored in the password or shadow file. Other more robust crypt functions have been defined based on other cryptographic or hash algorithms such as MD5, blowfish, or SHA-1. Such functions generally allow users to have any length password (> 8bytes), and do not limit the password to ASCII (7-bit) text. Currently, the most common crypt function used by Unix/Linux systems supports both the original DES-based and the MD5- based (MD5-crypt) algorithms. The MD5-crypt function is really not a straight implementation of MD5: first the password and salt are MD5 hashed together in a first digest, then 1000 iteration loops continuously remix the password, salt and intermediate digest values; the output of the last of these rounds is the resulting hash. A typical output of the stored password together with username, salt, and other information is: alice:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj:12747:0:99999:7::: where $1$ indicates the use of MD5-crypt, while BZftq3sP is the base-64 encoding of the salt and xEeZmr2fGEnKjVAxzjQo68 is the password hash. Other applications also store user's credentials in local files or database, that have they own format but that re-use similar hashing algorithms. For example the Apache's htpasswd tool supports four different methods: PLAINTEXT: passwords are stored without any encryption mechanism. In this case in the file will contain lines of the form: user: passwd CRYPT: passwords are stored encrypted using the traditional Unix crypt function described in the previous section. SHA1: passwords are stored by base64-encoding the SHA-1 digest of the password. The corresponding htpasswd file has lines that look like: alice:{SHA1}VBPuJHI7uixaa6LQGWx4s+5GKNE= where VBPuJHI7uixaa6LQGWx4s+5GKNE= is the base-64 hash of the password. Veltri, et al. Expires October 29, 2008 [Page 6] Internet-Draft SIP auth. using alternate schemes April 2008 MD5: passwords are stored encrypted through the MD5-crypt function described in the previous section using an Apache-modified version of MD5. An example of a corresponding htpasswd line is: alice:$apr1$r31.....$HqJZimcKQFAMYayBlzkrA/ where $apr1$ indicates the use of the Apache's MD5-crypt function, followed by the salt and the effective password hash. Veltri, et al. Expires October 29, 2008 [Page 7] Internet-Draft SIP auth. using alternate schemes April 2008 3. New extensible authentication scheme The HTTP Digest Authentication [RFC2617] requires that the response to the challenge, regardless of the selected algorithm, is in the form of: response = KD(H(A1),nonce:nc:cnonce:qop:H(method:uri)) In case of "algorithm=MD5", KD(secret,data) is MD5(secret:data), H(data) is MD5(data), while the H(A1) becomes MD5(username:realm: passwd). Assuming for the moment that we have no interest in changing the KD function, we can envisage two possible solutions: a. we can define a different A1 and H(A1) function compatible with the specific authentication system (A1 is a formatted set of parameters that are taken into account by the H() function). For example A1 could be the concatenation passwd:salt and H(A1) could become: H(A1) = MD5(passwd:salt) b. we can reuse the definition of H(A1) and only replace the password parameter with a new derived pseudo-password A3 defined as A3=KP(password,other-params). In this case we are introducing a new function KP() with a new set of parameters that includes the user password. The value A1 becomes: A1=username:realm:A3. For example, if we chose KP() as MD5(passwd:salt) the value H(A1) becomes: H(A1) = MD5(username:realm:A3), i.e.: H(A1) = MD5(username:realm:MD5(passwd:salt)) The first solution (a) has the advantage that it may save some computation of crypto functions. The second option (b) has the advantage that it inherits all the security properties of the current MD5 solution. Moreover one could store in the client the derived password (i.e. the A3 value) instead of the password and maintain a compatibility with existing clients. We are here referring to the approach of several SIP user agents to store the SIP user password rather then requesting it to the user each time. During this "one- time" password storing operation, the A3 value could be computed externally and then manually stored in the SIP client. Of course this is not our suggested solution, i.e. we believe that SIP stacks should be enhanced with the proposed solution so that SIP UA can natively support the new authentication method, anyway it was worth mentioning this possibility to reuse legacy clients in the short Veltri, et al. Expires October 29, 2008 [Page 8] Internet-Draft SIP auth. using alternate schemes April 2008 term. Once that we have chosen which solution for the algorithm, we should discuss: 1. how to introduce the indication of this different authentication algorithms within SIP signaling; 2. how to convey the parameters that are needed by the new authentication algorithms. Again, we introduce two different options concerning issue 1): i introduce new algorithms specified as parameter "algorithm" within authentication headers. We could have for example algorithm=md5-ldap-sha1, algorithm=md5-crypt-des and so on. ii introduce a new authentication parameter called "pwd-algo" in order to indicate the chosen algorithm used to compute only the derived-passwd A3. These two choices are not completely independent from the choice of the algorithm definition, as shown in the following table. |----------------------|----------------------|----------------------| | |i)introduce new values|ii)introduce a new | | | for the algorithm | pwd-algo parameter | | | parameter | | |----------------------|----------------------|----------------------| |a)definition of a | | | | new A1 and H(A1) | Yes | No | | | | | |----------------------|----------------------|----------------------| |b)reuse H(A1) and | | | | include a new | | | | A3=KP(pwd,params) in | Possible | Suggested | | place of the passwd | | | | value | | | |----------------------|----------------------|----------------------| Figure 1: Alternatives If we define new A1 and H(A1) this should be signaled by introducing new values for the algorithm parameter. At the contrary, if we reuse H(A1) and introduce A3=KP() in place of the clear password, both options for the signaling are feasible, but we think that keeping the algorithm parameter unchanged (that specify A1, H(), and KD()) and introducing a new pwd-algo is preferable. Veltri, et al. Expires October 29, 2008 [Page 9] Internet-Draft SIP auth. using alternate schemes April 2008 Now we finally need to discuss how to convey the additional parameter that may be needed by the different authentication mechanisms. We think that three options are possible: 1. introduce new parameters with specific names for each authentication algorithm; 2. introduce a generic parameter named pwd-param to carry algorithm specific parameters; 3. carry the new parameters added inside the nonce parameter. This is the approach that has been followed for example in the specification of the AKA authentication mechanism. We believe that 1) is the worst solution as it may lead to add several new parameters. 2) and 3) are both feasible, where 2) is a "cleaner" approach that requires the definition of an additional parameter, while 3) has the advantage that does not require any new parameter. Considering the various discussed options, we believe that a first possible solution is based on: a. reuse of H(A1) with a modified version of A1 in which the password value is simply replaced by A3 = KP(password,other- params) b. introduction of new "pwd-algo" parameter c. introduction of a new generic "pwd-param" parameter Examples of the new pwd-algo parameter are: pwd-algo= ssha pwd-algo= crypt-md5 pwd-algo= crypt-apache A second possible solution, more conservative from the point of view of SIP signaling is the use of A3 = KP(password,other-params) as above, but specifying the chosen algorithm in the existing "algorithm" parameter and carrying the algorithm specific parameters within the "nonce" parameter. Examples of the "algorithm" parameter are: algorithm=md5-pwd-hashed algorithm=sha1-pwd-salt-hashed Veltri, et al. Expires October 29, 2008 [Page 10] Internet-Draft SIP auth. using alternate schemes April 2008 When we need to specify variants of the algorithm we think that a simple and efficient solution is to carry the name of the variant into the eventual pwd-param or as part of the nonce value. 3.1. First solution In the first solution we define two new parameters as follows: pwd-algo = "pwd-algo" "=" ( "plain" | token ) pwd-param = "pwd-param" "=" quoted-string where "pwd-algo" specifies the function KP() used to compute the derived-password A3, while "pwd-param" has a completely opaque value, depending on the particular selected function KP, indicating the values of the (eventual) parameters used in KP() computation. A "pwd-algo=plain" value should indicate that none algorithm has to be used, and hence A3=password. This corresponds to the case in which no pwd-algo parameter is present, as in case of standard MD5-based Digest Authentication. Examples of such parameters are: pwd-algo=crypt-des, pwd-param="fzwhEV6E" pwd-algo=alternative, pwd-param="12" pwd-algo=plain Particularly, in order to support current LDAP, Unix-based, and other storing mechanisms, the following new values are defined: pwd-algo = "pwd-algo" "=" ( "plain" | "ssha" | "smd5" | "sha" | "md5" | crypt-algo | token ) crypt-algo = "crypt-" crypt-hash crypt-hash = "des" | "md5" | "blowfish" | "apache" | token pwd-param = "pwd-param" "=" LDQUOT salt-value RDQUOT salt-value = In case of ssha or smd5 or crypt-XXX, the A3 value is computed as follows: A3 = KP(password,salt) = H(password||salt) where H() is respectively SHA1, MD5, or the the Unix crypt function. Veltri, et al. Expires October 29, 2008 [Page 11] Internet-Draft SIP auth. using alternate schemes April 2008 Instead, in the remaining cases: A3 = KP(password) = H(password) In case of ssha or smd5 or crypt-XXX, the pwd-param will contain the base-64 encoding of the salt value. Examples of use of such parameters within a SIP transaction are: INVITE sip:bob@neverland.net SIP/2.0 To: sip:bob@neverland.net From: sip:alice@wonderland.net [...] SIP/2.0 401 Unauthorized To: sip:bob@neverland.net From: sip:alice@wonderland.net WWW-Authenticate: Digest realm="example.com", nonce="cc5a61b2954e03541847f227102f", qop="auth", algorithm="MD5", pwd-algo="crypt-md5", pwd-param="fzwhEV6E" [...] INVITE sip:bob@neverland.net SIP/2.0 To: sip:bob@neverland.net From: sip:alice@wonderland.net Authorization: Digest username="alice", realm="example.com", nonce="cc5a61b2954e03541847f227102f", pwd-algo="crypt-md5", pwd-param="MD5-fzwhEV6E" response="587410ee2dc5edd9bbe9370ddc1fA3a1", uri="sip:bob@neverland.net", qop="auth", nc="00000001" Veltri, et al. Expires October 29, 2008 [Page 12] Internet-Draft SIP auth. using alternate schemes April 2008 cnonce="226827CAD1C949A18B17FD71EC68" [...] SIP/2.0 200 OK To: sip:bob@neverland.net From: sip:alice@wonderland.net [...] 3.2. Second solution The second solution does not require any new authentication parameters since both the selected function KP() (used to generate the new "password" value A3 used in A1) and the eventual parameters of KP() are indicated respectively in the standard algorithm and nonce authentication parameters. According with this solution, the "algorithm" parameter defined in [RFC3261] can be extended as follows: algorithm = "algorithm" EQUAL ( algorithm-value | new-algorithm) algorithm-value = "MD5" | "MD5-sess" | token where "new-algorithm" is a new algorithm name that completely specifies the KD(), H(), A1, and KP() functions for the new authentication scheme. For example, in order to support authentication against a server with Unix-based password archive, we could define: new-algorithm = crypt-algorithm crypt-algorithm = algorithm-value "-crypt" Examples of the use of "algorithm" parameter are: algorithm=MD5 algorithm=MD5-crypt In case of KP() function requires additional parameters such as sub- algorithm type, salt, etc, their values will be included within the nonce parameter, in a form named compound-nonce. According to [RFC3261], the "nonce" parameter can be extended as follows: Veltri, et al. Expires October 29, 2008 [Page 13] Internet-Draft SIP auth. using alternate schemes April 2008 nonce = "nonce" EQUAL (nonce-value | compound-nonce ) compound-nonce = LDQUOT compound-nonce-value RDQUOT compound-nonce-value = algo-param ":" nonce-value algo-param = *( unreserved | algo-mark ) algo-mark = ";" | "/" | "?" | "@" | "&" | "=" | "+" | "$" | "," Examples of the use of nonce parameter are: nonce="cc5a61b2954e0354184" nonce=":cc5a61b2954e0354184" nonce="$1$BZftq3sP:cc5a61b2954e0354184" Particularly, in order to support current LDAP, Unix-based, and other storing mechanisms, the following new values are defined: algorithm = "algorithm" EQUAL ( algorithm-value | new-algorithm) new-algorithm = algorithm-value ( "-pwd-hashed" | "-pwd-salt- hashed" ) In this case, the nonce parameter will contains indication of both password hash algorithm and salt, together with the actual nonce value; that is: nonce = "nonce" EQUAL (nonce-value | compound-nonce ) compound-nonce = LDQUOT compound-nonce-value RDQUOT compound-nonce-value = ( salted-hash-algo | hash-algo ) ":" nonce- value compound-nonce-value = ( crypt-algo-nonce ) ":" nonce-value hash-algo = "sha" | "md5" | "des" | "blowfish" | "apache" | token salted-hash-algo = (hash-algo | crypt-algo) "-" salt-value crypt-algo = "crypt-" hash-algo salt-value = . Examples of use of such parameters within a SIP transaction are: Veltri, et al. Expires October 29, 2008 [Page 14] Internet-Draft SIP auth. using alternate schemes April 2008 INVITE sip:bob@neverland.net SIP/2.0 To: sip:bob@neverland.net From: sip:alice@wonderland.net [...] SIP/2.0 401 Unauthorized To: sip:bob@neverland.net From: sip:alice@wonderland.net WWW-Authenticate: Digest realm="example.com", nonce="crypt-des-fzwhEV6E:cc5a61b2954e03541847f2", qop="auth", algorithm="MD5-crypt" [...] INVITE sip:bob@neverland.net SIP/2.0 To: sip:bob@neverland.net From: sip:alice@wonderland.net Authorization: Digest username="alice", realm="example.com", nonce="crypt-des-fzwhEV6E:cc5a61b2954e03541847f2", response="587410ee2dc5edd9bbe9370ddc1fA3a1", uri="sip:bob@neverland.net", qop="auth", nc="00000001" cnonce="226827CAD1C949A18B17FD71EC68" [...] SIP/2.0 200 OK To: sip:bob@neverland.net From: sip:alice@wonderland.net [...] Veltri, et al. Expires October 29, 2008 [Page 15] Internet-Draft SIP auth. using alternate schemes April 2008 We believe that this second solution is to be preferred to the one presented in the previous sub-section, as it does not require addition of new parameters. This is the same approach that has been followed when defining the SIP-AKA authentication mechanism [RFC3310]. Veltri, et al. Expires October 29, 2008 [Page 16] Internet-Draft SIP auth. using alternate schemes April 2008 4. Security considerations Put security considerations here Veltri, et al. Expires October 29, 2008 [Page 17] Internet-Draft SIP auth. using alternate schemes April 2008 5. Informative References [RFC3261] J. Rosenberg et al., "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC2617] J. Franks et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2401] "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC3310] "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002. [RFC3112] "LDAP Authentication Password Schema", RFC 3112, May 2001. [RFC1321] "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC3174] "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. Veltri, et al. Expires October 29, 2008 [Page 18] Internet-Draft SIP auth. using alternate schemes April 2008 Authors' Addresses Luca Veltri DII, University of Parma Viale delle Scienze 181/A Parma 43100 Italy Phone: +39 0521 90 5768 Email: luca.veltri@unipr.it URI: http://www.tlc.unipr.it/veltri Stefano Salsano DIE, University of Rome "TorVergata" Via Politecnico, 1 Rome 00133 Italy Phone: +39 06 7259 7770 Email: stefano.salsano@uniroma2.it URI: http://netgroup.uniroma2.it/Stefano_Salsano Andrea Polidoro DIE, University of Rome "TorVergata" Via Politecnico, 1 Rome 00133 Italy Phone: +39 06 7259 7773 Email: andrea.polidoro@uniroma2.it URI: http://netgroup.uniroma2.it Veltri, et al. Expires October 29, 2008 [Page 19] Internet-Draft SIP auth. using alternate schemes April 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. Veltri, et al. Expires October 29, 2008 [Page 20]