Subject: [lemonade] "submit+" versus "stream+"

From: Eric Burger <[email-masked]>
Date: Wed, 1 Oct 2008 14:29:57 -0400

Below is a thread discussing the relative merits of considering the  
semantics of "submit+" URLAUTH use. The key positions:

POSITION 1: "submit+" really means "the client gets a pawn ticket for  
an object for the client to give to someone else".

POSITION 2: "submit+" means "the client gets a pawn ticket for the  
purposes of fetching for submission", which means that for streaming,  
we will need a "streaming+", which means "the client gets a pawn  
ticket for the purposes of fetching for streaming", and when someone  
comes up with another reason for getting a pawn ticket for passing to  
someone else, someone will have to create a new "mumble+" prefix for  
URLAUTH.

Pro's of POSITION 2:
The client is somewhat explicit on why it is requesting a URLAUTH  
token, and when the third party accesses the IMAP store, the IMAP  
store (which generated the ticket) can do separate ACL processing or  
logging based on the purpose of the URLAUTH token (e.g., submit versus  
streaming versus mumble).

There was some discussion that an IMAP server might restrict the kinds  
of MIME types it would release to a streaming server versus a submit  
server. However, in practice it is clear there is no distinction.  
Other than filtering viruses, a streaming server actually can stream  
most any type. For example, an open office document could be spoken as  
text-to-speech and an image could be rendered as a streaming video to  
a video phone.

Pro's of POSITION 1:
The client does not need to consider why it is grabbing a URLAUTH  
token; it just grabs one. This is not an issue today with POSITION 2:  
a client that is composing a message knows to request a submit+ token  
and a client that wants streaming will request a stream+ token. The  
problem comes in when a new application wants to have access to an  
IMAP body part that is neither for submit processing nor streaming.  
The likelihood of the application developers going through the process  
of writing an RFC to register a new mumble+ token and then getting the  
entire IMAP Server community to adopt it is virtually zero. Moreover,  
while POSITION 1 offers the ability for the IMAP server to do  
something "special" for submit+ versus stream+, it is not clear the  
IMAP server will (or can) do anything different in practice. In  
addition, there is no protocol mechanism to prevent an application  
from using submit+ for another purpose. Thus in practice there is no  
distinction between submit+ versus stream+, which means wasted,  
duplicated code that does no useful work.

To be clear: What we are talking about here is expanding the semantic  
of "submit+" to mean "request from a thrid-party client on behalf of  
the client."

<With Chair hat off>
I'm against writing code that never gets used.

<With Chair hat on>
RFC 4467 is done. Using something other than "submit+" for streaming  
means a much longer cycle on getting streaming done. If there is no  
difference in protocol, scale, or security, our preference as Chairs  
is to take the path of least resistance.

PLEASE REGISTER YOUR CHOICE OR AMBIVALENCE SOON

Note: given the text currently says "submit+", what we are looking for  
here is one of:
[ ] I like "submit+" means "third-party request"
[ ] I like the idea of "submit+" meaning "third-party request", but I  
am not comfortable with the token being called "submit"
[ ] I don't like the idea of "submit+" meaning "third-party request",  
but I can live with it
[ ] I just realized the reason why "submit+" meaning "third-party  
request" will damage the Internet
[ ] Here is the reason "stream+" is the only way to go

On Sep 25, 2008, at 8:40 AM, Neil Cook wrote:

