Subject: Re: [lemonade] Security Considerations Pawn Ticket URLs

From: Eric Burger <[email-masked]>
Date: Wed, 24 Sep 2008 06:52:00 -0400

Sigh.
Part of me says, "Get it done."
Another part of me says, "Internet protocol; cannot assume all in same  
administrative domain."
Reality is, "Informational document."
Thus, "Get it done" side of my brain wins. Go for stream+.

(Just my vote - if anyone feels strongly otherwise, please speak up  
now!)

On Sep 23, 2008, at 1:26 PM, Neil Cook wrote:

> All,
>
> I'm updating the streaming draft based on feedback from the AD, and  
> I'd like to solicit some feedback from the WG on a proposal that he  
> made. Basically he felt that the security considerations of the doc  
> were a bit weak, particularly around the use of pawn ticket URLs.
>
> Now up to this point I've been using the mechanisms already inherent  
> in the existing IMAP URI RFC, however Chris proposed a new IMAP URI  
> identifier prefix of "stream+", (similar to the existing stream+  
> prefix). This would provide additional security as it would allow  
> clients to be sure that only media servers that are authorized as  
> "streaming entities" would be allowed to access pawn-ticket URLs  
> generated for streaming.
>
> I like this idea. My main reservations are around:
>
> 1) Would this prevent widespread adoption of streaming as it would  
> effectively require media servers to be "paired" with IMAP servers  
> in advance. This would imply that the media server and IMAP server  
> must be under the same administrative domain/control. My personal  
> feeling is that this is how it would happen 99% of the time anyway,  
> and that the extra security can only help.
> 2) I don't have an idea of how much extra work it is to add a new  
> prefix to the IMAP URI protocol. Can I add it as part of my  
> streaming doc? If so, does that change it from informational status?
>
> Thought would be appreciated.
>
> thanks,
>
> Neil

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 24 Sep 2008 13:15:55 +0200

> (Just my vote - if anyone feels strongly otherwise, please speak up

I didn't quite understand what the proposal is.

If I understand it: The proposal is to add a new knob to IMAP URIs which 
an entity (which? an IMAP server or client?) can add (where?). Access 
to the URI is then granted only to entities that are known to be 
streaming servers.

I don't see how this helps security. If I'm an attacker and have such a 
URI, then (AFAICT) I can obtain the data by connecting to the streaming

Arnt

---

From: Neil Cook <[email-masked]>
Date: Wed, 24 Sep 2008 12:45:49 +0000

Arnt,

so the proposal is that if clients know the details of a media server  
that is authorized for streaming, then the client adds the stream+  
prefix as part of the IMAP URI generation process. This prevents media  
servers which are not authorized to retrieve streaming content from  
the IMAP server in question from accessing the data.

You're right - this doesn't stop an attacker who has the URI from  
using a suitable media server to get the streaming content. However  
the existing encryption mechanisms in both protocols should prevent  
third-parties from accessing the URI created. (There is a caveat with  
the NETANN service and proxies, but that is already mentioned in the  
security considerations, and the fix is to use the IVR service).

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.

So I think we have two scenarios, with three possible outcomes.

Scenario 1)

Client has used the discovery process in the new draft (which allows  
for the IMAP server to return a list of media servers, including which  
ones are trusted), or has used some out of band mechanism such as pre- 
configuration of the device, and has one or more "trusted" media  
servers that can be used. It thus generates a URI using the "stream+"  
prefix, ensuring that only media servers that are trusted by the IMAP  
server can make use of it.

It makes no sense for the client to generate an anonymous URI in this  
case, thus I think this should be a MUST.

Scenario 2)

Client has a list of media servers, but it has no idea if they are  
trusted or not. There are two options:

i) it can generate a URI using the stream+ prefix
ii) it can generate an anonymous URI

Option i) means that only media servers trusted by the IMAP server can  
access the content, thus it is more secure, but streaming has a chance  
of failing.
Option ii) means that any media server can access the content, but the  
client has to take a risk that the media server

I think I should make Option i) a SHOULD, as I don't think we should  
stop clients from using anonymous URIs if that is what they really  
want to do.

Neil

On 24 Sep 2008, at 11:15, Arnt Gulbrandsen wrote:

>> Another part of me says, "Internet protocol; cannot assume all in  
>> same administrative domain."
> If I understand it: The proposal is to add a new knob to IMAP URIs  
> which an entity (which? an IMAP server or client?) can add (where?).  
> Access to the URI is then granted only to entities that are known to  
> be streaming servers.
>
> I don't see how this helps security. If I'm an attacker and have  
> such a URI, then (AFAICT) I can obtain the data by connecting to the  
> streaming
>
> Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 24 Sep 2008 15:35:15 +0200

Neil Cook writes:
> 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

---

From: Neil Cook <[email-masked]>
Date: Wed, 24 Sep 2008 14:00:26 +0000

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.
>
> which turns around, guesses a trusted server, connects to it,  
> forwards the request and the stream and does something evil while  
> forwarding.
>
> I guess I'm for or against the change depending on whether this  
> attack works or not.
>
> Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 24 Sep 2008 16:00:48 +0200

Neil Cook writes:
> place regardless of streaming) would be enough to make such attacks 
> as  you describe below extremely difficult/unlikely.

OK, then I'm for the change.

Arnt

---

From: Eric Burger <[email-masked]>
Date: Wed, 24 Sep 2008 19:55:41 -0400

On the one hand, a stream+ mechanism solves the issue of unexpected  
servers somehow guessing or stealing a URLAUTH token and using it to  
access the object on the IMAP server. On the other hand, I would offer  
that we *not* create a new stream+ prefix.

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.

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.

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.

Thoughts?

--
- Eric

On Sep 24, 2008, at 10:00 AM, Neil Cook wrote:

> unauthenticated access from clients in the same administrative  
> domain, but request credentials (or deny access) from clients in a  
> different administrative domain.
>
> as you describe below extremely difficult/unlikely. Media servers  
> are extremely unlikely to allow access to the resources from any old  
> possibility of this type of attack should be mentioned in the  
> Security Considerations section.
>
> Neil
>
>>> 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 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.
>>

---

From: Neil Cook <[email-masked]>
Date: Thu, 25 Sep 2008 12:40:59 +0000

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:

> 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.

> 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.

> 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."
>
> +". 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

>> are extremely unlikely to allow access to the resources from any  
>> old network, and if they did, they probably wouldn't qualify to be

---

From: Eric Burger <[email-masked]>
Date: Thu, 25 Sep 2008 09:11:47 -0600

Sounds good to me.

On Sep 25, 2008, at 6: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
>
> 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.
>
> 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.
>
>> 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.
>
> 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.
>
>>
>> "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  
>> 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."
>>
>> changes to make a Media Server, or other trusted third-party- 
>> trusted server, work.
>
> 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  
> require a way to indicate that access should be restricted to  
> trusted entities.
>
> username follows it, even though that username is ignored by the  
> IMAP server. I could simply recommend that clients use the username  
>>> 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
>>>
>>>>> 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  
>>>> secure against MITM attacks or b) guessing the name of the  
>>>> trusted media server is really difficult.
>>>>