Subject: Re: [secdir] secdir review

From: Dave Burke <[email-masked]>
Date: Tue, 27 Jan 2009 15:54:21 +0000

Thanks for the feedback Stephen. Comments below. If you agree, I'll prepare
an updated draft.

Dave

On Mon, Jan 19, 2009 at 10:18 PM, Stephen Kent <[email-masked]> wrote:
> 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.

We will include additional discussion of security considerations in the main
text where appropriate for completeness.

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

Will do

>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 requesting endpoint could be as person for very simple networks though
it will be a server in the more usual case. We will generalize the method of
authentication to any SIP standard approach rather than mandate one
particular flavor.

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

Agree with the language issue (that we're talking about mechanisms to
enforce policies). This paragraph is really attempting to address security
within the VoiceXML language which, in retrospect, makes it clearly out of
place in this document (it is actually a W3C consideration). For this
reason, we'll drop the paragraph.

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

Will fix the language issue and will also change the recommendation to only
include well-specified behaviour (i.e. SIP authentication).
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Jan 2009 18:04:34 -0500

Dave,

I think the changes you propose are reasonable.

Steve