> Eric,
>
> I'm not sure I agree with the specifics of some of your arguments,  
> but I do agree with your conclusions - see below.
>
> Neil
>
> On 24 Sep 2008, at 23:55, Eric Burger wrote:
>
>> What we are talking about here is not "Who may fetch parts for the  
>> purposes of submission?" versus "Who may fetch parts for the  
>> purposes of streaming?", but rather "Who may fetch parts?" From the  
>> perspective of the IMAP Server, the protocol interaction, and  
>> physics, these three questions are identical and collapse down to  
>> "Who may fetch parts?" As far as the IMAP server is concerned, some  
>> third-party server connects to the IMAP Server and asks for a bunch  
>> of bytes. Since there IS NO PROGRAMATIC WAY to prevent a Submit  
>> Server from streaming the fetched IMAP part or to PREVENT a  
>> Streaming (Media) Server from submitting the data, there is no  
>> sensible distinction between the two.
>>
>
> This is not absolutely true. The submit+ prefix means that the URL  
> can only be retrieved by  those entities that, when logged in to the  
> IMAP server have a "submit+" authorization level. Similarly the  
> stream+ prefix means that the URL can only be retrieved by those  
> entities that have a "stream+" authorization level.
>
> So this absolutely *does* programmatically prevent a submit server  
> from retrieving the content specified by a URL that contains the  
> stream+ prefix. It could fetch content specified with a URL that  
> contains the submit+ prefix, and choose to stream that it if wished.  
> Similarly a streaming media server would not have the "submit" role  
> on the IMAP server.
>
> But the point you are making is that once the content has been  
> fetched, there is nothing preventing the retriever of that content  
> from doing whatever they like with it, which is a fair point.
>
>> If I am an evil Media Server, and you request me to fetch  
>> something, then I can steal your content because you asked me to  
>> fetch something. I don't see how specifying the purpose of the  
>> content fetch to be streaming changes anything. Whether I  
>> legitimately stream the data, I stream the data and steal a copy,  
>> or I just steal the copy, is something that I do NOT see a  
>> cryptographic (or naming convention, for that matter) way to fix.
>
> "stream+" (and indeed submit+) does more than specify the purpose of  
> the content fetch. It specifically restricts such fetching to  
> entities that have established a prior trust relationship with the  
> IMAP server for the purposes of fetching data to be streamed. But  
> again I see your point - is there anything fundamentally different  
> about the trust relationship with submit+ servers and stream+  
> servers? Probably not.
>
>>
>> I would offer one of three solutions. The first solution is to just  
>> state, "submit+" means the IMAP server MUST validate the source of  
>> the request. In plain English, the Media Server must be in some ACL  
>> at the IMAP Server. The second solution is to create a "stream+"  
>> prefix, which is a 100% cut-and-paste of "submit", substituting  
>> "message submission entity" with "streaming entity." The third is  
>> to punt entirely and state in the Security Considerations section  
>> that the IMAP Server and the Media Server SHOULD have some trust  
>> relationship, such as an ACL, host certificates, or physical  
>> security, because bad things can happen if you don't.
>>
>> Creating a "stream+" prefix duplicates a bunch of text and  
>> semantics. These semantics have no distinction in the real world.  
>> Thus I welcome $100 bets this duplication of text and semantics,  
>> without any distinction in the real world, will generate errors in  
>> the RFC and interoperability problems in the real world.
>>
>> In short, I offer we mention in the Streaming draft we use the  
>> submit+ mechanism to let the IMAP Server authenticate the Media  
>> Server. We issue an RFC Errata saying when we said "message  
>> submission entity" in RFC 4467, we meant "entity."
>>
>> Some may object, saying "submit+" does not look like "trusted_entity 
>> +". I would offer the following. We are talking about the octet  
>> stream 73 74 72 65 61 6d, which, by sheer coincidence, spells  
>> "submit", but really is just a unique octet stream that means  
>> "trusted entity." Second, RFC 4467 is done and does not need any  
>> changes to make a Media Server, or other trusted third-party- 
>> trusted server, work.
>
> The main reasons I can see for distinguishing betweeen "submit+" and  
> "stream+" are administrative in nature, such as IMAP server  
> administrators being able to track the statistics for URLs retrieved  
> for streaming purposes separately from those retrieved for submit  
> purposes.
>
> In short however, I think administrative benefits are probably not  
> worth the effort of adding "stream+", so I agree with the proposal  
> to use submit+, and to modify the semantics of that prefix to mean  
> "trusted entity". This also solves the problem more generically, as  
> I'm sure there will be further uses of IMAP URLs in the future that  
> require a way to indicate that access should be restricted to  
> trusted entities.
>
> Actually, I just had an idea - the submit+ syntax specifies that a  
> username follows it, even though that username is ignored by the  
> IMAP server. I could simply recommend that clients use the username  
> "stream", as a hint for admins.
>
> Neil
>
>>
>> Thoughts?
>>
>>
>> --
>> - Eric
>>
>>
>> On Sep 24, 2008, at 10:00 AM, Neil Cook wrote:
>>
>>> Arnt,
>>>
>>> Access to the media server is via SIP, which already has has  
>>> mechanisms to restrict access to authorized users, such as by  
>>> requesting authentication. For example, media servers might allow  
>>> unauthenticated access from clients in the same administrative  
>>> domain, but request credentials (or deny access) from clients in a  
>>> different administrative domain.
>>>
>>> In my opinion, the above mechanisms (policies for which would be  
>>> in place regardless of streaming) would be enough to make such  
>>> attacks as you describe below extremely difficult/unlikely. Media  
>>> servers are extremely unlikely to allow access to the resources  
>>> from any old network, and if they did, they probably wouldn't  
>>> qualify to be included in the list of trusted servers. However, I  
>>> think the possibility of this type of attack should be mentioned  
>>> in the Security Considerations section.
>>>
>>> Neil
>>>
>>> On 24 Sep 2008, at 13:35, Arnt Gulbrandsen wrote:
>>>
>>>> Neil Cook writes:
>>>>> The concern is about trust in the media server, i.e. that the  
>>>>> client  is passing a URI to a media server that may or may not  
>>>>> be trusted to  do the right thing with the content. What this  
>>>>> proposes is a way to  restrict the URL from being used by media  
>>>>> servers that are not trusted  by the IMAP server.
>>>>
>>>> An untrusted malevolent media server can use the data if it can  
>>>> guess the name of an a trusted media server.
>>>>
>>>> An innocent end user requests stream from an untrusted media  
>>>> server, which turns around, guesses a trusted server, connects to  
>>>> it, forwards the request and the stream and does something evil  
>>>> while forwarding.
>>>>
>>>> This attack breaks down if either a) media servers tend to be  
>>>> secure against MITM attacks or b) guessing the name of the  
>>>> trusted media server is really difficult.
>>>>
>>>> I guess I'm for or against the change depending on whether this  
>>>> attack works or not.
>>>>
>>>> Arnt
>>>
>>
>

