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:
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ lemonade mailing list lemonade at ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade