[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4467

Network Working Group                                         M. Crispin
INTERNET-DRAFT: IMAP URLAUTH                    University of Washington
                                                               March 2005
Document: internet-drafts/draft-ietf-lemonade-urlauth-06.txt

     Internet Message Access Protocol (IMAP) - URLAUTH Extension


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,
    or will be 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

    A revised version of this document will be submitted to the RFC
    editor as an Informational Document for the Internet Community.

    A revised version of this draft document will be submitted to the RFC
    editor as a Proposed Standard for the Internet Community.  Discussion
    and suggestions for improvement are requested, and should be sent to
    lemonade@IETF.ORG.  This document will expire before 17 September
    2005.  Distribution of this memo is unlimited.


Abstract

    This document describes the URLAUTH extension to the Internet
    Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme
    (IMAPURL) (RFC 2192).  This extension provides a means by which an
    IMAP client can use URLs carrying authorization to access limited
    message data on the IMAP server.

    An IMAP server which supports this extension indicates this with a
    capability name of "URLAUTH".


Conventions Used in this Document

    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
    in this document are to be interpreted as defined in [KEYWORDS].

    The formal syntax uses the Augmented Backus-Naur Form (ABNF)
    notation including the core rules defined in Appendix A of [ABNF].

    In examples, "C:" and "S:" indicate lines sent by the client and
    server respectively.  If a single "C:" or "S:" label applies to
    multiple lines, then the line breaks between those lines are for
    editorial clarity only and are not part of the actual protocol
    exchange.


Introduction

    In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20
    requires authorization as userid "fred".

    The URLAUTH extension provides a means by which an authorized user of
    an IMAP server can create URLAUTH authorized IMAP URLs.  A URLAUTH
    authorized URL conveys authorization (not authentication) to the data
    addressed by that URL, and can be used in another IMAP session to
    access specific content on the IMAP server without otherwise
    providing authorization to any other data owned by the authorizing
    user (including other data in the mailbox specified in the URL).

    A URLAUTH authorized URL can be used in the argument to the BURL
    command in message composition, as described in [BURL], for such
    purposes as a memory (or other resource) constrained client
    submitting a message forward or resend from an IMAP mailbox without
    requiring the client to fetch that message data.

    The URLAUTH is generated using an authorization mechanism name and an
    authorization token, which is generated using a secret mailbox
    access key.  An IMAP client can request the server to generate and
    assign a new mailbox access key (thus effectively revoking all
    current URLs using URLAUTH with the old mailbox access key) but can
    not set the mailbox access key to a key of its own choosing.


1. Concepts

1.1. URLAUTH

    The URLAUTH is a component, appended at the end of a URL, which
    conveys authorization to access the data addressed by that URL.  It
    contains an authorized access identifier, an authorization
    mechanism name, and an authorization token.  The authorization
    token is generated from the URL, the authorized access identifer,
    authorization mechanism name, and a mailbox access key.

1.2. Mailbox Access Key

    The mailbox access key is a random string with at least 128 bits of
    entropy.  It is generated by software (not by the human user), and
    MUST be unpredictable.

    Each user has a table of mailboxes and an associated mailbox access
    key for each mailbox.  Consequently, the mailbox access key is
    per-user and per-mailbox.  In other words, two users sharing the
    same mailbox each have a different mailbox access key for that
    mailbox, and each mailbox accessed by a single user also has a
    different mailbox access key.

1.3. Authorized Access Identifier

    The authorized access identifier restricts use of the URLAUTH
    authorized URL to certain users authorized on the server, as
    described in section 2.

1.4. Authorization Mechanism

    The authorization mechanism is the algorithm by which the URLAUTH is
    generated and subsequently verified, using the mailbox access key.

    This specification defines the INTERNAL mechanism, which uses a token
    generation algorithm of the server's choosing (a modern and
    reasonably secure [HMAC] such as HMAC-SHA1 is recommended) and does
    not involve disclosure of the mailbox access key to the client.

       Note: If, for any reason, it is necesary to change the token
       generation algorithm of the INTERNAL mechanism (e.g. because an
       attack against the current algorithm has been discovered), all
       currently existing URLAUTH authorized URLs are invalidated by the
       change in algorithm.  Since this would be an unpleasant surprise
       to applications which depend upon the validity of a URLAUTH
       authorized URL, and there is no good way to do a bulk update of
       existing deployed URLs, it is best to avoid this situation by
       using a secure algorithm as opposed to one that is "good enough".

    Although this specification is extensible for other mechanisms, none
    are defined in this document.  In addition to the mechanism name
    itself, other mechanisms may have mechanism specific data, which is
    to be interpreted according to the definition of that mechanism.