_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Oct 2008 10:41:06 +0100

> an object for the client to give to someone else".

I think this is a bit too generic (as it covers all other URLAUTH 
prefixes). I think you meant "the client gets a pawn ticket for  an 
object for the client to give to another service, that has to 
authenticate to retrieve the content".

> logging based on the purpose of the URLAUTH token (e.g., submit 
> versus  streaming versus mumble).
>
> There was some discussion that an IMAP server might restrict the 
> kinds  of MIME types it would release to a streaming server versus a 
> submit  server. However, in practice it is clear there is no 
> distinction.  Other than filtering viruses, a streaming server 
> actually can stream  most any type. For example, an open office 
> document could be spoken as  text-to-speech and an image could be 
> rendered as a streaming video to  a video phone.
>
> Pro's of POSITION 1:
> The likelihood of the application developers going through the 
> process  of writing an RFC to register a new mumble+ token and then 
> getting the  entire IMAP Server community to adopt it is virtually zero.

As a side note: while the last sentence is certainly true, there are 
some other cases when the client can easily decide on URLAUTH type it 
wants to use.
For example a client that wants to store a private bookmark, will always 
use "user+". If the client wants to store a public bookmark, it can use 
"anonymous" or "authuser".

> Moreover,  while POSITION 1 offers the ability for the IMAP server to 
> do  something "special" for submit+ versus stream+, it is not clear 
> the  IMAP server will (or can)

