Subject: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-00.txt

From: [email-masked]
Date: Fri, 20 Jun 2003 07:33:46 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Internet Message Access Protocol (IMAP) - URLAUTH 
                          Extension
	Author(s)	: M. Crispin, C. Newman
	Filename	: draft-crispin-imap-urlauth-00.txt
	Pages		: 0
	Date		: 2003-6-19
	
This document describes the URLAUTH extension to the Internet
Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme
(IMAPURL) (RFC 2192).  This extension provides a means by which an
IMAP client can create 'signed' URLs which can be used to access
limited message data on the IMAP server.
An IMAP server which supports this extension indicates this with a
capability name of 'URLAUTH'.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imap-urlauth-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-crispin-imap-urlauth-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-crispin-imap-urlauth-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Mark Crispin <[email-masked]>
Date: Fri, 20 Jun 2003 05:34:22 -0700 (PDT)

Although this document nees a bit more fleshing out (particularly in
security considerations and quality-of-implementation issues), URLAUTH
demonstrates how relatively simple it is to deploy an IMAP URL-based
mechanism for submit-without-download.

Most IMAP server and client implementations already have HMAC-MD5 and
BASE64 routines, as these are needed for SASL.

Since the mailbox private key is returned automatically at SELECT time,
there are no extra RTTs required of the mobile client; it's just another
bit of mailbox metadata.

Another beauty of URLAUTH is that it turns out that there is pent-up need
for a mechanism of this nature for other purposes.

-- 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: [email-masked]
Date: Fri, 20 Jun 2003 11:01:20 -0700

Mark, Chris,
	I've read the draft.  The idea of embedding security
