Subject: RE: [lemonade] Working Group Last Call on URLAUTH

From: [email-masked]
Date: Thu, 21 Oct 2004 13:51:44 -0500

> -----Original Message-----
> From: ext Mark Crispin [mailto:[email-masked]]
> Sent: Thursday, October 21, 2004 11:13 AM
> To: Wener Michael (Nokia-ES/Pittsburgh)
...
> On Thu, 21 Oct 2004 [email-masked] wrote:
> > If I have orgA and orgB both gaining access to sec 1.2 and sec 1.3 
> > respectively how does the URLFETCH processing server tell the 
> > difference?
> 
> Are you asking how does the URLFETCH processing server know which 
> organization is accessing the data?  It doesn't.  If you want 

No.

I'm asking how the URLFETCH processing server knows which organization the accessing user is a part of.

So userA has a URLAUTH url. He logs into an IMAP server and issues the URLFETCH. Authuser is supposed to restrict access only to users of a certain organization. How does the imap server know when to allow access? Why couldn't userB from some other organization use the URL as well?

> 
> > I saw it as a 
> > way of tagging the Authorized URL as being from some 
> account. Given this 
> > I would think something along the lines of 
> anonymous+<userid> would be 

I was confusing the granted userid with the granting userid. In this case I was thinking of userid as the granting userid.

Mike

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

---

From: Mark Crispin <[email-masked]>
Date: Thu, 21 Oct 2004 12:08:57 -0700 (PDT)

On Thu, 21 Oct 2004 [email-masked] wrote:
>> organization is accessing the data?  It doesn't.
> No.

I don't see any real difference between these two.  It's just two ways of 
saying the same thing.

> So userA has a URLAUTH url. He logs into an IMAP server and issues the 
> URLFETCH. Authuser is supposed to restrict access only to users of a 
> certain organization. How does the imap server know when to allow 
> access? Why couldn't userB from some other organization use the URL as 
> well?

I think that you may have misunderstood authuser.  Authuser restricts 
access to authorized users of the IMAP server.  In other words, the 
"organization" for authuser is the "set of individuals who have accounts 
on the IMAP server."

userB can't use an authuser URLAUTH URL unless she has an account on the 
IMAP server.

Let's see if this clarifies things for you.  mrc creates a URLAUTH URL, 
and gives the URL to annie.  Here's the requirements set by each access 
identifier:

Existing:
---------
user+annie	annie must be able to log into the IMAP server as annie.
 		Nobody but annie can access it, and annie can't submit a
 		message that asks the submit server to use it.
submit+annie	the submit server must log into the IMAP server after it
 		has verified that it was annie making the request.  annie
 		can't access it directly.  Nobody else can submit a
 		message that asks the submit server to use it.

Proposed:
---------
authuser	anyone who can log into the IMAP server (it doesn't
 		matter what userid) can use this URL directly.  Anyone who
 		is authorized to submit a message to the submit server can
 		submit a message that asks the submit server to use it.
anonymous	anyone can use this URL directly.

For the purposes of Lemonade forward-without-download, only 
submit+<userid> is needed.  However, other Lemonade purposes 
(specifically, CATENATE) may also find user+<userid> useful.

authuser and anonymous are not needed for Lemonade, but I believe would be 
useful for other purposes.

> I was confusing the granted userid with the granting userid. In this 
> case I was thinking of userid as the granting userid.

That's identified in the basic IMAP URL, not in the URLAUTH extension.

-- Mark --

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Oct 2004 14:55:02 -0700

At 12:08 PM -0700 10/21/04, Mark Crispin wrote:
>
>Let's see if this clarifies things for you.  mrc creates a URLAUTH 
>URL, and gives the URL to annie.  Here's the requirements set by 
>each access identifier:
>
>Existing:
>---------

Just to be clear, the reason you don't want to do this by creating
an actual userid called "anonymous"  is that Annie, logged in as
"anonymous", should not get any other rights than to fetch a
specfic URI  and letting her log in as "anonymous" might grant
those rights?

Or am I missing something here?
				Ted

---

From: Mark Crispin <[email-masked]>
Date: Thu, 21 Oct 2004 15:09:56 -0700 (Pacific Daylight Time)

> specfic URI  and letting her log in as "anonymous" might grant