1.5. Authorization Token

    The authorization token is a deterministic string of at least 128
    bits which an entity with knowledge of the secret mailbox access key
    and URL authorization mechanism can use to verify the URL.


2. IMAP URL Extensions

    [IMAPURL] is extended by allowing the addition of ;EXPIRE=<datetime>"
    and ";URLAUTH=<access>:<mech>:<token>" to IMAP URLs which refer to
    specific message or message parts.

    ";URLAUTH=<access>:<mech>:<token>" (the URLAUTH) MUST be at the end
    of the URL.

    URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL
    which refers to an entire IMAP server, list of mailboxes, an entire
    IMAP mailbox, or IMAP search results.

    When ";EXPIRE=<datetime>" is used, this indicates the latest date and
    time that the URL is valid.  After that date and time, the URL has
    expired and server implementations MUST reject the URL.  If
    ";EXPIRE=<datetime>" is not used, the URL has no expiration, but
    still can be revoked as discussed below.

    ";URLAUTH=<access>:<mech>:<token>" indicates the access identifiers
    which are permitted to use this URL, the authorization mechanism, and
    the authorization token.

    The "submit+" access identifier, followed by a userid, indicates that
    only a userid authorized as a message submission entity on behalf of
    the specified userid is permitted to use this URL.  The IMAP server
    does not validate the specified userid but does validate that the
    IMAP session has an authorization identity that is authorized as a
    message submission entity.  The authorized message submission entity
    MUST validate the userid prior to contacting the IMAP server.

    The "user+" access identifier, followed by a userid, indicates that
    use of this URL is limited to IMAP sessions which are logged in as
    the specified userid (that is, have authorization identity as that
    userid).

       Note: if a SASL mechanism which provides both authorization and
       authentication identifiers is used to authenticate to the IMAP
       server, the "user+" access identifier must match the authorization
       identifier.

    The "authuser" access identifier indicates that use of this URL is
    limited to IMAP sessions which are logged in as an authorized user
    (that is, have authorization identity as an authorized user) of
    that IMAP server.  Use of this URL is prohibited to anonymous IMAP
    sessions.

    The "anonymous" access identifier indicates that use of this URL is
    not restricted by session authorization identity; that is, any IMAP
    session in authenticated or selected state (as defined in [IMAP]),
    including anonymous sessions, may issue a URLFETCH using this URL.

    The authorization token is represented as an ASCII-encoded
    hexadecimal string, which is used to authorize the URL.  The length
    and the calculation of the authorization token depends upon the
    mechanism used; but, in all cases, the authorization token is at
    least 128 bits (and therefore at least 32 hexadecimal digits).


3. Discussion of URLAUTH Authorization Issues

    In [IMAPURL], the userid before the "@" in the URL has two purposes:
       1) It provides context for user-specific mailbox paths such
          as "INBOX".
       2) It specifies that resolution of the URL requires logging in as
          that user and limits use of that URL to only that user.
    An obvious limitation of using the same field for both purposes is
    that the URL can only be resolved by the mailbox owner.

    URLAUTH overrides the second purpose of the userid in the IMAP URL
    and by default permits the URL to be resolved by any user permitted
    by the access identifier.

    The "user+<userid>" access identifier limits resolution of that URL
    to a particular userid, whereas the "submit+<userid>" access
    identifier is more general and simply requires the session be
    authorized by a user that has been granted a "submit" role within
    the authentication system.  Use of either of these access
    identifiers makes it impossible for an attacker, spying on the
    session, to use the same URL, either directly or by submission to a
    message submission entity.

    The "authuser" and "anonymous" access identifiers do not have this
    level protection, and should be used with caution.  These access
    identifiers are primarily useful for public export of data from an
    IMAP server, without requiring that it be copied to a web or
    anonymous FTP server.  Refer to the Security Considerations for
    more details.


4. Generation of URLAUTH authorized URLs

    A URLAUTH authorized URL is generated from an initial URL as follows:

    An initial URL is built, ending with ";URLAUTH=<access>" but
    without the ":<mech>:<token>" components.  An authorization
    mechanism is selected and used to calculate the authorization
    token, with the initial URL as the data and a secret known to the
    IMAP server as the key.  The URLAUTH authorized URL is generated by
    taking the initial URL and appending ":", the URL authorization
    mechanism name, ":", and the ASCII-encoded hexadecimal
    representation of the authorization token.

       Note: ASCII-encoded hexadecimal is used instead of BASE64
       because a BASE64 representation may have "=" padding characters
       which would be problematic in a URL.

    In the INTERNAL mechanism, the mailbox access key for that mailbox is
    the secret known to the IMAP server, and a server-selected algorithm
    such as HMAC-SHA1 is used to to calculate the authorization token.


