Subject: [lemonade] Security Considerations Pawn Ticket URLs

From: Neil Cook <[email-masked]>
Date: Tue, 23 Sep 2008 22:08:05 +0000

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?

Thoughts 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: Dave Cridland <[email-masked]>
Date: Tue, 23 Sep 2008 23:47:25 +0100

On Tue Sep 23 23:08:05 2008, Neil Cook wrote:
> 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.
> 
> 
Hmmm....

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

It's reasonable to assume a submission server and message store are  
in the same administrative domain. It's less reasonable to assume a  
streaming server also is, I think - my gut feel is that a streaming  
server could belong to a network operator, say.

It's entirely possible for the document to say "Use anonymous unless  
it's within the same administrative domain", but then you need to  
have the client know which administrative domains have trust  
agreements. This problem exists in the BURL/URLAUTH interaction now,  
but it'd be much hairier in a situation where cross-domain URLAUTH  
were commonplace.

> prefix to the IMAP URI protocol

In terms of implementation or specification, I don't think it's much.

> . Can I add it as part of my streaming  doc?

Yes.

>  If so, does that change it from informational status?

Yes, it becomes Standards Track, I suspect.

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: Neil Cook <[email-masked]>
Date: Wed, 24 Sep 2008 12:16:19 +0000

Dave,

comments inline:

Neil

> but it'd be much hairier in a situation where cross-domain URLAUTH  

I'm also adding media server discovery back into the document (based  
on the -14 METADATA draft). This would provide a suitable mechanism  
for discovering media servers in the same administrative domain  
(either implicitly (i.e. if the IMAP server lists media servers they  
are implicitly authorised to stream media) or explicitly (it lists  
both authorized and non-authorized media servers and distinguishes  
between them)).

> Yes, it becomes Standards Track, I suspect.

I'd be interested in Eric's opinion on this.

Neil

---

From: Ted Hardie <[email-masked]>
Date: Wed, 24 Sep 2008 10:57:16 -0700

Howdy,
	After reading through the discussion to date, my biggest
take away is that we'd really need to see a draft or diffs to the existing
draft before making this change.  This statement, for example:

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

seems to imply a set of trust relationships and model that I can't
quite tease out in my head. 
	Have pity on the old and feeble-brained like me, 
and proppose (or have the relevant AD propose) text?

			thanks,
				Ted

---

From: Neil Cook <[email-masked]>
Date: Wed, 24 Sep 2008 18:18:19 +0000

Ted,

I'll issue a new draft by the end of the week, and I'll also send a  
diff of the changes to the list. I'll make sure I include a discussion  
of the security implications of the attack referenced below.

Neil