Subject: [Gen-art] Gen-ART review of lemonade drafts in IESG review

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 01 Sep 2005 01:57:42 -0700

Drafts under review:

Internet Message Access Protocol (IMAP) CATENATE Extension (Proposed 
Standard) - 2 of 10
<http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-05.txt>draft-ietf-lemonade-catenate-05.txt 

Internet Message Access Protocol (IMAP) - URLAUTH Extension (Proposed Standard)
<http://www.ietf.org/internet-drafts/draft-ietf-lemonade-urlauth-07.txt>draft-ietf-lemonade-urlauth-07.txt 

Message Submission BURL Extension (Proposed Standard)
<http://www.ietf.org/internet-drafts/draft-ietf-lemonade-burl-02.txt>draft-ietf-lemonade-burl-02.txt

Background for those who may be unaware of GenART:

GenART is the Area Review Team for the General Area of the IETF.
We advise the General Area Director (i.e., the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected as the
GenART member to review this document.  Below is my review, which was
written specifically with an eye to the GenART process, but since I
believe that it will be useful to have these comments more widely
distributed, others outside the GenART group are included.

Summary:  Generally ready for publication ...  I see some discuss comments 
already, and I have some questions/comments myself.

BURL
-------

No additional issues other than those on the tracker already.

What does BURL stand for?

There are some typos toward the end of the security considerations 
section.  Please run a spell check.  Also, the RFC ed process will take 
care of it too.

Lemonda-Catenate:
------------------------

Note: The author of this draft, Pete Resnick and I are colleagues, however 
I was not aware of this work until I read the draft for the first time to 
review it for Gen-ART.

*) I would like to see more in the security considerations section.  I 
understand that the draft says the proposal does not introduce any 
threats.  However, this is in contradiction to the BURL draft's sec 
considerations section.  I think that the first part of that section might 
be appropriate in this draft as well.

*) The draft says "Responses behave just as the original APPEND command 
described in IMAP [1]."
But the examples are somewhat inconsistent (may be I am being too picky):
In Example 1:
S: A003 OK catenate append completed

In Example 3:
A003 OK append Completed

In Example 4:
... CATENATE append has failed, one message expunged

Should they all use the keyword APPEND?  Is the keyword CATENATE allowed in 
responses?  I realize it is allowed in capabilities as specified in Section 5.

URLauth
-----------

* I am uncomfortable with the word Authorization and the mechanisms for it 
in this draft.  However, it is late in the process to have a philosophical 
discussion.  Since this is a WG consensus, I can live with it.

   To explain: The first sentence notes that RFC 2192 requires authorization

My reading of that RFC is that it is talking about authenticating a user 
and then verifying whether the user is authorized to 
read/read-write.  Authorization comes from local policy and enforced after 
authenticating the user.

Section 1.4 concerns me.  First, I am not sure I understand the use of 
HMAC-SHA-1 as an authorization mechanism.  More importantly, the draft only 
recommends something such as that algorithm and notes that there is no way 
to change the algorithm without severe consequences.  While HMAC is holding 
up, there are concerns about SHA-1 already; I am not sure about advancing 
protocol specs in which algorithms cannot be updated.

best regards,
Lakshminath

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 01 Sep 2005 02:08:26 -0700

cc'ing the WG chairs, and noting that

Iin the URLAUTH I-D, the following reference needs to be updated:

[BURL]     Newman, C., "Message Submission BURL Extension",
                draft-newman-lemonade-burl-00.txt (work in progress),
                March 2004.

thanks and regards,
Lakshminath

At 01:57 AM 9/1/2005, Lakshminath Dondeti wrote:
>*) The draft says "
>Responses behave just as the original APPEND command described in IMAP [1]."
>Should they all use the keyword APPEND?  Is the keyword CATENATE allowed 
>in responses?  I realize it is allowed in capabilities as specified in 
>Section 5.
>
>URLauth
>-----------
>
>HMAC-SHA-1 as an authorization mechanism.  More importantly, the draft 
>only recommends something such as that algorithm and notes that there is 
>no way to change the algorithm without severe consequences.  While HMAC is 
>holding up, there are concerns about SHA-1 already; I am not sure about 
>advancing protocol specs in which algorithms cannot be updated.
>
>
>best regards,
>Lakshminath

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 01 Sep 2005 14:37:07 +0200

minor metacomment, just in case Gen-ART remembers it next time an IMAP 
document comes around...