An IMAP server certainly can. It might be used by a specialized application.
We certainly can't control "will", but "can" is the most important part 
here.

> do anything different in practice. In  addition, there is no protocol 
> mechanism to prevent an application  from using submit+ for another 
> purpose. Thus in practice there is no  distinction between submit+ 
> versus stream+, which means wasted,  duplicated code that does no 
> useful work.
>

So much for a neutral description of the 2 choices ;-).

> means a much longer cycle on getting streaming done.

Are you sure?

> If there is no  difference in protocol, scale, or security, our 
> preference as Chairs  is to take the path of least resistance.
>
> Note: given the text currently says "submit+", what we are looking 
> for  here is one of:

I am somewhere between the last 2.

As a server developer I can tell you that adding stream+ is not going to 
be difficult, at least in the case of our server.
M-Box is using a special group "submit" for verifying who is allowed to 
use submit+ URLs. We do support multiple groups, so defining a new one 
is easy.

---

From: Eric Burger <[email-masked]>
Date: Mon, 13 Oct 2008 08:22:10 -0400

Any other opinions out there?

Anyone else care?

Hello... Hello... anyone out there?!?!?

On Oct 11, 2008, at 5:41 AM, Alexey Melnikov wrote:

> Eric Burger wrote:
>
>> Below is a thread discussing the relative merits of considering  
>> the  semantics of "submit+" URLAUTH use. The key positions:
>>
>> POSITION 1: "submit+" really means "the client gets a pawn ticket  
>> for  an object for the client to give to someone else".
>
>> purposes of fetching for submission", which means that for  
>> streaming,  we will need a "streaming+", which means "the client  
>> gets a pawn  ticket for the purposes of fetching for streaming",  
>> and when someone  comes up with another reason for getting a pawn  
>> ticket for passing to  someone else, someone will have to create a  
>> new "mumble+" prefix for  URLAUTH.
>>
>> Pro's of POSITION 2:
>> store (which generated the ticket) can do separate ACL processing  
>> or  logging based on the purpose of the URLAUTH token (e.g., submit  
>> kinds  of MIME types it would release to a streaming server versus  
>> a submit  server. However, in practice it is clear there is no  
>> token; it just grabs one. This is not an issue today with POSITION  
>> 2:  a client that is composing a message knows to request a submit+  
>> token  and a client that wants streaming will request a stream+  
>> token. The  problem comes in when a new application wants to have  
>> access to an  IMAP body part that is neither for submit processing  
>> nor streaming.  The likelihood of the application developers going  
>> through the process  of writing an RFC to register a new mumble+  
>> token and then getting the  entire IMAP Server community to adopt  
>> it is virtually zero.
>
> some other cases when the client can easily decide on URLAUTH type  
> it wants to use.
> For example a client that wants to store a private bookmark, will  
> always use "user+". If the client wants to store a public bookmark,  
> it can use "anonymous" or "authuser".
>
>> Moreover,  while POSITION 1 offers the ability for the IMAP server  
>> to do  something "special" for submit+ versus stream+, it is not  
>> clear the  IMAP server will (or can)
>
> We certainly can't control "will", but "can" is the most important  
> part here.
>
>> do anything different in practice. In  addition, there is no  
>> protocol mechanism to prevent an application  from using submit+  
>> for another purpose. Thus in practice there is no  distinction  
>> between submit+ versus stream+, which means wasted,  duplicated  
>> code that does no useful work.
>>
>> To be clear: What we are talking about here is expanding the  
>> semantic  of "submit+" to mean "request from a thrid-party client  
>> on behalf of  the client."
>>
>> <With Chair hat off>
>> RFC 4467 is done. Using something other than "submit+" for  
>> streaming  means a much longer cycle on getting streaming done.
>
> Are you sure?
>
>> [ ] I like the idea of "submit+" meaning "third-party request", but  
>> I  am not comfortable with the token being called "submit"
>> [ ] I don't like the idea of "submit+" meaning "third-party  
>> request",  but I can live with it
>
> As a server developer I can tell you that adding stream+ is not  
> going to be difficult, at least in the case of our server.
> M-Box is using a special group "submit" for verifying who is allowed  
> to use submit+ URLs. We do support multiple groups, so defining a  
> new one is easy.
>

---

From: Dave Cridland <[email-masked]>
Date: Mon, 13 Oct 2008 13:53:35 +0100

On Wed Oct  1 19:29:57 2008, Eric Burger wrote:
> streaming  means a much longer cycle on getting streaming done. If  
> there is no  difference in protocol, scale, or security, our  

Two things, from which you can derive a tickbox opinion.

First, RFC 4467 is indeed done, and specifies what submit+ means:

   The "submit+" access identifier prefix, followed by a userid,
   indicates that only a userid authorized as a message submission
   entity on behalf of the specified userid is permitted to use this
   URL.  The IMAP server does not validate the specified userid but  
does
   validate that the IMAP session has an authorization identity that  
is
   authorized as a message submission entity.  The authorized message
   submission entity MUST validate the userid prior to contacting the
   IMAP server.

So by saying "Hey, and you can use it for streaming servers too",  
then you are changing this meaning, which, I think, technically  
requires this streaming RFC to Update RFC 4467, which in turn  
requires it to go Standards Track, etc. So reusing submit+ is not a  
standardization shortcut, and using that as an argument is therefore  
counter-productive, as it may very well be the opposite.

Secondly, it may be worthwhile asking what the point of submit+ is.  
As I understand it, submit+ is there to limit the effective scope of  
the damage caused by the leak of such a URL. It's not to limit the  
scope of where it's used legitimately, because all legitimate usage  
is, by definition, okay.

But if a URI is leaked, the intention here is to make it more  
difficult for an attacker. So, if an attacker gets hold of a submit+  
URI, said attacker must also have a compromised trusted submission  
server. By extending the scope of submit+ to include other trusted  
servers, the attack surface is increased, and therefore the protocol  
as a whole is weakened.

Hence, reusing the submit+ prefix in other circumstances appears to  
me to be a marginal simplification for IMAP client and server  
implementors, at the expense of security, which is an argument I find  
very difficult to justify.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Oct 2008 03:59:32 -0700

> very difficult to justify.

I consider this to be a compelling argument.

_________________________________________________________________
Stay up to date on your PC, the Web, and your mobile phone with Windows Live.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Eric Burger <[email-masked]>
Date: Wed, 15 Oct 2008 20:27:43 -0400

I would consider it to be compelling, if one could argue how submit+  
is different from stream+ in practice.

If people will provision IMAP servers with separate ACL's, I would buy  
it. However, I don't see it in practice.

This one is certainly in "it's the will of the work group."

<chair hat on>
So far, it's 3 votes for submit+ only, and 4 for submit+ and stream+.  
In my book the 4 votes for having bunches of ACL's counts more heavily  
than the 3 votes, because my vote does not count as I'm not an  
implementor.

Do be aware that if we do stream+, we would do a stand-alone document  
for stream+ (standards track)  and a separate document for how to use  
it in the context of streaming voice and video (informational). A  
separate issue is whether we would need to recharter. I do not think  
we do, as to me stream+ would be an IMAP (URLAUTH) extension in  
support of handling streaming multimedia content, which is deliverable  
#1.

I would offer if we go the route of multiple prefixes that we spend  
time thinking about whether submit+ and stream+ will be the only  
prefixes. To me, this mechanism is opening the door for lots and lots  
of access "reasons", in which case we should set up an IANA registry  
for future prefixes (reason codes).

On Oct 14, 2008, at 6:59 AM, Mark Crispin wrote:
> Quoting Dave Cridland:

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 16 Oct 2008 09:55:14 +0200

> So far, it's 3 votes for submit+ only, and 4 for submit+ and stream+.

Uh. Dave's missive the other day changed my mind.

Arnt