Subject: [lemonade] More comments about URLAUTH draft

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Feb 2005 22:34:05 +0000

After doing a prototype URLAUTH implementation in Isode IMAP server, I 
suggest the following changes (additions) to the URLAUTH document:

>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.

Add: Each provided URL MUST contain a valid username and a the URLAUTH
component with a valid access identifier. If either of them is missing
or invalid, the server MUST return BAD.

The server MUST verify that the mailbox component of the URL refers to
an existing mailbox, it SHOULD also verify that the specified message id
and section (if present) are valid.

The URL username is used to determine the owner of a mailbox access key
table to be used to generate the URLAUTH authorized URL.

>    If there is currently no mailbox access key for the given mailbox
>    in the user's mailbox access key table, one is automatically

as the term "user" is overloaded, I suggest to replace it with "owner" here.
>    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://[email-masked]/INBOX/;uid=20/;section=1.2
>          ;urlauth=submit+fred" INTERNAL
>       S: * GENURLAUTH "imap://[email-masked]/INBOX/;uid=20/;section=1.2
>          ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
>       S: a777 OK GENURLAUTH completed

Add:

    Example:

       C: a778 GENURLAUTH
"imap://[email-masked]/INBOX/;uid=20/;section=1.2"
          INTERNAL
       S: a778 BAD access identifier is missing the from the URL to be
signed

       C: a779 GENURLAUTH "imap://example.com/Shared/;uid=20/;section=1.2
          ;urlauth=submit+fred" INTERNAL
       S: a779 BAD username is missing from the provided URL

Some additional wordsmithing might be required.

Alexey

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Philip Guenther <[email-masked]>
Date: Tue, 15 Feb 2005 12:56:15 -0800

Alexey Melnikov <[email-masked]> writes:
...
>or invalid, the server MUST return BAD.

So URLAUTH can be used to test usernames for validity?  I would think
that would be a MUST NOT!

>and section (if present) are valid.

When I asked about a similar requirement during the original last call
in November, the author's response was:
>Not necessary for security, and creates a mandate that may be costly
>for some servers.

Since it doesn't fix any race conditions or prevent any attacks, I don't
think it should be required, though servers should be permitted to
reject the command.

>as the term "user" is overloaded, I suggest to replace it with "owner" here.

Uh, no, the 'user' in that sentence is the user that invoked GENURLAUTH,
_not_ the user from the partial URL.

Philip Guenther

---

From: Mark Crispin <[email-masked]>
Date: Tue, 15 Feb 2005 13:18:45 -0800 (Pacific Standard Time)

> that would be a MUST NOT!

I think that, in the 99.999% case, the username that appears in
 	imap://username@server
must be the same as the authorization identity of the session that issued 
the GENURLAUTH.  I guess that it could also match the authentication 
identity.

Otherwise, I don't see how fred could issue a
 	imap://sally@server
URL authorizaed via URLAUTH.

> think it should be required, though servers should be permitted to

I tend to agree.

> _not_ the user from the partial URL.

However, both should be the same, right?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 Feb 2005 12:40:44 +0000

>that would be a MUST NOT!
The username is both the context for the mailbox, as well as the
selector of the owner of the mailbox access key (see below). Whether you
like it or not, but the server has to do username verification internally.

In order address the problem that you've mentioned a server can choose a
random mailbox key that would always fail to verify. But this has to be 
spelled out in the document.

>think it should be required, though servers should be permitted to

Ok, the SHOULD can be dropped, but the MUST is required, because a
mailbox access key is a property of a mailbox.

>_not_ the user from the partial URL.
That is what I thought at first, but this doesn't seem to be the case.
User's mailbox access key is used for signing. So, the user must be
derivable from an URLAUTH URL. An access identifier is not necessarily a
user, it can be a group/role ("submit" or "anonymous"). Which leaves us
with the URL's username part.

Alexey