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 URIOption 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:
Eric Burger writes: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!)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 streamingArnt
_______________________________________________ lemonade mailing list lemonade at ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade