Subject: [lemonade] URLAUTH draft changes

From: Mark Crispin <[email-masked]>
Date: Thu, 13 Apr 2006 13:51:07 -0700 (PDT)

The proposed set of changes to draft-ietf-lemonade-urlauth-08.txt follow. 
Following each change is a set of comments prefixed with ;;; that 
explain the change.

Assuming that there are no further objections, I will then review the RFC 
Editor's work and merge these changes.

Speak now or forever....

73c73
<    that it only supports authentication, and confuses the concepts
---
>    that it only supports authentication, and confuses the concepts of

;;; grammar correction

78c78
<    conveys authorization in the URL name itself, and reuses a portion of
---
>    conveys authorization in the URL string itself, and reuses a portion of

;;; precision correction (no such thing as a "URL name")

195c195
<    [IMAPURL] is extended by allowing the addition of ;EXPIRE=<datetime>"
---
>    [IMAPURL] is extended by allowing the addition of ";EXPIRE=<datetime>"

;;; typographic correction: missing open quote.

416,417c416,423
<           As a consequence, the iserver rule of [IMAPURL] is modified
<           so that iuserauth is mandatory.
---
>           As a consequence, relative URLs are not permitted, and
>           enc-user is mandatory, in URLAUTH authorized URLs.
>
>              Note: the server component of the URL is generally the
>              logged in userid and server.  If not, then the logged in
>              userid and server MUST have owner-type access to the
>              mailbox access key table owned by the userid and server
>              indicated by the server component of the URL.

;;; per recent discussion regarding the URLAUTH security model.

424,425c430,431
<       (4) the server MAY also verify that the Message-ID and/or
<           second components (if present) are valid.
---
>       (4) the server MAY also verify that the iuid and/or isection
>           components (if present) are valid.

;;; per discussion; "Message-ID" and "second" are obvious errors.

478a485,491
>    The URLFETCH command effectively executes with the access of the userid
>    in the server component of the URL (which is generally the userid that
>    issued the GENURLAUTH).  By itself, the URLAUTH does NOT grant access to
>    the data; once validated, it grants whatever access to the data is held
>    by the userid in the server component of the URL.  That access may have
>    changed since the GENURLAUTH was done.
>

;;; more per recent discussion regarding the URLAUTH security model.

626c639,641
< authimapurl     = "imap://" iuserauth "@" hostport "/" imessagepart
---
> authimapurl     = "imap://" enc-user [iauth] "@" hostport "/" imessagepart
>                    ; replaces "imapurl" and "iserver" rules for URLAUTH
>                    ; authorized URLs

;;; indicate that enc-user is mandatory (it is optional in iuserauth)

633a649,651
> enc-user        = 1*achar
>                    ; same as "enc_user" in RFC 2192
>

;;; per underscore vs. hyphen foofaraw

638c656
< access          = ("submit+" iuserauth) / ("user+" iuserauth) /
---
> access          = ("submit+" enc-user) / ("user+" enc-user) /

;;; remove iauth as possible value in these fields.

677a696,702
>    Although this specification does not prohibit the theoretical
>    capability to generate a URL with a server component other than the
>    logged in userid and server, this capability should only be provided
>    when the logged in userid/server has been authorized as equivalent to
>    the server component userid/server, or otherwise has access to that
>    userid/server mailbox access key table.
>

;;; further security caution per recent discussion regarding the URLAUTH
;;; security model.

719,720c744
<               Specifications: ABNF", draft-crocker-abnf-rfc2234bis (work
<               in progress).
---
>               Specifications: ABNF", RFC 4234, October 2005.

;;; update since RFC now issued (probably will be updated in RFC Editor
;;; version too).

723c747
<               draft-newman-lemonade-burl (work in progress).
---
>               draft-ietf-lemonade-burl (work in progress).

;;; update now that WG draft (probably will be updated in RFC Editor
;;; version too).

-- Mark --

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

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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 13 Apr 2006 16:13:12 -0700

>  ;;; further security caution per recent discussion regarding the URLAUTH

I'm not sure what "this capability should only be provided" means. 
Does it mean the server should reject a GENURLAUTH where the server 
or userid differ from that of the current session?  If so, I'd prefer 
the text to say so more clearly.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is hardly anything in the world that some one cannot make a
little worse, and sell a little cheaper.  --John Ruskin (1819-1900)

---

From: Mark Crispin <[email-masked]>
Date: Thu, 13 Apr 2006 16:21:54 -0700 (Pacific Daylight Time)

On Thu, 13 Apr 2006, Randall Gellens wrote:
> Does it 
> mean the server should reject a GENURLAUTH where the server or userid differ 
> from that of the current session?

I don't know how the server could do a GENURLAUTH where the server or 
userid differ from that of the current session, since somehow the server 
has to get ahold of the mailbox key table for that other userid/server in 
order to generate it.

But that's an implementation issue.  I'm just pointing out that the 
implementation would have to do that if it is to allow such a thing.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Thu, 13 Apr 2006 16:18:49 -0700 (Pacific Daylight Time)

On Thu, 13 Apr 2006, Randall Gellens wrote:
> I'm not sure what "this capability should only be provided" means. Does it 
> from that of the current session?  If so, I'd prefer the text to say so more 
> clearly.

No, it means what it says.  It is a cautionary security note.

It's exactly like saying that you shouldn't implement separate 
authentication vs. authorization users in SASL unless you have some means 
to validate that the authentication user can acquire the authorization 
user's credentials.

-- Mark --