In IMAP responses such as these, the structure is
[tag] [status] [completely free text]
If there is stuff in there that is supposed to be machine parseable, it is 
enclosed in square brackets.

so the responses

  A003 OK catenate append completed

and

  A003 OK Gollum is a Troll

are completely equivalent, from a protocol perspective.

                     Harald

--On 1. september 2005 01:57 -0700 Lakshminath Dondeti 
<[email-masked]> wrote:

> ) The draft says "Responses behave just as the original APPEND command
> described in IMAP [1]."

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Thu, 1 Sep 2005 07:33:02 -0700

Thanks Harald.  I will keep that in mind.

regards,
Lakshminath

-----Original Message-----
From: Harald Tveit Alvestrand [mailto:[email-masked]]
Sent: Thu 9/1/2005 5:37 AM
To: Dondeti, Lakshminath; [email-masked]
Subject: Re: [Gen-art] Gen-ART review of lemonade drafts in IESG review

so the responses

and

                     Harald

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 01 Sep 2005 09:32:30 -0700

I was clued in earlier today that the OK responses as specified in the 
-catenate- I-D are semantically correct.  Apologies for my ignorance of the 
format of those messages.  (I was using the examples in the RFCs in the 
area as my reference, and didn't look for the formal syntax)

regards,
Lakshminath

At 02:08 AM 9/1/2005, Lakshminath Dondeti wrote:
>>Summary:  Generally ready for publication ...  I see some discuss 
>>comments already, and I have some questions/comments myself.
>>
>>BURL
>>-------
>>
>>Note: The author of this draft, Pete Resnick and I are colleagues, 
>>however I was not aware of this work until I read the draft for the first 
>>time to review it for Gen-ART.
>>
>>considerations section.  I think that the first part of that section 
>>might be appropriate in this draft as well.
>>
>>*) The draft says "
>>
>>* I am uncomfortable with the word Authorization and the mechanisms for 
>>it in this draft.  However, it is late in the process to have a 
>>philosophical discussion.  Since this is a WG consensus, I can live with it.
>>
>>read/read-write.  Authorization comes from local policy and enforced 
>>after authenticating the user.
>>
>>no way to change the algorithm without severe consequences.  While HMAC 
>>is holding up, there are concerns about SHA-1 already; I am not sure 
>>about advancing protocol specs in which algorithms cannot be updated.
>>
>>
>>best regards,
>>Lakshminath

---

From: Mark Crispin <[email-masked]>
Date: Thu, 1 Sep 2005 09:46:57 -0700 (PDT)

>               draft-newman-lemonade-burl-00.txt (work in progress),

OK, noted in my set of in-progress -08 updates to the URLAUTH document.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 1 Sep 2005 10:35:52 -0700 (PDT)

Hi -

I'd like to respond your comments about the URLAUTH document.  Please let 
me know if these responses adequately address your concerns, or if I need 
to respond in some other way.  If you recommend any changes in wording, I 
would be happy to oblige.

On Thu, 1 Sep 2005, Lakshminath Dondeti wrote:
> My reading of that RFC is that it is talking about authenticating a user and 
> then verifying whether the user is authorized to read/read-write. 
> Authorization comes from local policy and enforced after authenticating the 
> user.

I assume that you're talking about the first sentence in the URLAUTH 
document abstract; if not, what I'm about to say may not make sense.

Yes, RFC 2192 talks about authentication, but it muddles the waters 
between authentication, authorization, and namespace identification.  This 
isn't terribly surprising, because it preceeds the understanding of these 
as separate concepts.

The result is that RFC 2192's authentication mechanisms are not 
particularly useful.

URLAUTH replaces and redefines all of this.

URLAUTH defines an *authorization* mechanism; the URL name itself conveys 
authorization.  A portion of the syntax of the RFC 2192 authentication 
mechanism is reused to convey the authorization ID (which also defines the 
default namespace in the IMAP context).  Other portions are likely to be 
abandoned in an update to RFC 2192 which is under initial discussion.

URLAUTH uses the existing RFC 2192 mechanisms to limit the authorization 
to a particular datum; it is impossible to use the URLAUTH-gained 
authorization to access other data even if the authorization ID conveyed 
by URLAUTH would have that access.

URLAUTH has additional mechanisms to restrict use of the URL to certain 
authentication IDs; anyone, a specific user, or a submission server acting 
on behalf of a specific user.  It also has mechanisms for expiration.

