Subject: [lemonade] Comments on draft-ietf-lemonade-urlauth-07.txt

From: Randall Gellens <[email-masked]>
Date: Fri, 5 Aug 2005 02:44:39 -0700

Sorry for the late comments.  I think there are some minor 
fixes/clarifications needed, but these are no big deal.

Technical:

Section 3, lines 239-241: "Use of either of these access
     identifiers makes it impossible for an attacker, spying on the
     session, to use the same URL, either directly or by submission to a
     message submission entity."

The "impossible" depends on the attacker being able to capture the 
session, but not be able to use the same submission server or to 
capture the user's authentication credentials (for either the IMAP or 
submit services).  While this seems very obvious, and perhaps not 
worth saying, it does mean, for example, that an attacker who shares 
the same submission server can reuse a URLAUTH protected by 
"submit+", and an attacker who can capture the authorization 
credentials can of course access arbitrary data belonging to the 
user.  Likewise, if the attacker can capture the submission session, 
he or she can capture everything sent in that session, including 
messages sent without using BURL, so the risk the same either way, 
perhaps less with URLAUTH since the attacker may be thwarted by use 
of "submit+" or "user+".

Section 5, line 300: "case-folding MUST NOT occur"

I wonder if it is worth adding a parenthetical note that this applies 
to the domain portion of the URL as well as the rest of it.  There 
may be implementations which rely on the domain portion of URLs to be 
case-insignificant, but probably such implementations are rare enough 
that we're better off not doing anything.

May want to add an explanation of why the server would follow the 
exception in Section 6:
	In the case of an
     invalid userid supplied as mailbox access key owner and/or as part
     the access identifier, the server MAY issue a tagged OK response
     with a generated mailbox key that always fails validation when used
     with a URLFETCH command.

Editorial:

Section 1.4, line 140: "e.g" should be "e.g.,"

Section 2, line 165: "specific message" should be either "specific 
messages" or "a specific message".

Section 2, line 199, unclear if "must" means "MUST".

Section 3, line 236, "requires the session be" should be either 
"requires that the session be" or "requires the session to be"

Section 3, line 244, "level protection" should be "level of protection"

Section 6, line 391, "supplied as mailbox access key owner" maybe 
should be "supplied as the mailbox access key owner"

Section 6, line 391-392, "part the access identifier" should be "part 
of the access identifier".

Section9, line 638, "disclosed to anonymous" should probably be 
"disclosed to anyone".

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
As far as the laws of mathematics refer to reality, they are not
certain; and as far as they are certain, they do not refer to reality.
                                                    --Albert Einstein

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

---

From: Mark Crispin <[email-masked]>
Date: Fri, 5 Aug 2005 03:07:21 -0700 (PDT)

It's 3AM here, so please forgive me if I have a brain fart.

On Fri, 5 Aug 2005, Randall Gellens wrote:
> The "impossible" depends on the attacker being able to capture the session, 
> but not be able to use the same submission server or to capture the user's 
> authentication credentials (for either the IMAP or submit services).  While 
> this seems very obvious, and perhaps not worth saying, it does mean, for 
> example, that an attacker who shares the same submission server can reuse a 
> URLAUTH protected by "submit+",

I don't see how, given the semantics of submit+<userid>, which requires 
that "only a userid authorized as a message submission entity on behalf of 
the specified userid is permitted to use this URL.  Normally, this will be 
the current authorization userid on the submission server.

So the attacker must not merely share the same submision server; the 
attacker must be able to authorize as that userid on the submission 
server in order to reuse a URL protected by "submit+".

I don't think that I need to answer your other comments; the desired 
document action in each case all seems to be obvious.  Please let me know 
if you feel that you need feedback, since otherwise I intend to do the 
seemingly obvious when preparing it for an RFC.

If I'm not mistaken, this document has finished WGLC and is awaiting IESG 
action, correct?  If it's still in WGLC, I wouldn't mind issuing a new I-D 
with your action items addressed.

-- Mark --

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

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Aug 2005 15:12:16 -0700

At 3:07 AM -0700 8/5/05, Mark Crispin wrote:

>> capture the user's authentication credentials (for either the IMAP 
>> or submit services).  While this seems very obvious, and perhaps 
>> not worth saying, it does mean, for example, that an attacker who 
>> shares the same submission server can reuse a URLAUTH protected by 
>> "submit+",
>
>  I don't see how, given the semantics of submit+<userid>, which 
> requires that "only a userid authorized as a message submission 
> entity on behalf of the specified userid is permitted to use this 
> URL.  Normally, this will be the current authorization userid on 
> the submission server.
>
>  So the attacker must not merely share the same submision server; 
> the attacker must be able to authorize as that userid on the 
> submission server in order to reuse a URL protected by "submit+".

This comment was a minor one, since I don't think it affects the 
security considerations either way.

Likely I'm the one confused, but if user B captures a urlauth URL for 
user A, and shares the same servers, then B can submit a new message 
using the same urlauth URL, right?  If they don't share the same 
servers (both submission and IMAP), then this won't work.

Also, if B can capture the message submission of A, then B can 
directly capture data not referenced by a URL, and this is a threat 
regardless of the use of urlauth or not.

>
>  I don't think that I need to answer your other comments; the 
> desired document action in each case all seems to be obvious.

I agree, the bulk of my comments were requests for minor wording 
tweaks or typo corrections.

>    Please let me know if you feel that you need feedback, since 
> otherwise I intend to do the seemingly obvious when preparing it 
> for an RFC.

No need to respond to each of my comments individually.

>  If I'm not mistaken, this document has finished WGLC and is 
> awaiting IESG action, correct?  If it's still in WGLC, I wouldn't 
> mind issuing a new I-D with your action items addressed.

My understanding is it has passed WGLC.  I anticipated that my 
comments would get addressed with IETF Last Call or IESG comments, if 
any; if there are none then AUTH48 will do.

-------------- Randomly-selected tag: ---------------
There's only one corner of the universe you can be certain of
improving that's your own self.               --Aldous Huxley

---

From: Mark Crispin <[email-masked]>
Date: Tue, 9 Aug 2005 15:22:30 -0700 (Pacific Daylight Time)

On Tue, 9 Aug 2005, Randall Gellens wrote:
> Likely I'm the one confused, but if user B captures a urlauth URL for user A, 
> and shares the same servers, then B can submit a new message using the same 
> urlauth URL, right?

No; because the submit server is supposed to validate that the userid in a 
submit+<userid> is the userid used to log into the submit server.  Since 
user B can't log in as user A to the submit server, that loophole is 
closed.

Also, user B can't use that urlauth URL with the IMAP server directly, 
because user B isn't a submit server.

> Also, if B can capture the message submission of A, then B can directly 
> capture data not referenced by a URL, and this is a threat regardless of the 
> use of urlauth or not.

Correct.

-- Mark --

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Aug 2005 16:36:02 -0700

At 3:22 PM -0700 8/9/05, Mark Crispin wrote:

>>  Likely I'm the one confused, but if user B captures a urlauth URL 
>> for user A, and shares the same servers, then B can submit a new 
>> message using the same urlauth URL, right?
>
>  No; because the submit server is supposed to validate that the 
> userid in a submit+<userid> is the userid used to log into the 
> submit server.  Since user B can't log in as user A to the submit 
> server, that loophole is closed.

Indeed.  I missed this.  Thanks.

-------------- Randomly-selected tag: ---------------
farpotshket (far-POTCH-ket; Yiddish; noun): something that is all
fouled up, especially as the result of an attempt to fix it.