Subject: [lemonade] URLAUTH document

From: Mark Crispin <[email-masked]>
Date: Thu, 11 Aug 2005 15:34:25 -0700 (PDT)

Ken and Randall's nits hit (what is to me) a critical mass, so I have 
prepared a draft -08.  I believe that all their nits are addressed, with 
no changes to the protocol as we approved it.

I also think that the new formal syntax is superior, as it no longer 
changes any rules in [IMAPURL] and for the first time actually has formal 
syntax for the concept of a "rump URL".  Nevertheless, it needs a going 
over by the group.

I haven't submitted this draft to the I-D repository, but I've attached it 
to this message.  Please review.  The set of diffs are pretty small.

-- 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: Ken Murchison <[email-masked]>
Date: Thu, 18 Aug 2005 09:13:59 -0400

Mark Crispin wrote:

> Introduction
> 
>    In [IMAPURL], a URL of the form imap://[email-masked]/INBOX/;uid=20
>    requires authorization as userid "fred".

This sentence bothers me each time I read it.  In my mind, the above URL 
requires *authentication* as userid "fred" with implicit authorization 
as "fred" (since we can't specify an authzid in the URL).  After all, 
any password/secret passed via IMAP LOGIN or a SASL mech corresponds to 
the authid, not the authzid.  Should this fact be captured in the text 
somehow?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     2495 Main St. - Suite 401
716-604-0088 x26      Buffalo, NY 14214
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Dave Cridland <[email-masked]>
Date: Thu, 18 Aug 2005 17:10:01 +0100

On Thu Aug 18 06:13:59 2005, Ken Murchison wrote:
> This sentence bothers me each time I read it.  In my mind, the 
> above URL requires *authentication* as userid "fred" with implicit 
> authorization as "fred" (since we can't specify an authzid in the 
> URL).  After all, any password/secret passed via IMAP LOGIN or a 
> SASL mech corresponds to the authid, not the authzid.  Should this 
> fact be captured in the text somehow?

I thought the "username" present in the URI was the one used for 
authorization - what authentication identifier is used to gain that 
authorization identity was up to the client processing it. In other 
words, I didn't think anything was wrong with the text.

That seems to hold for this example - if I authenticated with the 
identifier "superuser", supplying an authorization identifier "fred", 
then that URI points to "Fred's Inbox", which is what we want. Thus 
to use that URI, I must be authorized as userid "fred", which is what 
the text says.

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 18 Aug 2005 10:56:46 -0700 (PDT)

On Thu, 18 Aug 2005, Dave Cridland wrote:
> authorization identity was up to the client processing it. In other words, I 
> didn't think anything was wrong with the text.

I agree with Dave's analysis.  Authorization is what is important for 
URLAUTH.  In the case of
 	imap://[email-masked]/INBOX/;uid=20
it is necessary to be authorized as "fred" in order to use it.  It doesn't 
matter if the authentication id is "sally"; if sally is authorized as fred 
she can use that URL.

I agree that the semantics of the imap URL userid are overloaded.  In 
addition to representing authorization id, it also represents namespace. 
In the above example, INBOX is fred's INBOX, not sally's INBOX.  This is 
probably alright since IMAP helpfully has the NAMESPACE extension, e.g.,
 	imap://[email-masked]/~sally/INBOX/;uid=20
or, preferably:
 	imap://[email-masked]/#user.sally/INBOX/;uid=20

However, I sympathize with Ken's protests that this overload, along with 
the lack of authentication id specification, creates complexity.

Matters are further complicated by URLAUTH's addition of user+ and 
submit+.

user+ effectively adds two layers of authorization id.  Consider:
  imap://[email-masked]/#user.sally/INBOX/;uid=20;urlauth=user+judy ...

So, larry authenticates, and authorizes as judy.  He then does URLFETCH, 
which accesses sally's INBOX while authorized as fred.

Whew!

-- Mark --

---

From: Marc Perkel <[email-masked]>
Date: Thu, 18 Aug 2005 11:17:08 -0700

>     imap://[email-masked]/INBOX/;uid=20

I'm a little confused. How do you know the UID of the other person and 
what makes you assume they even have a UID?

---

From: Mark Crispin <[email-masked]>
Date: Thu, 18 Aug 2005 11:28:39 -0700

On Thu, 18 Aug 2005, Marc Perkel wrote:
> I'm a little confused. How do you know the UID of the other person and what 
> makes you assume they even have a UID?

I'm a lot confused.  I have read this question.  I can make no sense out 
of it.

Or rather, the only sense that I can make out of it requires that you have 
not read RFC 2192 and the URLAUTH document.

-- Mark --

---

From: Ken Murchison <[email-masked]>
Date: Thu, 18 Aug 2005 17:05:10 -0400

> what makes you assume they even have a UID?

You need to read RFC 2192.  The UID in the URL is the UID of a 
particular message in the specified mailbox.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Aug 2005 21:35:08 +0100

Ken Murchison wrote:

> This sentence bothers me each time I read it.  In my mind, the above 
> URL requires *authentication* as userid "fred" with implicit 
> URL).  After all, any password/secret passed via IMAP LOGIN or a SASL 
> mech corresponds to the authid, not the authzid.  Should this fact be 
> captured in the text somehow?

I wonder if this needs to be clarified in IMAP URL revision that I am 
planning to do shortly.
(And I agree with Mark/Dave that the URL has authorization id "fred", 
but if the password is specified authentication id == authorization id).

---

From: Ken Murchison <[email-masked]>
Date: Fri, 19 Aug 2005 14:00:21 -0400

Mark Crispin wrote:

> it is necessary to be authorized as "fred" in order to use it.  It 
> doesn't matter if the authentication id is "sally"; if sally is 
> authorized as fred she can use that URL.

Hmm, it seems like we're trying to assign different meanings to the URL 
tokens depending on the context (which MAY be OK).  My reading of RFC 
2192 still leads me to believe that iuserauth is the id to be used for 
authenticating to the server (using the optionally supplied mechanism). 
  Since authorization info can't be passed as part of the URL, the 
authorization id becomes the same as the authorization id, which also 
provides the context for INBOX.

This bit of text from RFC 2192 seems pretty clear that iuserauth is the 
authentication id:

"A program interpreting IMAP URLs MAY cache open connections to an IMAP 
server for later re-use.  If a URL contains a user name, only 
connections authenticated as that user may be re-used."
             ^^^^^^^^^^^^^^

For URLAUTH, we're assuming that the client/user has already 
authenticated, therefore iuserauth only gives the context for INBOX. 
But I'm not sure that stating that iuserauth is only used for 
authorization without mentioning authentication is entirely correct.

Perhaps Chris can shed some light on this.

That being said, I don't intend to holdup progress of this draft based 
on semantics.

---

From: Mark Crispin <[email-masked]>
Date: Fri, 19 Aug 2005 12:36:07 -0700 (PDT)

On Fri, 19 Aug 2005, Ken Murchison wrote:
> tokens depending on the context (which MAY be OK).  My reading of RFC 2192 
> still leads me to believe that iuserauth is the id to be used for 

I think that this is best explained by RFC 2192 being written at a time 
prior to the concept of authorization vs. authentication id.  This is 
something that should be addressed in an update to RFC 2192, and not by 
the URLAUTH document.

-- Mark --