< draft-crispin-imap-urlauth-08.txt   draft-crispin-imap-urlauth-09.txt >
Network Working Group M. Crispin Network Working Group M. Crispin
INTERNET-DRAFT: IMAP URLAUTH University of Washington INTERNET-DRAFT: IMAP URLAUTH University of Washington
C. Newman C. Newman
Sun Microsystems Sun Microsystems
Document: internet-drafts/draft-crispin-imap-urlauth-08.txt July 2004 Document: internet-drafts/draft-crispin-imap-urlauth-09.txt July 2004
Internet Message Access Protocol (IMAP) - URLAUTH Extension Internet Message Access Protocol (IMAP) - URLAUTH Extension
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 36 skipping to change at line 37
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A revised version of this document will be submitted to the RFC A revised version of this document will be submitted to the RFC
editor as an Informational Document for the Internet Community. editor as an Informational Document for the Internet Community.
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to and suggestions for improvement are requested, and should be sent to
lemonade@IETF.ORG. This document will expire before 21 January 2005. lemonade@IETF.ORG. This document will expire before 25 January 2005.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
;;; POINTS FOR DISCUSSION:
;;;
;;; Earlier versions of this document had access identifiers for "any
;;; authorized user" and anonymous. These were not needed for Lemonade
;;; submit-without-download and were removed. Should something of this
;;; nature be put back in?
Abstract Abstract
This document describes the URLAUTH extension to the Internet This document describes the URLAUTH extension to the Internet
Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme
(IMAPURL) (RFC 2192). This extension provides a means by which an (IMAPURL) (RFC 2192). This extension provides a means by which an
IMAP client can use "signed" URLs carrying authorization to access IMAP client can use URLs carrying authorization to access limited
limited message data on the IMAP server. message data on the IMAP server.
An IMAP server which supports this extension indicates this with a An IMAP server which supports this extension indicates this with a
capability name of "URLAUTH". capability name of "URLAUTH".
Conventions Used in this Document Conventions Used in this Document
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in [KEYWORDS]. in this document are to be interpreted as defined in [KEYWORDS].
The formal syntax uses the Augmented Backus-Naur Form (ABNF) The formal syntax uses the Augmented Backus-Naur Form (ABNF)
skipping to change at line 69 skipping to change at line 77
server respectively. If a single "C:" or "S:" label applies to server respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol editorial clarity only and are not part of the actual protocol
exchange. exchange.
Introduction Introduction
In [IMAPURL], a URL of the form imap://fred@example.com/INBOX;uid=20 In [IMAPURL], a URL of the form imap://fred@example.com/INBOX;uid=20
requires authorization as userid "fred". requires authorization as userid "fred".
The URLAUTH extension provides a means by which an authorized The URLAUTH extension provides a means by which an authorized user of an
user of an IMAP server can create signed IMAP URLs. A signed URL IMAP server can create URLAUTH authorized IMAP URLs. A URLAUTH
conveys authorization (not authentication) to its data, and can be authorized URL conveys authorization (not authentication) to the data
used in another IMAP session to access specific content on the IMAP addressed by that URL, and can be used in another IMAP session to access
server without otherwise providing authorization to any other data specific content on the IMAP server without otherwise providing
owned by the signing user (including other data in the mailbox authorization to any other data owned by the authorizing user (including
specified in the URL). other data in the mailbox specified in the URL).
A signed URL can be used in the argument to the BURL command in message A URLAUTH authorized URL can be used in the argument to the BURL command
composition, as described in [BURL], for such purposes as a memory (or in message composition, as described in [BURL], for such purposes as a
other resource) constrainted client submitting a message forward or resend memory (or other resource) constrainted client submitting a message
from an IMAP mailbox without requiring the client to fetch that message forward or resend from an IMAP mailbox without requiring the client to
data. fetch that message data.
URLs are signed using a signature mechanism name and an authentication The URLAUTH is generated using an authorization mechanism name and an
signature, which is generated using a secret mailbox access key. An IMAP authorization token, which is generated using a secret mailbox
client client can request the server to generate and assign a new mailbox access key. An IMAP client client can request the server to generate
access key (thus effectively revoking all current URLs using URLAUTH with and assign a new mailbox access key (thus effectively revoking all
that mailbox access key) but can not set the mailbox access key to a key current URLs using URLAUTH with that mailbox access key) but can not set
of its own choosing. the mailbox access key to a key of its own choosing.
1. Concepts 1. Concepts
1.1. Mailbox Access Key 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 which 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 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 entropy. It is generated by software (not by the human user), and MUST
be unpredictable. be unpredictable.
Each user has a table of mailboxes and an associated mailbox access key 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 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 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 a different mailbox access key for that mailbox; and each mailbox accessed
by a single user also has different mailbox access key. by a single user also has different mailbox access key.
1.2. Signatures 1.3. Authorized Access Identifier
The signature is a deterministic string of at least 128 bits which an The authorized access identifier restricts use of the URLAUTH authorized
entity with knowledge of the secret mailbox access key and signature URL to certain users authorized on the server, as described in section 2.
mechanism can use to verify the URL.
1.3. Signature Mechanisms 1.4. Authorization Mechanism
The signature mechanism is the algorithm by which the URL is signed and The authorization mechanism is the algorithm by which the URLAUTH is
subsequently verified, using the mailbox access key. generated and subsequently verified, using the mailbox access key.
This specification defines the INTERNAL mechanism, which uses a signature This specification defines the INTERNAL mechanism, which uses a token
algorithm of the server's choosing (a modern and reasonably secure generation algorithm of the server's choosing (a modern and reasonably
algorithm such as HMAC-SHA1 is recommended) and does not involve secure [HMAC] such as HMAC-SHA1 is recommended) and does not involve
disclosure of the mailbox access key to the client. disclosure of the mailbox access key to the client.
Although this specification is extensible for other mechanisms, none Although this specification is extensible for other mechanisms, none
are defined in this document. are defined in this document.
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 2. IMAP URL Extensions
[IMAPURL] is extended by allowing the addition of ;EXPIRE=<datetime>" [IMAPURL] is extended by allowing the addition of ;EXPIRE=<datetime>"
and ";URLAUTH=<access>:<mech>:<sig>" to IMAP URLs which refer to and ";URLAUTH=<access>:<mech>:<token>" to IMAP URLs which refer to
specific message or message parts. specific message or message parts.
";URLAUTH=<access>:<mech>:<sig>" MUST be at the end of the URL. ";URLAUTH=<access>:<mech>:<token>" (the URLAUTH) MUST be at the end of
the URL.
This facility does not apply to, and MUST NOT be used with, any IMAP URL URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL which
which refers to an entire IMAP server, list of mailboxes, an entire IMAP refers to an entire IMAP server, list of mailboxes, an entire IMAP
mailbox, or IMAP search results. mailbox, or IMAP search results.
When ";EXPIRE=<datetime>" is used, this indicates the latest date and 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 time that the URL is valid. After that date and time, the URL has
expired and server implementations MUST reject the URL. If expired and server implementations MUST reject the URL. If
";EXPIRE=<datetime>" is not used, the URL has no expiration, but still ";EXPIRE=<datetime>" is not used, the URL has no expiration, but still
can be revoked as discussed below. can be revoked as discussed below.
When ";URLAUTH=<access>:<mech>:<sig>" is used, this indicates the access ";URLAUTH=<access>:<mech>:<token>" indicates the access identifiers
identifiers which are permitted to use this URL, the mechanism used to which are permitted to use this URL, the authorization mechanism, and
sign the URL, and the signature. the authorization token.
The "submit+" access identifier, followed by a userid, indicates that The "submit+" access identifier, followed by a userid, indicates that
only a userid authorized as a message submission entity on behalf of the 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 specified userid is permitted to use this URL. The IMAP server does not
validate the specified userid but does validate that the IMAP session validate the specified userid but does validate that the IMAP session
has an authorization identity that is authorized as a message submission has an authorization identity that is authorized as a message submission
entity. The authorized message submission entity MUST validate the entity. The authorized message submission entity MUST validate the
userid prior to contacting the IMAP server. userid prior to contacting the IMAP server.
The "user+" access identifier, followed by a userid, indicates that use 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 of this URL is limited to IMAP sessions which are logged in as the
specified userid (that is, have authorization identity as that userid). specified userid (that is, have authorization identity as that userid).
;;; Earlier versions of this document had access identifiers for "any The authorization token is represented as an ASCII-encoded hexadecimal
;;; authorized user" and anonymous. These are not needed for Lemonade string, which is used to authorize the URL. The length and the
;;; submit-without-download and have been removed. calculation of the authorization token depends upon the mechanism used;
but in all cases the authorization token is at least 128 bits (and
The signature is represented as an ASCII-encoded hexadecimal string, therefore 32 hexadecimal digits).
which is used to authorize the URL. The length and the calculation of
the signature depends upon the mechanism used; but in all cases the
signature is at least 128 bits (and therefore 32 hexadecimal digits).
3. Discussion of URLAUTH Authorization Issues 3. Discussion of URLAUTH Authorization Issues
In [IMAPURL], the userid before the "@" in the URL has two purposes: In [IMAPURL], the userid before the "@" in the URL has two purposes:
1) It provides context for user-specific mailbox paths such 1) It provides context for user-specific mailbox paths such
as "INBOX". as "INBOX".
2) It specifies that resolution of the URL requires logging in as 2) It specifies that resolution of the URL requires logging in as
that user and limits use of that URL to only that user. 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 An obvious limitation of using the same field for both purposes is that
the URL can only be resolved by the mailbox owner. the URL can only be resolved by the mailbox owner.
skipping to change at line 189 skipping to change at line 208
The "user+<userid>" access identifier limits resolution of that URL to a The "user+<userid>" access identifier limits resolution of that URL to a
particular userid, whereas the "submit+<userid>" access identifier is particular userid, whereas the "submit+<userid>" access identifier is
more general and simply requires the session be authorized by a user more general and simply requires the session be authorized by a user
that has been granted a "submit" role within the authentication system. that has been granted a "submit" role within the authentication system.
This makes it impossible for an attacker, spying on the session, to use This makes it impossible for an attacker, spying on the session, to use
the same URL, either directly or by submission to a message submission the same URL, either directly or by submission to a message submission
entity. entity.
4. Generation of Signed URLs 4. Generation of URLAUTH authorized URLs
A signed URL is generated as follows. A URLAUTH authorized URL is generated from an initial URL as follows.
An initial URL is built, ending with ";URLAUTH=<access>" but without the An initial URL is built, ending with ";URLAUTH=<access>" but without the
":<mech>:<sig>" components. A signature mechanism is selected and used ":<mech>:<token>" components. An authorization mechanism is selected
to calculate the signature, with the initial URL as the data and a and used to calculate the authorization token, with the initial URL as
secret known to the IMAP server as the key. The signed URL is created the data and a secret known to the IMAP server as the key. The URLAUTH
by taking the initial URL and appending ":" followed by the signature authorized URL is generated by taking the initial URL and appending ":",
mechanism name, ":", and the ASCII-encoded hexadecimal representation of the URL authorization mechanism name, ":", and the ASCII-encoded
the authentication signature. hexadecimal representation of the authorization token.
Note: ASCII-encoded hexadecimal is used instead of BASE64 because a Note: ASCII-encoded hexadecimal is used instead of BASE64 because a
BASE64 representation may have "=" padding characters which would be BASE64 representation may have "=" padding characters which would be
problematic in a URL. problematic in a URL.
In the INTERNAL mechanism, the mailbox access key for that mailbox is In the INTERNAL mechanism, the mailbox access key for that mailbox is
the secret known to the IMAP server, and a server-selected algorithm the secret known to the IMAP server, and a server-selected algorithm
such as HMAC-SHA1 is used to to calculate the signature. such as HMAC-SHA1 is used to to calculate the authorization token.
5. Validation of Signed URLs 5. Validation of URLAUTH authorized URLs
A signed URL is validated as follows. A URLAUTH authorized URL is validated as follows.
The URL is split at the ":" which separates "<access>" from "<mech>:<sig>" The URL is split at the ":" which separates "<access>" from
in the ";URLAUTH=<access>:<mech>:<sig>" portion of the URL. The "<mech>:<token>" in the ";URLAUTH=<access>:<mech>:<token>" portion of
"<mech>:<sig>" portion is first parsed and saved as the signature the URL. The "<mech>:<token>" portion is first parsed and saved as the
mechanism and the signature. The URL is truncated, discarding the ":" authorization mechanism and the authorization token. The URL is
described above, to create a "rump URL" (the URL minus the ":" and the truncated, discarding the ":" described above, to create a "rump URL"
"<mech>:sig" portion). The rump URL is then analyzed to identify the (the URL minus the ":" and the "<mech>:<token>" portion). The rump URL
mailbox. is then analyzed to identify the mailbox.
If the mailbox cannot be identified, a signature is calculated on the rump If the mailbox cannot be identified, an authorization token is
URL, using random "plausible" keys (selected by the server) as needed, calculated on the rump URL, using random "plausible" keys (selected by
before returning a validation failure. This prevents timing attacks aimed the server) as needed, before returning a validation failure. This
at identifying mailbox names. prevents timing attacks aimed at identifying mailbox names.
If the mailbox can be identified, the signature is calculated on the If the mailbox can be identified, the authorization token is calculated
rump URL and a secret known to the IMAP server using the given signature on the rump URL and a secret known to the IMAP server using the given
mechanism. Validation is successful if, and only if, the calculated URL authorization mechanism. Validation is successful if, and only if,
signature for that mechanism matches the signature supplied in the calculated authorization token for that mechanism matches the
";URLAUTH=<access>:<mech>:<sig>". authorization token supplied in ";URLAUTH=<access>:<mech>:<token>".
Removal of the ":<mech>:<sig>" portion of the URL MUST be the only Removal of the ":<mech>:<token>" portion of the URL MUST be the only
operation applied to the signed URL to get the rump URL. In particular, operation applied to the URLAUTH authorized URL to get the rump URL. In
URL percent escape decoding and case-folding MUST NOT occur. particular, URL percent escape decoding and case-folding MUST NOT occur.
In the INTERNAL mechanism, the mailbox access key for that mailbox is In the INTERNAL mechanism, the mailbox access key for that mailbox is
used as the secret known to the IMAP server, and the same used as the secret known to the IMAP server, and the same
server-selected algorithm used for generating URLs is used to calculate server-selected algorithm used for generating URLs is used to calculate
the signature for verification. the authorization token for verification.
6. Additional Commands 6. Additional Commands
These commands are extension to the [IMAP] base protocol. These commands are extension to the [IMAP] base protocol.
The section headings of these commands are intended to correspond with The section headings of these commands are intended to correspond with
where they would be located in the base protocol document if they were where they would be located in the base protocol document if they were
part of that document. part of that document.
BASE.6.3.RESETKEY. RESETKEY Command BASE.6.3.RESETKEY. RESETKEY Command
skipping to change at line 262 skipping to change at line 281
optional mechanism name(s) optional mechanism name(s)
Responses: none other than in result Responses: none other than in result
Result: OK - RESETKEY completed, URLMECH containing new data Result: OK - RESETKEY completed, URLMECH containing new data
NO - RESETKEY error: can't change key of that mailbox NO - RESETKEY error: can't change key of that mailbox
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The RESETKEY command has two forms. The RESETKEY command has two forms.
The first form accepts a mailbox name as an argument, and generates a The first form accepts a mailbox name as an argument, and generates
new mailbox access key for the given mailbox in the user's mailbox a new mailbox access key for the given mailbox in the user's
access key table, replacing any previous mailbox access key (and mailbox access key table, replacing any previous mailbox access key
revoking any URLs signed using that key) in that table. By default, the (and revoking any URLs that were authorized with a URLAUTH using
mailbox access key is generated for the INTERNAL mechanism; other that key) in that table. By default, the mailbox access key is
mechanisms can be specified with the optional mechanism argument. 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 second form, with no arguments, removes all mailbox access keys
the user's mailbox access key table, revoking all URLs signed by the in the user's mailbox access key table, revoking all URLs current
user. authorized using URLAUTH by the user.
Any current IMAP session logged in as the user which has the mailbox Any current IMAP session logged in as the user which has the mailbox
selected will receive an untagged OK response with the MAILBOXKEY selected will receive an untagged OK response with the MAILBOXKEY
status response code. status response code.
Example: Example:
C: a31 RESETKEY C: a31 RESETKEY
S: a31 OK All keys removed S: a31 OK All keys removed
C: a32 RESETKEY INBOX C: a32 RESETKEY INBOX
S: a32 OK [URLMECH INTERNAL] mechs S: a32 OK [URLMECH INTERNAL] mechs
C: a33 RESETKEY INBOX XSAMPLE C: a33 RESETKEY INBOX XSAMPLE
S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] mechs S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] mechs
BASE.6.3.SIGNURL. SIGNURL Command BASE.6.3.GENURLAUTH. GENURLAUTH Command
Argument: one or more URL/mechanism pairs Argument: one or more URL/mechanism pairs
Response: untagged response: SIGNURL Response: untagged response: GENURLAUTH
Result: OK - signurl completed Result: OK - GENURLAUTH completed
NO - signurl error: can't sign a URL NO - GENURLAUTH error: can't generate a URLAUTH
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The SIGNURL command requests the server to generate a URLAUTH signed The GENURLAUTH command requests the server to generate a URLAUTH
URL for each of the given URLs using the given signing mechanism. authorized URL for each of the given URLs using the given URL
authorization mechanism.
If the command is successful, a SIGNURL response code is returned If the command is successful, a GENURLAUTH response code is returned
listing the requested URLs as signed URLs. listing the requested URLs as URLAUTH authorized URLs.
Example: Example:
Note that lines which do not begin with "C:" or "S:" are Note that lines which do not begin with "C:" or "S:" are
continuations of the previous line for typographical clarity and continuations of the previous line for typographical clarity and
are not separate lines in the protocol. are not separate lines in the protocol.
C: a777 SIGNURL "imap://joe@example.com/INBOX;uid=20;section=1.2 C: a777 GENURLAUTH "imap://joe@example.com/INBOX;uid=20;section=1.2
;urlauth=submit+fred" INTERNAL ;urlauth=submit+fred" INTERNAL
S: * SIGNURL "imap://joe@example.com/INBOX;uid=20;section=1.2 S: * GENURLAUTH "imap://joe@example.com/INBOX;uid=20;section=1.2
;authid=fred;urlauth=submit+fred:internal: ;authid=fred;urlauth=submit+fred:internal:
91354a473744909de610943775f92038" 91354a473744909de610943775f92038"
S: a777 OK SIGNURL completed S: a777 OK GENURLAUTH completed
BASE.6.3.URLFETCH. URLFETCH Command BASE.6.3.URLFETCH. URLFETCH Command
Argument: URL Argument: URL
Response: untagged response: URLFETCH Response: untagged response: URLFETCH
Result: OK - urlfetch completed Result: OK - urlfetch completed
NO - urlfetch failed due to server internal error NO - urlfetch failed due to server internal error
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at line 384 skipping to change at line 405
7. Additional Responses 7. Additional Responses
These responses are extensions to the [IMAP] base protocol. These responses are extensions to the [IMAP] base protocol.
The section headings of these responses are intended to correspond with The section headings of these responses are intended to correspond with
where they would be located in the base protocol document if they were where they would be located in the base protocol document if they were
part of that document. part of that document.
BASE.7.1.URLMECH. URLMECH Status Response Code BASE.7.1.URLMECH. URLMECH Status Response Code
The URLMECH status response code is followed by a list of signature The URLMECH status response code is followed by a list of URL authorization
mechanism names. Mechanism names other than INTERNAL may be appended mechanism names. Mechanism names other than INTERNAL may be appended
with an "=" and BASE64 encoded form of mechanism specific data. with an "=" and BASE64 encoded form of mechanism specific data.
This status response code is returned in an untagged OK response in This status response code is returned in an untagged OK response in
response to a RESETKEY, SELECT, or EXAMINE command. response to a RESETKEY, SELECT, or EXAMINE command.
BASE.7.4.URLFETCH. URLFETCH Response BASE.7.4.URLFETCH. URLFETCH Response
Contents: URL/nstring pair Contents: URL/nstring pair
skipping to change at line 413 skipping to change at line 434
8. Formal Syntax 8. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF]. Form (ABNF) notation as specified in [ABNF].
The following modifications are made to the Formal Syntax in [IMAP]: The following modifications are made to the Formal Syntax in [IMAP]:
resetkey = "RESETKEY" [SP mailbox *(SP mechanism)] resetkey = "RESETKEY" [SP mailbox *(SP mechanism)]
command-auth =/ resetkey / signurl / urlfetch command-auth =/ resetkey / genurlauth / urlfetch
resp-text-code =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64]) resp-text-code =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])
signurl = "SIGNURL" 1*(SP url SP mechanism) genurlauth = "GENURLAUTH" 1*(SP url SP mechanism)
signurl-data = "*" SP "SIGNURL" 1*(SP url) genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url)
url = astring url = astring
; contains imapurl as defined below ; contains imapurl as defined below
urlfetch = "URLFETCH" SP url urlfetch = "URLFETCH" SP url
urlfetch-data = "*" SP "URLFETCH" SP url SP nstring urlfetch-data = "*" SP "URLFETCH" SP url SP nstring
The following modifications are made to the Formal Syntax in [IMAPURL]: The following modifications are made to the Formal Syntax in [IMAPURL]:
skipping to change at line 458 skipping to change at line 479
The mailbox access key SHOULD have at least 128 bits of entropy (refer The mailbox access key SHOULD have at least 128 bits of entropy (refer
to [RANDOM] for more details) and MUST be unpredictable. to [RANDOM] for more details) and MUST be unpredictable.
The URLMECH status response code may expose sensitive data in the The URLMECH status response code may expose sensitive data in the
mechanism specific data for mechanisms other than INTERNAL. A server mechanism specific data for mechanisms other than INTERNAL. A server
implementation MUST implement a configuration that will not return implementation MUST implement a configuration that will not return
a URLMECH status response code unless some mechanism is provided a URLMECH status response code unless some mechanism is provided
that protects the session from snooping, such as a TLS or SASL that protects the session from snooping, such as a TLS or SASL
security layer that provides confidentiality protection. security layer that provides confidentiality protection.
The calculation of a signature with a "plausible" key if the mailbox can The calculation of a authorization token with a "plausible" key if the
not be identified is necessary to avoid attacks in which the server is mailbox can not be identified is necessary to avoid attacks in which the
probed to see if a particular mailbox exists on the server by measuring server is probed to see if a particular mailbox exists on the server by
the amount of time taken to reject a known bad name vs. some other name. 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 To protect against a computational denial-of-service attack, a server
MAY impose progressively longer delays on multiple URL requests that MAY impose progressively longer delays on multiple URL requests that
fail validation. fail validation.
IANA Considerations IANA Considerations
URLAUTH authentication signture mechanisms are registered by URLAUTH authorization mechanisms are registered by publishing a
publishing a standards track or IESG approved experimental RFC. The standards track or IESG approved experimental RFC. The registry is
registry is currently located at: currently located at:
[to be defined by IANA] [to be defined by IANA]
This document consitutes registration of the INTERNAL URLAUTH This document consitutes registration of the INTERNAL URLAUTH
signature mechanism: authorization mechanism.
IMAP URLAUTH Authentication Signature Mechanism Registry IMAP URLAUTH Authorization Mechanism Registry
Mechanism Name Reference Mechanism Name Reference
-------------- --------- -------------- ---------
INTERNAL [this document, to be filled in by IANA] INTERNAL [this document, to be filled in by IANA]
References References
The following references are normative: The following references are normative:
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
skipping to change at line 508 skipping to change at line 530
[IMAP] Crispin, M., "Internet Message Access Protocol - Version [IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. [IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
The following references are informative: The following references are informative:
[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 [RANDOM] Eastlake, D., Crocker, S., and Schiller, J., "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
Author's Addresses Author's Addresses
Mark R. Crispin Mark R. Crispin
Networks and Distributed Computing Networks and Distributed Computing
University of Washington University of Washington
4545 15th Avenue NE 4545 15th Avenue NE
Seattle, WA 98105-4527 Seattle, WA 98105-4527
 End of changes. 50 change blocks. 
112 lines changed or deleted 138 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/