As in FTP, anonymous is a special access class in IMAP.  There is a 
specific SASL authentication mechanism named ANONYMOUS (RFC 2245) which 
replaces the old convention of logging in with a username of anonymous.

The precise semantics of anonymous access in IMAP are dictated by the 
server implementation and by server management policy.  In UW imapd, 
anonymous is disabled unless explicitly enabled by site management, is 
allowed access only to certain namespaces (#news, #ftp, #public), and 
numerous commands are disabled (e.g. COPY, APPEND, CREATE, DELETE, etc.) 
or crippled (SELECT always becomes EXAMINE), etc.

In any case, logging in as anonymous with any password is considered to be 
an obsolete convention now that the ANONYMOUS SASL mechanism exists.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Oct 2004 16:20:03 -0700

At 3:09 PM -0700 10/21/04, Mark Crispin wrote:
>specific SASL authentication mechanism named ANONYMOUS (RFC 2245) 
>which replaces the old convention of logging in with a username of 
>anonymous.
>
>The precise semantics of anonymous access in IMAP are dictated by 
>the server implementation and by server management policy.  In UW 
>imapd, anonymous is disabled unless explicitly enabled by site 
>management, is allowed access only to certain namespaces (#news, 
>#ftp, #public), and numerous commands are disabled (e.g. COPY, 
>APPEND, CREATE, DELETE, etc.) or crippled (SELECT always becomes 
>EXAMINE), etc.
>
>In any case, logging in as anonymous with any password is considered 
>to be an obsolete convention now that the ANONYMOUS SASL mechanism 
>exists.
>

Okay; I was working from RFC 2192's description of the URI scheme,
which predates  RFC 2245.  I read it to mean there were multiple possible
auth types, not just SASL.  To be clear I've got your explanation
right, let me reflect it back:  "IMAP  no longer allows a userid 
anonymous; there
is a set of rights grants to those logging in using SASL anonymous,
but that is never associated with a userid".  Right?

  As an aside, is there a planned update of RFC 2192?

Let's go back to the example a moment:

imap://[email-masked]/INBOX/;uid=20/;section=1.2;expire=2004-10-20T20:45:00-0700;urlauth=anonymous:internal:91354a473744909de610943775f92038

Though I can see the use case for this, I don't think it is in the core part of
the forward-without-download mission for this.  If we start to think about
URLAUTH as a more general mechanism, I suspect that we may want to
think about other things as well (for example, generalizing submit+).
My personal 2 cents are on keeping this as lean as possible at the moment,
and considering expansion later.

			regards,
				Ted

---

From: Mark Crispin <[email-masked]>
Date: Thu, 21 Oct 2004 16:53:04 -0700 (Pacific Daylight Time)

On Thu, 21 Oct 2004, Ted Hardie wrote:
> To be clear I've got your explanation
> right, let me reflect it back:  "IMAP  no longer allows a userid anonymous; 
> there

It isn't a question of allowing or disallowing userid anonymous; userid 
anonymous was nothing more than a convention with no official status. 
The ANONYMOUS mechanism for SASL has official status.

> As an aside, is there a planned update of RFC 2192?

I don't know.

> Though I can see the use case for this, I don't think it is in the core 
> part of the forward-without-download mission for this.

I thought that I already said this.  Neither anonymous nor authuser are 
needed for Lemonade forward-without-download.  The issue at hand is that 
they were anticipated as part of URLAUTH from inception, were removed from 
URLAUTH as it was causing a distraction to the push/pull discussion.

The question is simply: is it alright to put them back?  If they do not go 
into URLAUTH now I will probably promptly produce a non-WG URLAUTH 
Extensions document for them, since I have other (non-Lemonade) purposes 
for these.  In fact, not having these two would diminish much of the 
reason that I have to implement URLAUTH.

> If we start to 
> think about URLAUTH as a more general mechanism, I suspect that we may 
> want to think about other things as well (for example, generalizing 
> submit+). My personal 2 cents are on keeping this as lean as possible at 
> the moment, and considering expansion later.

I'm sympathetic to this; you'll notice that I haven't mentioned anything 
about client-created URLAUTHs and the necessary non-INTERNAL mechanisms to 
allow such.  But, at least for me, anonymous and authuser are pretty basic 
to a URLAUTH facility and are significant attractants for server 
implementors who would otherwise not care able the Lemonade community.

-- Mark --