> HMAC-SHA-1 as an authorization mechanism.

OK.  Please understand that the following explanation uses some very 
specific technical terms as layman's language; and consequently deviates 
from the strict technical interpretation.  [This is to preclude people 
from beating me up for abusing these terms!]

URLAUTH is simply a mechanism by which a pointer to the desired data is 
signed by an authorized entity to access that data.  That pointer can be 
used by some other entity to access the data.

In effect, it's saying "Bob gave me this pointer which has this dongle at 
the end that proves that only Bob could have generated the pointer. 
Since this proves Bob's permission, please use Bob's access to give me 
that data."

The basic idea is that the pointer to the data is one-way encoded along 
with a secret known only to Bob, and the result of that encoding is the 
dongle.  Any alteration to the pointer requires a different dongle.  In 
addition, any restrictions placed by Bob are in the dongle *and* in the 
encoding in the dongle, so those restrictions can't be changed either.

Think of how CRAM-MD5 or HMAC-MD5 SASL authentication works.

Originally, URLAUTH was going to use MD5, but with the increasing 
discomfort about using MD5 it was changed to SHA-1.

> More importantly, the draft only 
> recommends something such as that algorithm and notes that there is no way to 
> change the algorithm without severe consequences.

I'm not sure what you mean, unless you are talking about the comment about 
"all currently existing URLAUTH authorized URLs are invalidated."  It's 
expected that the lifetime of most URLAUTH authorized URLs would be 
relatively short.

Although a mass revocation is not something done lightly, it's also 
something that I expect will happen from time to time.  Consider the 
functionality for a user to mass-revoke all his issued URLAUTH authorized 
URLs.

I don't think that this is a major problem.  A change in algorithm could 
have a short period in which a hash from both old and new algorithms are 
accepted.  The worst-case is if SHA1 is cracked in a way that can derive 
the secret keys given a valid URLAUTH; that would probably require change 
of algorithm and change of all keys.

>  While HMAC is holding up, 
> there are concerns about SHA-1 already; I am not sure about advancing 

The specification does not stipulate SHA1; it only recommends it.  This 
recommendation could change over time.

-- Mark --

http://panda.com/mrc

---

From: Pete Resnick <[email-masked]>
Date: Thu, 1 Sep 2005 13:31:17 -0500

On 9/1/05 at 1:57 AM -0700, Lakshminath Dondeti wrote:

>Lemonda-Catenate:
>------------------------
>
>I would like to see more in the security considerations section.  I 

I see nothing in the BURL security considerations which is applicable 
to the CATENATE extension. For instance, the first part of that 
section talks about fetching content before content-based security 
filters are used. But CATENATE does not fetching of content, so I'm 
not clear how that is applicable. Please point out anything in that 
section that might apply to CATENATE. I'm missing it.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 01 Sep 2005 11:53:57 -0700

At 11:31 AM 9/1/2005, Pete Resnick wrote:
>I see nothing in the BURL security considerations which is applicable to 
>the CATENATE extension. For instance, the first part of that section talks 
>about fetching content before content-based security filters are used. But 
>CATENATE does not fetching of content, so I'm not clear how that is 
>applicable. Please point out anything in that section that might apply to 
>CATENATE. I'm missing it.
>
>pr
>--

Hi Pete,

Sorry for the terse comments earlier.  Here is what I thought might be 
worth including (it is quite plausible that these were considered and 
thought to be insignificant and left out of the spec):

Paragraph 2 of Section 8 in the BURL I-D notes "this mechanism would make
    it feasible for a programmable cell phone or other device on a slow
    link to become a significant source of unsolicited bulk email and/or
    viruses" and suggests  it is " ... more important ... to have ... 
mandatory authentication"

Along the same lines, one of the ways to mitigate DoS attacks is to make 
the potential attacker to do some work.  These set of lemonade drafts 
specify protocols (definitely useful features all of them) that make it 
easier for a client to construct large messages, and so perhaps the 
Security considerations sections should talk about the implications of that.

I have quickly read the security considerations sections of 2192 and 3501 
and did not find any discussion along those lines.  Apologies in advance if 
I misread.

Many thanks for considering the comments.

best regards,
Lakshminath

---

From: Pete Resnick <[email-masked]>
Date: Thu, 1 Sep 2005 13:59:57 -0500