5. Validation of URLAUTH authorized URLs

    A URLAUTH authorized URL is validated as follows:

    The URL is split at the ":" which separates "<access>" from
    "<mech>:<token>" in the ";URLAUTH=<access>:<mech>:<token>" portion
    of the URL.  The "<mech>:<token>" portion is first parsed and saved
    as the authorization mechanism and the authorization token.  The
    URL is truncated, discarding the ":" described above, to create a
    "rump URL" (the URL minus the ":" and the "<mech>:<token>"
    portion).  The rump URL is then analyzed to identify the mailbox.

    If the mailbox cannot be identified, an authorization token is
    calculated on the rump URL, using random "plausible" keys (selected
    by the server) as needed, before returning a validation failure.
    This prevents timing attacks aimed at identifying mailbox names.

    If the mailbox can be identified, the authorization token is
    calculated on the rump URL and a secret known to the IMAP server
    using the given URL authorization mechanism.  Validation is
    successful if, and only if, the calculated authorization token for
    that mechanism matches the authorization token supplied in
    ";URLAUTH=<access>:<mech>:<token>".

    Removal of the ":<mech>:<token>" portion of the URL MUST be the
    only operation applied to the URLAUTH authorized URL to get the
    rump URL.  In particular, URL percent escape decoding and
    case-folding MUST NOT occur.

    In the INTERNAL mechanism, the mailbox access key for that mailbox
    is used as the secret known to the IMAP server, and the same
    server-selected algorithm used for generating URLs is used to
    calculate the authorization token for verification.


6. Additional Commands

    These commands are extension to the [IMAP] base protocol.

    The section headings of these commands are intended to correspond
    with where they would be located in the base protocol document if
    they were part of that document.

BASE.6.3.RESETKEY.  RESETKEY Command

    Arguments:  optional mailbox name
                optional mechanism name(s)

    Responses:  none other than in result

    Result:     OK - RESETKEY completed, URLMECH containing new data
                NO - RESETKEY error: can't change key of that mailbox
                BAD - command unknown or arguments invalid

    The RESETKEY command has two forms.

    The first form accepts a mailbox name as an argument, and generates
    a new mailbox access key for the given mailbox in the user's
    mailbox access key table, replacing any previous mailbox access key
    (and revoking any URLs that were authorized with a URLAUTH using
    that key) in that table.  By default, the mailbox access key is
    generated for the INTERNAL mechanism; other mechanisms can be
    specified with the optional mechanism argument.

    The second form, with no arguments, removes all mailbox access keys
    in the user's mailbox access key table, revoking all URLs currently
    authorized using URLAUTH by the user.

    Any current IMAP session logged in as the user which has the mailbox
    selected will receive an untagged OK response with the URLMECH
    status response code (see below for more details about the URLMECH
    status response code).

    Example:

       C: a31 RESETKEY
       S: a31 OK All keys removed
       C: a32 RESETKEY INBOX
       S: a32 OK [URLMECH INTERNAL] mechs
       C: a33 RESETKEY INBOX XSAMPLE
       S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done


BASE.6.3.GENURLAUTH.  GENURLAUTH Command

    Argument:   one or more URL/mechanism pairs

    Response:   untagged response: GENURLAUTH

    Result:     OK - GENURLAUTH completed
                NO - GENURLAUTH error: can't generate a URLAUTH
                BAD - command unknown or arguments invalid

    The GENURLAUTH command requests the server to generate a URLAUTH
    authorized URL for each of the given URLs using the given URL
    authorization mechanism.

    If there is currently no mailbox access key for the given mailbox
    in the user's mailbox access key table, one is automatically
    generated.  That is, it is not necessary to use RESETKEY prior to
    first-time use of GENURLAUTH.

    If the command is successful, a GENURLAUTH response code is returned
    listing the requested URLs as URLAUTH authorized URLs.

    Example:

       C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
          ;section=1.2;urlauth=submit+fred" INTERNAL
       S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
          ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
       S: a777 OK GENURLAUTH completed


