Subject: [secdir] secdir review

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Jan 2009 17:18:05 -0500

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 document describes a SIP interface to VoiceXML media services 
and is an adjunct to the (full) MEDIACTRL protocol. The interface 
leverages a mechanism defined in RFC 4240, updating and extending it 
to match current VoiceXML specs from the W3C.

The security considerations section of this document is very brief, 
i.e., about half a page. The security-relevant requirements cited in 
this section appear to be defined only here, not in the body of the 
spec. This seems a bit unusual,  i.e., this section often is used to 
summarize security-relevant requirements that have been explicitly 
discussed previously in a document. More importantly, since the 
security requirements cited here appear nowhere else in this 
document, it is critical that the description provided here be 
sufficient for implementers to develop complaint products.  Of the 
five security requirements (MUST or RECOMMENDED) cited here, only 
three meet this criteria.

The first paragraph notes that offering network services via 
well-known ports may enable exploitation (of something) by 
adversaries, a pretty generic and vague statement. It then notes that 
an application server implementing this protocol MUST support digest 
authentication "of requesting endpoints." At a minimum there ought to 
be a cite to the relevant RFC (2617) here. Since the requesting 
endpoint in this context appears to be another server (vs. a person) 
it is not clear that a password-based authentication mechanism is the 
preferred choice here. Support for :https is mandated later, in a 
different context, so it is not clear why support for that form of 
authentication (preferably bi-directionally) is not required here as 
well.

The second paragraph of this section notes that the transfer 
mechanism defined for this protocol could enable various types of 
attacks, by causing an application server to make outbound calls. 
Such calls consume resources (a DoS attack vector), may cost money 
(fraud), and might interfere with the ability of the calls to be 
traced (unintentional anonymity?). The document RECCOMMENDs that 
VoiceXML servers provide "local policies" to authorize and limit such 
calls, and audit trails to help resolve billing issues and provide 
traceability. This is not an appropriate recommendation for two 
reasons. First, this RFC is specifying what vendors of application 
servers are supposed to implement. Vendors can provide "mechanisms" 
that enforce local policies, but they are not creators of policies 
per se. So, the requirement is for mechanisms not policies. Second, 
this is a very vague recommendation; if is not clear how one would 
determine whether a set of mechanisms offered by a vendor satisfied 
the recommendation.

To address confidentiality of data transferred to/from these servers, 
support for :sips and https: is mandated, which seems appropriate. 
SRTP also MUST be supported to provide various security services for 
media streams, another appropriate and well-specified requirement.

The sections ends with another RECOMMENDATION described in terms of 
the need to support "local policies" that would help minimize DoS 
attacks launched from an application server.  Here too the document 
should be stating the need for "mechanisms" that can be used to 
enforce local policies, as noted above. And, as above, the 
description is vague, giving just one example, to be used in 
evaluating whether a given product satisfies the recommendation.

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir