Skip to main content

Last Call Review of draft-ietf-mediactrl-architecture-

Request Review of draft-ietf-mediactrl-architecture
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-01-27
Requested 2009-01-13
Authors Tim J. Melanchuk
I-D last updated 2009-02-19
Completed reviews Secdir Last Call review of -?? by Scott G. Kelly
Assignment Reviewer Scott G. Kelly
State Completed
Request Last Call review on draft-ietf-mediactrl-architecture by Security Area Directorate Assigned
Completed 2009-02-19
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.