credentials in URIs has been discussed extensively, dating
back to the HTTP working group.  The fundamental problem
goes to how authentication and authorization are intertwined.
In the typical security model, there is first authorization ("You are who
you say you are") then authorization ("you have the rights to
do $FOO").  When you embed authorization credentials in an
identifier, you shift to a security model in which there is no
prior authentication for an authorization.  To put this another
way, anyone who knows the identifier has authorized access
to the resource.
	There are a couple of common responses to this:
creating a separate mechanism for prior authentication and limiting
access to the resource in some other way such that the risk
is appropriate to value of the resource being protected.  It is
also common to attempt to mitigate the risk by protecting the
channels by which the identifier is transmitted so that the
value of "anyone who knows the identifier" remains appropriate
to the situation at hand.
	The most common forms of prior authentication I
have seen are tied to some form of server-based ACL ("only servers presenting
the following credentials are allowed to present these URIs"); the
most common forms of limitations I have seen limit access to
the resource to a single attempt.  The one-shot access limitations have a
number of failure conditions that have no direct relationship to
security, as well as a bad tendency to layer denial of service
on top of an access compromise.
	To take the case of the server-based prior authentication
in more detail, one of the principle risks is that authorized use of 
the external
server can be used to create authenticated use of the target server.  Assuming
that this were to be used in an "IMAP pull" scenario and a submit server,
the "pulling" submit server is almost certain to be accessible to multiple
individuals.  Any such individual who has intercepted the credential-bearing
URI  can piggyback their authorized use of the submit server to create
the authentication needed to allow access to the URI.  To put this another
way, the difference in granularity of authentication creates a security risk.
	Fundamentally, I think your draft needs to be re-written
from a very different security perspective.  I think you either need
to demonstrate that access to these resources is appropriately
made based solely on essentially anonymous authorization or that
you have worked out the mechanisms of the larger security context
so that the granularity of authentication and authorization are
appropriately matched.  I also strongly believe that Mark's comment
below (that there is a pent-up need for this mechanism for other
purposes) needs to be understood within the limitations of this method.
The uses to which anonymous authorization can be put are quite
limited, and it is not clear to me that this use fits the model, much
less that there is a pent up demand for it outside this use.
				regards,
					Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Fri, 20 Jun 2003 15:35:56 -0700 (Pacific Daylight Time)

Ted -

Thank you very much for your well-considered and very helpful comments.
My response is below.

> In the typical security model, there is first authorization ("You are who
                                                ^^^^^^^^^^^^^ authentication?
> way, anyone who knows the identifier has authorized access

This analysis is correct; the mechanism that we propose has authorization
but not authentication.  The specific intent of the design was to provide
authorization to entities which can not (or should not) be authenticated.

To elaborate on the "should not" aspect; the goal was to create a
mechanism to grant access to entities that do not have authentication
credentials on the IMAP server *without* giving those entities the
authentication credentials of the owner of the data.

I thought about this, but decided for the 00 version of the draft not to
address authentication.  If you feel that authentication must be addressed
in this go-around, I think I know how to do that.

Can you give me some additional input; specifically, is it alright to
continue to have an authorization-only form, as long as a form with
authentication is defined?

The authorization-only form, in effect, would mean "anyone including
anonymous can use it".  A form with authentication would restrict access
to a certain IMAP-server authenticated user or users.

I briefly considered a signing form of authentication for the mail submit
case, but rejected this because of excessive complexity and no actual gain
in a submit environment.

> is appropriate to value of the resource being protected.

This prior authentication, in the form with authentication, would be by
means of existing IMAP authentication mechanisms.

> It is

In the case of submit, there is a presumption (which perhaps should be
stated in security considerations) that SSL/TLS-protected channels should
be used to transmit the identifier, along with short-term expiration.

> the resource to a single attempt.

I don't propose doing either of these.  Server-based ACL isn't completely
out of the question, but I think that it's better to give authentication
credentials on the IMAP server to users of the URLs (perhaps limited
solely to use of URLs).  One-shot access limitations seem to me to be a
gad idea.

> Assuming
> the authentication needed to allow access to the URI.

Hence my presumption of the use of SSL/TLS.

Also, it's important to do an appropriate risk assessment.  If the
credential-bearing URI is intercepted, the other components of the message
are also intercepted.  More significantly, the ultimate fate of the
message, *including* the data accessed by the credential-bearing URI, is
likely to be the totally-unprotected SMTP infrastructure.

> I think you either need
> appropriately matched.

I would like to do both, if possible; and would very much appreciate your
assistance in accomplishing this.

We glossed over some important security issues, but were focused on
getting out a 00 draft in time for the IETF cutoff.  Hence the focus was
to create a mechanism that was defensible from a security standpoint even
if the details of that defense were not fully worked out.  I think that
this proposal succeeds in doing so; but you're correct in calling out the
glossings-over.

> I also strongly believe that Mark's comment

Well, there are a couple of needs that come immediately to mind, but both
boil down to a desire for a finer granularity of authorization, both for
anonymous and for non-anonymous access, and to do it in a way that is
revokable and which has an optional expiration.

IMAP itself only offers authorization at the level of authentication
(although authorization is commonly imposed via external means); the ACL
extension to IMAP brings it down to the mailbox level.

> less that there is a pent up demand for it outside this use.

Within an enterprise, one could imagine members sending each other URIs to
the data instead of the data itself.  Right now, the only way to do this
is by forward or resend, which has other implications.

-- Mark --

---

From: [email-masked]
Date: Fri, 20 Jun 2003 16:43:30 -0700

Hi Mark,

Thanks for your response; some comments in line.

>                                                 ^^^^^^^^^^^^^ authentication?

(*blush*).  Yes.  Given the rest of the message, that's an 
embarrassing mistake;
sorry for any confusion.

>...snip...
>>... authentication for an authorization.  To put this another

I think that depends on what the working group decides the use cases
warrant.  And just to be clear, Ned is the Area Advisor for the group
and I was speaking without any hat on at all.  I happen to have been
around for the previous discussions of URIs as credentials, and thought
I should share my experience.  If the language below ("I think you need either
to demonstrate..." etc.) sounded directive, I apologize.  I did not
mean to short circuit the working group's discussion of the topic.
I meant to participate in it.

>to a certain IMAP-server authenticated user or users.

I guess I'm fuzzy on the use case for "anyone including anonymous can use it".
The case I thought we were focused on is "forward without download",
which seems to require that the access to the message being forwarded be
restricted to the user (or her agent) in whose message store the message sits.
(I suppose it might also be seen as access by the user to whom the 
message has been
forwarded, but that's not the viewpoint I think we've started from.)  Can you
elaborate on when the anonymous access would be used?

>means of existing IMAP authentication mechanisms.

If I understand you, then, this authentication would not be the user's
normal IMAP credentials (and I can certainly see why you would not 
want to share those
with the submit server or embed them in a URI).  They would be user
specific, however, and possibly restricted in some other way?  I assume from
the text below that they would not be server-based (since you say 
server-based ACLs
are not the focus of your effort.)  Could a user theoretically present them
through any submit server, then?

>be used to transmit the identifier, along with short-term expiration.

I agree that it should be noted; using TLS does add overhead for both
traffic and credentials that the group should consider.  As you note
below, we also need to be sure in the risk assessment that it
matches the risks in these environments.

>solely to use of URLs).  One-shot access limitations seem to me to be a

In the http-based systems where I've seen it, it has been a bad idea.  There
turn out to be a *lot* of corner cases (just the accept-ranges aspect of it
make it hard to work through).  I've not thought through the IMAP-specific
aspects in any detail, but I suspect there would be similar concerns.

>>  the "pulling" submit server is almost certain ...
>...snip...

I agree that it is appropriate to do a risk assessment.  I'm not sure I
agree about the importance of the use of SMTP for later delivery (as the
protections there may depend on what has been negotiated between specific
hops).  I certainly agree that if an attacker has compromised the IMAP session,
she may well have trapped the credentials which will allow full 
access to the IMAP
store (or may be able to inject requests for access in other ways). 
I would also note,
though, that there are some cases where the attacker  may be listening to
the traffic between the user and the submit server in order to get
access to the data accessed by the credential-bearing URI.

>this proposal succeeds in doing so; but you're correct in calling out the

Sorry if my response seemed an over-reaction to a -00 draft.   The burn
marks from previous attempts at embedding credentials in URIs still
throb occasionally, though, and I wanted to respond quickly.
If that came across as heavy-handed, I apologize.
				regards,
					Ted Hardie

---

From: Randall Gellens <[email-masked]>
Date: Sat, 21 Jun 2003 22:47:13 -0700

>  revokable and which has an optional expiration.

It occurs to me that a mechanism like this could be useful for 
geopriv, where anonymous authorization is needed.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Implementation is the sincerest form of flattery.

---

From: Randall Gellens <[email-masked]>
Date: Sat, 21 Jun 2003 22:53:56 -0700

At 4:43 PM -0700 6/20/03, [email-masked] wrote:

>  there are some cases where the attacker  may be listening to

Presumably if an attacker is able to listen to the traffic between 
the user and the submit server, the attacker has access to all 
non-encrypted messages being submitted.  Since today most email is 
submitted in this way, that would be most email.  The URL-based 
authorization probably is no worse than what we have today (unless it 
allows denial-of-service).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Whenever you find that you are on the side of the majority, it is
time to reform.                                      --Mark Twain

---

From: Mark Crispin <[email-masked]>
Date: Thu, 26 Jun 2003 19:42:39 -0700 (Pacific Daylight Time)

On Fri, 20 Jun 2003 [email-masked] wrote:
> If the language below ("I think you need either

No need to apologize!  I know that I handwaved over certain security
points, and I very much appreciate your help.

> elaborate on when the anonymous access would be used?

OK, there is one obvious limitation in IMAP, and that is that access
control is at the user (and with ACL the mailbox) level.  There is no way
to grant access to a particular message in a mailbox without granting
access to the entire mailbox.

Consider, for example, an archive in which the archive itself is not
public (because there may perhaps be some sensitive information in it) but
individual messages may be.

This has always been a "background" type of issue -- annoying but never
really important enough to come to the forefront.  The attraction is to
kill two birds with one stone -- both "forward without download" and the
"grant anonymous access at the message level".

> normal IMAP credentials (and I can certainly see why you would not want
> to share those with the submit server or embed them in a URI).  They
> would be user specific, however, and possibly restricted in some other
> way?

Well...yes and no.

It is a fairly straightforward extension to URLAUTH to modify it so that
it only gives authorization to a particular authenticated userid.  For
example, "Mark gives Risa a URL to access a message in one of Mark's
private (and protected mailboxes) that only userid Risa can use."

The submit server could have its own submit-server userid.

More complex schemes are possible, but I believe in the KISS principle.

> I assume from

I'm not sure that I understand what you're asking here.  The
authentication would be server based, or at least in the particular
strawman that I'm thinking about.

> matches the risks in these environments.

OK, I'll keep this in mind.  Chris Newman has made a note of this in his
BURL document.

> >One-shot access limitations seem to me to be a
> >bad idea.

Well, since we're loudly agreeing in our dislike of one-shot here, let's
say we won't do one-shot!  :-)

> I certainly agree that if an attacker has compromised the IMAP session,

This is also a weakness of submit-via-IMAP.

> access to the data accessed by the credential-bearing URI.

Hence the implication that TLS protection will be used throughout; and
again, submit-through-IMAP has the same issues and probably the same ("use
TLS") solution.

> If that came across as heavy-handed, I apologize.

Once again, no offense taken.  If I can leverage from your experience, and
avoid making the same mistakes, so much the better.

I'm getting some very clear ideas of what needs to be in the -01.  Thanks!

-- Mark --