On 9/1/05 at 11:53 AM -0700, Lakshminath Dondeti wrote:

>Here is what I thought might be worth including (it is quite 
>plausible that these were considered and thought to be insignificant 
>and left out of the spec):
>

But since you can't send mail with CATENATE, this doesn't apply, right?

pr

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 01 Sep 2005 12:26:43 -0700

At 11:59 AM 9/1/2005, Pete Resnick wrote:
>>Here is what I thought might be worth including (it is quite plausible 
>>that these were considered and thought to be insignificant and left out 
>>of the spec):
>>

I did miss that part, definitely.  My mistake.  However, if a 
current/future doc specifies sending mail created using CATENATE, the 
security considerations apply.  I fear that document might point to this 
one and say look there for security considerations.

This probably borders on a nit at this point, since the BURL I-D discusses 
the threat and so the implementor has been warned.

At this point, it looks like my review served no one but me :-).

thanks and regards,
Lakshminath

---

From: Mark Crispin <[email-masked]>
Date: Thu, 1 Sep 2005 12:44:38 -0700 (PDT)

On Thu, 1 Sep 2005, Lakshminath Dondeti wrote:
> However, if a current/future 
> doc specifies sending mail created using CATENATE, the security 
> considerations apply.  I fear that document might point to this one and say 
> look there for security considerations.

Speaking from the point of view of someone who has been adamantly opposed 
to any sort of mail-sending feature in IMAP since the day I created IMAP, 
I think that it's a good thing that there are unresolved security issues 
with such a feature.

That particular proposed feature has proven to be an attractive nuisance; 
it *is* tempting to do everything in one protocol.  We're already seeing a 
(deplorable) tendency to make port 80 do all services.

Thus, I perceive these security considerations to be an additional 
roadblock in the path of a deceptively simple-seeming shortcut that avoids 
the work of doing the right thing.

-- Mark --

http://panda.com/mrc

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 Sep 2005 09:40:03 +0200

Lakshminath Dondeti wrote:
...
> At this point, it looks like my review served no one but me :-).

Let me reassure you. All Gen-ART reviews and the follow-up discussions
are of considerable value to me! I tend to operate on the principle that
if something is unclear to a Gen-ART reviewer, it is probably unclear
to a fair percentage of readers and needs to be checked or explained.

    Brian

---

From: Mark Crispin <[email-masked]>
Date: Sun, 4 Sep 2005 09:45:07 -0700

> to a fair percentage of readers and needs to be checked or explained.

For what it's worth, I agree.

-- Mark --

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 14 Sep 2005 22:16:16 -0700

Hi Mark,

Many thanks for your patience.  I have been meaning to get back to you, but 
other things kept getting in the way.  Here are some thoughts so we can 
close this from my PoV:

At 10:35 AM 9/1/2005, Mark Crispin wrote:
>>and then verifying whether the user is authorized to read/read-write. 
>>Authorization comes from local policy and enforced after authenticating 
>>the user.
>

I was referring to the first sentence of the Introduction.

>URLAUTH replaces and redefines all of this.

It was not clear to me from the draft that is replacing the notions in 
2192.  Perhaps it might make sense to state the above.  Something along the 
lines of (hope this makes sense): A URL of the form ... requires 
authorization ...; however RFC2192 only supports authentication.  URLAUTH 
extension defines an authorization mechanism to facilitate this.

Furthermore, this email and the notes in the tracker "
The URLAUTH extension to IMAP
provides a means by which an IMAP client can use URIs carrying authorization
to access limited message data on the IMAP server.  These URIs, like a pawn
ticket, can be redeemed by whoever presents them and carry no authentication
information."
helped clarify the draft to me.  It could be because I am so new to this area.

The long second sentence in the second paragraph of the Introduction was 
hard to parse.  (When I read it again just now it makes perfect sense :-)).

Perhaps the Introduction section might be expanded to include the above 
quoted text (some version of it is fine).

Q: May be I am confused, but is the part about "can be redeemed by whoever 
presents them and carry no authentication information" always true?  I 
think the draft says anonymous, any authenticated user, and a specific user 
mode are all supported.

>on behalf of a specific user.  It also has mechanisms for expiration.

The above points are also useful and might be appropriate to include (to 
whatever extent you are comfortable) in the first section of the I-D.

>the end that proves that only Bob could have generated the pointer. Since 
>this proves Bob's permission, please use Bob's access to give me that data."
>

