Subject: [lemonade] URLAUTH and GENURLAUTH

From: Peter Coates <[email-masked]>
Date: Wed, 05 Apr 2006 11:34:57 -0700

There are 3 possibilities
(1) I'm blind
(2) I'm stupid
(3) the URLAUTH spec is missing something important.
 
I tend toward 1 or 2.  But just in case, here goes.
 
First, let me verify that I have things straight.  In issuing a GENURLAUTH
request, the client is asking the server to generate a token so that the a
user can grant (temporary) access to a particular message pr message
fragment to a particular user/any authorised user/whatever.  And the URL
fetch command allows a user to access a message to which they might
otherwise not have access based on this generated token.
 
I believe that to be the theory.  In which case, the server MUST check that
the user issuing the GENURLAUTH request has read permission on the
mailbox(es) in the URL(s) given.  Otherwise anyone with any access could
generate URLs for access to anything.  
 
Now maybe I'm just stupid, and to anyone who is a bit cleverer than me this
would be quite obvious.  But I really think that this check, "does the
current user have read access to the mailbox specified mailbox" ought to be
called out in the list of checks to be performed:
 
   The server MUST validate each supplied URL as follows:

        (1) the mailbox component of the URL MUST refer to an existing
            mailbox.

-->    (1a) the current user authorised for this session MUST have read 
            permission on this mailbox.

        (2) the server component of the URL MUST contain a valid userid
            that identifies the owner of the mailbox access key table
            that will be used to generate the URLAUTH authorized URL.
            As a consequence, the iserver rule of [IMAPURL] is modified
            so that iuserauth is mandatory.

        (3) there is a valid access identifier which, in the case of
            "submit+" and "user+", will contain a valid userid.  This
            userid is not necessarily the same as the owner userid
            described in (2).

        (4) the server MAY also verify that the Message-ID and/or
            second components (if present) are valid.

Or course it is always possible that I have this completely wrong...

Peter

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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 5 Apr 2006 12:43:41 -0700

> There are 3 possibilities

(4) None of the above.  It's a valid point, but one which does not matter.

> otherwise not have access based on this generated token.

Remember, however, that the URLFETCH command effectively executes with the 
access of the user who issued the GENURLAUTH.

Put another way, the token does NOT grant you access to the data; it 
grants you the issuing user's access to the token (whatever that may be). 
Whether that grants you access to the token all depends upon the issuing 
user's access.

Consider this case:

joe generates a token to data owned by sally and gives it to pete. 
Between the time that joe generates the token, and pete uses it, sally 
revokes joe's access to the data.  That has the instantaneous and 
automatic effect of invalidating the token that joe generated.

> generate URLs for access to anything.

Hopefully, you now understand that it doesn't matter.  The check that you 
propose is unnecessary, since the check that counts will take place during 
the URLFETCH.

What's more, the check that you propose may be detrimental.

Why shouldn't it be possible for joe to generate the token for pete even 
if he doesn't have access to it right now?  Suppose he gives it to pete 
now, along with a "I'm leaving a note to sally to ask her change the 
protections, so hold off on using it until after 10AM when she gets in the 
office.  I'm now getting on the plane for Tokyo, so I'll be offline for 
the next 12 hours."

-- Mark --

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

---

From: Peter Coates <[email-masked]>
Date: Wed, 05 Apr 2006 12:47:44 -0700

Thanks.  Suddenly obvious. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Crispin
Sent: April 5, 2006 12:44
To: Peter Coates
Cc: [email-masked]
Subject: Re: [lemonade] URLAUTH and GENURLAUTH

> First, let me verify that I have things straight.  In issuing a 
> GENURLAUTH request, the client is asking the server to generate a 
> token so that the a user can grant (temporary) access to a particular 
> message pr message fragment to a particular user/any authorised 
> user/whatever.  And the URL fetch command allows a user to access a 
> message to which they might otherwise not have access based on this
generated token.

Put another way, the token does NOT grant you access to the data; it grants
you the issuing user's access to the token (whatever that may be). 
Whether that grants you access to the token all depends upon the issuing
user's access.

Consider this case:

joe generates a token to data owned by sally and gives it to pete. 
Between the time that joe generates the token, and pete uses it, sally
revokes joe's access to the data.  That has the instantaneous and automatic
effect of invalidating the token that joe generated.

> I believe that to be the theory.  In which case, the server MUST check 
> that the user issuing the GENURLAUTH request has read permission on 
> the
> mailbox(es) in the URL(s) given.  Otherwise anyone with any access 
> could generate URLs for access to anything.

