Last Call Review of draft-ietf-mediactrl-architecture-
review-ietf-mediactrl-architecture-secdir-lc-kelly-2009-02-19-00

I have reviewed this document as part of the security directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


 These comments were written primarily for the benefit of the security 


area directors.  Document editors and WG chairs should treat these 


comments just like any other last call comments.






This is an architecture document describing a framework for media server 


control which combines elements from several related working groups and 


protocols. The framework described in this document consists of 3 


elements: the application server, the media server, and the user agent. 


The document focuses on the interactions between the application server 


and the media server, and declares the user agent interactions to be out 


of scope.






The security considerations section says that media servers use the 


security mechanisms of SIP to authenticate requests from application 


servers, and to ensure the integrity of those requests, and says that 


this ensures that only authorized application servers may access the 


media server and impact its resources.






I have two concerns: first, the current security considerations section 


focuses on the media server and how to protect against malicious 


application servers (or AS impersonators) -- it should also address the 


flip side of this, i.e. what happens if someone impersonates the media 


server, and what, if anything, should be done? If this is addressed in 


some other related document, then perhaps a pointer to that other 


document would be helpful.






My other concern is a bit more nebulous: this work seems to cut across 


multiple other efforts (more than I have time to seriously review right 


now), and while I think it makes sense to reference the security 


considerations of other documents when they adequately address the 


problems at hand, I think the wg (and security ADs) will want to be sure 


that the particular threats of this framework are explicitly called out 


and completely addressed. This architecture document may or may not be 


the right place to do that.




--Scott