I understand this now.  Let me repeat this with the various options possible.

Bob can give such access to "Alice"
or any "authuser" (any user which the server can identify)
or to anyone, i.e., anonymous access (the security considerations section 
clarifies the latter two options).

Do I have it right?

>>More importantly, the draft only recommends something such as that 
>>algorithm and notes that there is no way to change the algorithm without 
>>severe consequences.
>

I am referring to the 3rd paragraph of Section 1.4, starting with "Note: 
."  NIST is currently going through an exercise to pick next generation 
hash functions and might suggest a new hash function to use starting in 
2010.  So, in about 5 years or so, we may have to start thinking about 
changing the recommended algorithm in this draft.  In other words, it 
appears that the advice in the last part of the last sentence in the note 
cannot easily followed.  (BTW, there is a new paper by Steve Bellovin and 
Eric Rescorla on how to deploy a new hash function that discusses other 
protocols that will be facing this problem.)

In summary, it looks like I had some trouble understanding the 
draft.  Perhaps revisions in the areas we touched on in this thread might 
help, or perhaps I should stick to reviewing drafts in the areas that I am 
more familiar with.

Thanks again for your patience Mark!

best wishes,
Lakshminath

>functionality for a user to mass-revoke all his issued URLAUTH authorized URLs.
>
>>  While HMAC is holding up, there are concerns about SHA-1 already; I am 
>> not sure about advancing protocol specs in which algorithms cannot be updated.
>

---

From: Mark Crispin <[email-masked]>
Date: Fri, 16 Sep 2005 18:22:45 -0700 (Pacific Daylight Time)

On Wed, 14 Sep 2005, Lakshminath Dondeti wrote:
> It was not clear to me from the draft that is replacing the notions in 2192. 
> Perhaps it might make sense to state the above.  Something along the lines of 
> (hope this makes sense): A URL of the form ... requires authorization ...; 
> however RFC2192 only supports authentication.  URLAUTH extension defines an 
> authorization mechanism to facilitate this.

OK, I'll make a note of this.  Actually, it is better to characterize it 
as the URLAUTH specification replaces RFC 2192's incomplete and not 
particularly useful authentication mechanism with an authorization 
mechanism.

> The long second sentence in the second paragraph of the Introduction was hard 
> to parse.  (When I read it again just now it makes perfect sense :-)).

I'll fix that.  Thanks.

> quoted text (some version of it is fine).

I'll do that as well.  Thanks.

> presents them and carry no authentication information" always true?  I think 
> the draft says anonymous, any authenticated user, and a specific user mode 
> are all supported.

You are correct.  URLAUTH has a means to limit who can use the URL.

> whatever extent you are comfortable) in the first section of the I-D.

OK.

> clarifies the latter two options).

Correct.  There is an additional option:

Bob can give access to a submission server acting on behalf of "Alice". 
The means by which the IMAP server knows that the IMAP client is a 
submission server is left to the implementation, but presumably some set 
of authentication/authorization credentials are registered as belonging to 
submission servers.

> I am referring to the 3rd paragraph of Section 1.4, starting with "Note: ." 
> NIST is currently going through an exercise to pick next generation hash 
> functions and might suggest a new hash function to use starting in 2010.  So, 
> in about 5 years or so, we may have to start thinking about changing the 
> recommended algorithm in this draft.  In other words, it appears that the 
> advice in the last part of the last sentence in the note cannot easily 
> followed.

The intent of that advice is to eschew choosing mechanisms that are known 
to be flawed.  ROT13 may be "good enough", but nobody would seriously 
consider it to be a credible encryption or hashing mechanism!

More to the point: MD5 seems to be "good enough" as a hashing mechanism 
now, but there is enough evidence of its flaws that no new software should 
be written to use it and we need to think about replacing MD5 in existing 
software that uses it.

I'm sure that SHA1 won't be a wise choice, or even "good enough", forever. 
This is clearly a moving target.  The point is to choose the best you can 
now, because what's "good enough" now will be completely unsafe in the 
future.

> In summary, it looks like I had some trouble understanding the draft.

I find this feedback to be useful.  The document was put together in a 
very ad hoc manner, and the underlying protocol was redesigned at least 
three times.  So it's amazing that the document is coherant at all.

Nevertheless, anything that clarifies it is probably a good idea, 
especially when someone comes from an external environment and is trying 
to figure out what the document is talking about.

-- Mark --