[secdir] review of draft-ietf-mediactrl-architecture-04

["Scott G. Kelly" <[e-mail]>]

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