Re: [secdir] Secdir review of draft-ietf-mmusic-sdp-miscellaneous-caps-05

[<[e-mail]>]

Hello Catherine,

Thank you for the comments, please see my answers below prefixed with [SV].

From: ext Catherine Meadows [mailto:[e-mail]]
Sent: 30. toukokuuta 2013 23:58
To: [e-mail]; [e-mail]; [e-mail]
Cc: Catherine Meadows
Subject: Secdir review of draft-ietf-mmusic-sdp-miscellaneous-caps-05

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 ID defines three new capabilities that can be negotiated in the Session Description Protocols (SDP) using the SDP offer/answer
procedure.  These are bandwidth capability (proposed bandwidth to be used by session or media), connection capability (network type, address
type, and address), and title capability (human-readable textual information about the session).

None of these are directly security-related, although the authors point out that an attacker who
is able to modify traffic could modify the bandwidth value so that then network winds up being under-utilized
or over-utilized.  They recommend using on of the security mechanisms recommended in RFC5939 (which defines SDP capability negotiation
in general) in case
it is necessary to protect the bandwidth value.

I think this is a very appropriate recommendation for this ID, but perhaps the authors should consider offering similar recommendations
for the other capabilities.  For example, in the connection capability it is possible to offer an address together with a number of alternatives.
What happens if an attacker removes some or most of the addresses?  Could this lead to overuse of the remaining addresses?  Likewise, one of the reasons the human-readable
title capability is provided is so that a human can make choices about which media configurations to choose.  If the attacker tampers with a label so that the human is caused to make wrong choices, this could again
cause problems.  I think it could be worthwhile to point out that there may be cases for both connection and title capabilities where adversarial tampering could have harmful effects,
and if this is the case the security mechanisms in RFC5939 should be applied as well.

[SV] I agree that just addressing the possible misuse of the bandwidth capability might give an impression that there are no foreseen threats with the two other capabilities. For the connection address capability ("ccap") attribute, the most harmful threat would actually that the attacker tricks the endpoint to send media to an unaware destination. This type of DoS attack in the context of voice over IP (called the "voice hammer") is discussed in RFC5245.

[SV] I have modified the relevant paragraphs and added new text to read:

                The bandwidth capability attribute may be used for reserving
                resources at endpoints and intermediaries which inspect the
                SDP. Modification of the bandwidth value by an attacker can
                lead to the network being underutilized (too high bandwidth
                value) or congested (too low bandwidth value).

                Similarly, by modifying the alternative connection
                address(es), an attacker would be able direct media streams to
                a desired endpoint, thus launching a version of the well known
                voice hammer attack (see Section 18.5.1 of [RFC5245]).

                The title capability provides for alternative "i=" line
                information, which is intended for human consumption. However,
                manipulating the textual information could be misused to
                provide false information, leading to bad user experience or
                the person using the service making wrong the choice
                regarding the available media streams.

                In case it is essential to protect the capability attribute
                values, one of the security mechanisms proposed in [RFC5939]
               SHOULD be used.

Regards,
Simo


Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: [phone]
fax: [phone]
email: [e-mail]<mailto:[e-mail]>