BASE.6.3.URLFETCH.  URLFETCH Command

    Argument:   one or more URLs

    Response:   untagged response: URLFETCH

    Result:     OK - urlfetch completed
                NO - urlfetch failed due to server internal error
                BAD - command unknown or arguments invalid

    The URLFETCH command requests that the server return the text data
    associated with the specified IMAP URLs, as described in [IMAPURL]
    and extended by this document.  The data is returned for all
    validated URLs, regardless of whether or not the session would
    otherwise be able to access the mailbox containing that data via
    SELECT or EXAMINE.

       Note: This command does not require that the URL refer to the
       selected mailbox; nor does it require that any mailbox be
       selected.  It also does not in any way interfere with any selected
       mailbox.

    The URLFETCH command MUST return an untagged URLFETCH response and
    a tagged OK response to any URLFETCH command that is syntactically
    valid.  A NO response indicates a server internal failure which may
    be resolved on later retry.

       Note: the possibility of a NO response is to accommodate
       implementations which would otherwise have to issue an
       untagged BYE with a fatal error due to an inability to
       respond to a valid request.  In an ideal world, a server
       SHOULD NOT issue a NO response.

    The server MUST return NIL for any IMAP URL which references an
    entire IMAP server, list of mailboxes, an entire IMAP mailbox, or
    IMAP search results.

    Example

       Note: for clarity, this example uses the LOGIN command which
       SHOULD NOT be used over a non-encrypted communication path.

       This example is of a submit server, obtaining a message segment
       for a message that it has already validated was submitted by
       "fred".

       S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server
       C: a001 LOGIN submitserver secret
       S: a001 OK submitserver logged in
       C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
          ;section=1.2;urlauth=submit+fred:internal
          :91354a473744909de610943775f92038"
       S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
          ;urlauth=submit+fred:internal
          :91354a473744909de610943775f92038" {28}
       S: Si vis pacem, para bellum.
       S:
       S: a002 OK URLFETCH completed


7. Additional Responses

    These responses are extensions to the [IMAP] base protocol.

    The section headings of these responses are intended to correspond
    with where they would be located in the base protocol document if
    they were part of that document.

BASE.7.1.URLMECH.  URLMECH Status Response Code

    The URLMECH status response code is followed by a list of URL
    authorization mechanism names.  Mechanism names other than INTERNAL
    may be appended with an "=" and BASE64 encoded form of mechanism
    specific data.

    This status response code is returned in an untagged OK response in
    response to a RESETKEY, SELECT, or EXAMINE command.

    Example:

       C: a33 RESETKEY INBOX XSAMPLE
       S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done

    In this example, the server supports the INTERNAL mechanism and an
    experimental mechanism called XSAMPLE which also holds some mechanism
    specific data (the name "XSAMPLE" is for illustrative purposes only).


BASE.7.4.GENURLAUTH.   GENURLAUTH Response

    Contents:   One or more URLs

    The GENURLAUTH response returns the URLAUTH authorized URL(s)
    requested by a GENURLAUTH command.

    Example:

       C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
          ;section=1.2;urlauth=submit+fred" INTERNAL
       S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
          ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
       S: a777 OK GENURLAUTH completed


BASE.7.4.URLFETCH.  URLFETCH Response

    Contents:   URL/nstring pair

    The URLFETCH response returns the message text data associated with
    an IMAP URLs, as described in [IMAPURL] and extended by this
    document.  This response occurs as the result of a URLFETCH
    command.

    The returned data string is NIL if the URL is invalid for any reason
    (including validation failure).  If the URL is valid, but the IMAP
    fetch of the body part returned NIL (this should not happen), the
    returned data string should be the empty string ("") and not NIL.

       Note: This command does not require that the URL refer to the
       selected mailbox; nor does it require that any mailbox be
       selected.  It also does not in any way interfere with any selected
       mailbox.

    Example:

       C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
          ;section=1.2;urlauth=submit+fred:internal
          :91354a473744909de610943775f92038"
       S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
          ;urlauth=submit+fred:internal
          :91354a473744909de610943775f92038" {28}
       S: Si vis pacem, para bellum.
       S:
       S: a002 OK URLFETCH completed

8. Formal Syntax

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [ABNF].

    The following modifications are made to the Formal Syntax in [IMAP]:

resetkey        = "RESETKEY" [SP mailbox *(SP mechanism)]

capability      =/ "URLAUTH"

command-auth    =/ resetkey / genurlauth / urlfetch

resp-text-code  =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])

genurlauth      = "GENURLAUTH" 1*(SP url SP mechanism)

genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url)

url             = astring
                    ; contains imapurl as defined below

urlfetch        = "URLFETCH" 1*(SP url)