Why shouldn't it be possible for joe to generate the token for pete even if
he doesn't have access to it right now?  Suppose he gives it to pete now,
along with a "I'm leaving a note to sally to ask her change the protections,
so hold off on using it until after 10AM when she gets in the office.  I'm
now getting on the plane for Tokyo, so I'll be offline for the next 12
hours."

-- Mark --

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 05 Apr 2006 16:29:36 -0400

Hi,

> Thanks.  Suddenly obvious.

If its only obvious after additional explanation, then the draft is 
deficient - particularly when dealing with a security issue. Having re-read 
it just now I too am somewhat confused as to what is the appropriate 
context for determining access to the actual data at URLFETCH time.

I think there needs to be some statement somewhere to make it clear that:

"access to the actual data referenced by the URL is ultimately governed by 
the access privileges of the user that 'owns' the mailbox access key used 
to generate the URLAUTH"

I don't think that is explicitly spelled out and I think it should be.

-- 
Cyrus Daboo

---

From: Mark Crispin <[email-masked]>
Date: Wed, 5 Apr 2006 14:09:41 -0700 (Pacific Daylight Time)

> I don't think that is explicitly spelled out and I think it should be.

<FLAME>

And this did not come up during Last Call because...?

</FLAME>

-- Mark --

---

From: Peter Coates <[email-masked]>
Date: Wed, 05 Apr 2006 14:09:46 -0700

<cringe>

Because few people reading this was as slow on the uptake as I am?

</cringe> 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Crispin
Sent: April 5, 2006 14:10
To: Cyrus Daboo
Cc: Peter Coates; [email-masked]
Subject: RE: [lemonade] URLAUTH and GENURLAUTH

<FLAME>

</FLAME>

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Wed, 5 Apr 2006 13:16:10 -0700

On Wed, 5 Apr 2006, Peter Coates wrote:
> This implies either that the userid must match the userid used to 
> authenticate the imap session, or at least that the current user has 
> access to the key table of the user specified in the iserver part of the 
> URL.  I'm guessing that in practice the former is going to be true.

I agree.  I don't think that most implementations will consider the latter 
case.

-- Mark --

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 05 Apr 2006 17:17:18 -0400

Hi Mark,

> And this did not come up during Last Call because...?

Sometimes things get missed, or don't get spotted until someone actually 
starts delving into doing an implementation - its a fact of life. That said 
I will admit that I did not review the document myself during last call, 
and am only reacting to Peter's comment which drew my attention.

I'm not really bothered as to whether we do anything about it now or not 
given how close to publication the documents are. If you want, just put 
this on the list for some future revision of the document.

-- 
Cyrus Daboo

---

From: Peter Coates <[email-masked]>
Date: Wed, 05 Apr 2006 13:08:02 -0700

OK so the answer is in this paragraph.  This implies either that the userid
must match the userid used to authenticate the imap session, or at least
that the current user has access to the key table of the user specified in
the iserver part of the URL.  I'm guessing that in practice the former is
going to be true.

Peter

-----Original Message-----

generated token.

Consider this case:

-- Mark --

---

From: Randall Gellens <[email-masked]>
Date: Fri, 7 Apr 2006 17:31:15 -0700

At 5:17 PM -0400 4/5/06, Cyrus Daboo wrote:

>  I'm not really bothered as to whether we do anything about it now 
> or not given how close to publication the documents are. If you 
> want, just put this on the list for some future revision of the 
> document.

I think it would be better to add the clarifying text during AUTH48. 
It in no way makes a technical change to the document; it is an 
informative sentence which simply adds clarity, which I think is 
better done now rather than putting it off for a future revision.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I hope we shall...crush in its birth the aristocracy of our moneyed
corporations, which dare already to challenge our government to a
trial of strength, and bid defiance to the laws of our country.
                                                 --Thomas Jefferson?

---

From: Dave Cridland <[email-masked]>
Date: Sat, 08 Apr 2006 01:37:26 +0100

On Sat Apr  8 01:31:15 2006, Randall Gellens wrote:
> I think it would be better to add the clarifying text during 
> AUTH48. It in no way makes a technical change to the document; it 
> is an informative sentence which simply adds clarity, which I think 
> is better done now rather than putting it off for a future revision.

I'd agree - the explanation Mark gave Peter was particularly good, 
clear text, it seems a terrible shame to waste it by not including it 
in the document while we can.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Apr 2006 13:23:11 +0100

Randall Gellens wrote:

>>  I'm not really bothered as to whether we do anything about it now or 
>> not given how close to publication the documents are. If you want, 
>> just put this on the list for some future revision of the document.
>

I agree.