urlfetch-data   = "*" SP "URLFETCH" 1*(SP url SP nstring)

    The following modifications are made to the Formal Syntax in
    [IMAPURL]:

enc-urlauth     = 32*HEXDIG

imessagepart    = enc-mailbox [uidvalidity] iuid [isection] [iurlauth]
                     ; enc-mailbox is called "enc_mailbox" in [URLAUTH]

iurlauth        = [expire] ";URLAUTH=" access ":" mechanism ":"
                   enc-urlauth

access          = ("submit+" iuserauth) / ("user+" iuserauth) /
                   "authuser" / "anonymous"

expire          = ";EXPIRE=" date-time
                     ; date-time defined in [DATETIME]

mechanism       = "INTERNAL" / 1*(alpha / digit / "-" / ".")
                    ; case-insensitive
                    ; new mechanisms MUST be registered with IANA


9. Security Considerations

    Security considerations are discussed throughout this memo.

    The mailbox access key SHOULD have at least 128 bits of entropy
    (refer to [RANDOM] for more details) and MUST be unpredictable.

    The URLMECH status response code may expose sensitive data in the
    mechanism specific data for mechanisms other than INTERNAL.  A server
    implementation MUST implement a configuration that will not return
    a URLMECH status response code unless some mechanism is provided
    that protects the session from snooping, such as a TLS or SASL
    security layer that provides confidentiality protection.

    The calculation of a authorization token with a "plausible" key if
    the mailbox can not be identified is necessary to avoid attacks in
    which the server is probed to see if a particular mailbox exists on
    the server by measuring the amount of time taken to reject a known
    bad name vs. some other name.

    To protect against a computational denial-of-service attack, a server
    MAY impose progressively longer delays on multiple URL requests that
    fail validation.

    The decision to use the "authuser" access identifier should be made
    with caution.  An "authuser" access identifier can be used by any
    authorized user of the IMAP server; and therefore use of this access
    identifier should be limited to content which may be disclosed to any
    authorized user of the IMAP server.

    The decision to use the "anonymous" access identifier should be
    made with extreme caution.  An "anonymous" access identifier can be
    used by anyone; and therefore use of this access identifier should
    be limited to content which may be disclosed to anonymous.  Many
    IMAP servers do not permit anonymous access; in the case of such
    servers the "anonymous" access identifer is equivalent to
    "authuser", but this MUST NOT be relied upon.


IANA Considerations

    This document consitutes registration of the URLAUTH capability in
    the imap4-capabilities registry.

    URLAUTH authorization mechanisms are registered by publishing a
    standards track or IESG approved experimental RFC.  The registry is
    currently located at:

         [to be defined by IANA]

    This registry is case-insensitive.

    This document consitutes registration of the INTERNAL URLAUTH
    authorization mechanism.

    IMAP URLAUTH Authorization Mechanism Registry

    Mechanism Name               Reference
    --------------               ---------
    INTERNAL                     [this document, to be filled in by IANA]


Normative References

    [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997.

    [BURL]     Newman, C., "Message Submission BURL Extension",
               draft-newman-lemonade-burl-00.txt (work in progress),
               March 2004.

    [DATETIME] Klyne, G., and Newman, C., "Date and Time on the Internet:
               Timestamps", RFC 3339, July 2002.

    [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
               4rev1", RFC 3501, March 2003.

    [IMAPURL]  Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.

    [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.


Informative References:

    [HMAC]     Krawczyk, H., Bellare, M., and Canetti, R., "HMAC:
               Keyed-Hashing for Message Authentication", RFC 2104,
               February 1997.

    [RANDOM]   Eastlake, D., Crocker, S., and Schiller, J., "Randomness
               Recommendations for Security", RFC 1750, December 1994.


Author's Address

    Mark R. Crispin
    Networks and Distributed Computing
    University of Washington
    4545 15th Avenue NE
    Seattle, WA  98105-4527

    Phone: (206) 543-5762
    EMail: MRC@CAC.Washington.EDU


IPR Disclosure Acknowledgement

    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.


Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    intellectual property 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; neither does it represent that it
    has made any effort to identify any such rights. Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11. Copies of
    claims of rights made available for publication 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 implementors or users of this specification can
    be obtained from the IETF Secretariat.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard. Please address the information to the IETF Executive
    Director.


Full Copyright Statement

    Copyright (C) The Internet Society (2005).  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-ipr@ietf.org.


Acknowledgement

    Funding for the RFC Editor function is currently provided by the
    Internet Society.


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/