Subject: [secdir] review of draft-ietf-mmusic-sdp-capability-negotiation-09.txt

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Oct 2008 11:20:52 -0400

I have reviewed this I-D 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.

General note: The I-D requires a separate copy editing review; I 
encountered several grammatical errors and several instances where a 
blank line appears in the middle of a paragraph. Also the number of 
lines per page seem to be too large. Finally, given the substantial 
complexity of the offer structuring mechanism defined here, I'd like 
to see more attention paid to proper placement of the word "only" in 
the text.

I have been told that this I-D was initially motivated by the need to 
provide a capability negotiation for MIKEY, when that protocol was a 
leading candidate for SRTP key management. The I-D defines a more 
general negotiation capability for SDP, one that has broader 
applicability, but which still aims to be backward compatible with 
existing SIP implementations. This is motivated by more instances in 
which the basic offer/answer model of SDP is perceived as not 
adequate.

In extending the semantics of this model, this I-D defines ways in 
which an offerer can describe capabilities and potential vs. actual 
configurations, and then the answerer will select a compatible set of 
capabilities or configurations from the offerer. The I-D defines six 
new attributes that allow an offerer to structure an SDP payload to 
convey the desired semantics to the answerer, and procedures that 
allow the answerer to interpret the structured payload. This 
functionality might be achieved more elegantly via the use of the 
multipart MIME construct, but support for that construct is not 
perceived as being ubiquitous. There also is a desire to achieve a 
compact encoding for a potentially large number of alternative offers.

I am a bit surprised that many of the examples in this I-D use inline 
keying for SRTP as a major motivator. I thought there was a decision 
in RAI to encourage use of DTLS-based key exchange for SRTP, which 
makes this sort of example less relevant.  Moreover, inline 
transmission of a plaintext key is not something the security areas 
wants to encourage, so use of this means of key transport in examples 
also sends a questionable message. (Yes, I know this is consistent 
with RFC 4568, but that RFC is over 2 years old.) There are other 
examples that use MIKEY as the key management mechanism, which also 
seems a bit odd, if MIKEY has been deprecated now.

The I-D notes (in Section 3.5.1) that there can be complex 
interactions between session level attributes and (subordinate) 
combinations of media-stream attributes, which could result in 
unanticipated results. The authors observe that this potential 
problem (which was already present in SDP but which may be 
exacerbated by this extended functionality) rarely occurs in 
practice. As a security guy, this is a worrisome observation.

The inclusion of a MIKEY-specific discussion in Sections 4.2 and 4.3 
are a concern, for the reasons already stated above, i.e., I thought 
that MIKEY has been superceded by DTLS-based key exchange.

The security considerations section is about 2 pages long. It begins 
by incorporating (by reference) the security considerations for SIP 
and SDP, but does not provide cites for RFCs that contain the 
discussions of these security considerations. I think such cites 
should be inserted here. The authors correctly note that SDP 
capability negotiation introduces new security considerations and 
they try to address those in subsequent paragraphs.

The primary observation here is that if an offerer indicates a 
willingness to create either secure or insecure (or more or less 
secure) media streams, then attacks that violate the integrity of the 
SDP traffic can undermine the security of the media stream. The 
recommended solution is to make use of one of the integrity 
mechanisms that have defined for either end-to-end or hop-by-hop SIP 
security. The I-D recommends use of the security approach in RFC 
4474, arguing that this mechanism does not require a PKI. This 
characterization is not correct; 4474 calls for a PKI that issues 
certificates to domains, rather than to end users, but it still 
assumes the existence of a PKI.

The I-D also argues that the 4474 approach is more secure than 
hop-by-hop use of TLS or IPsec (IPsec is misspelled in the I-D). 
However, if the typical path for a call traverses just two proxies 
(Alice's home domain, outbound proxy and Bob's  home domain inbound 
proxy) this assertion also seems questionable, for several reasons. 
The 4474 approach provides authentication form the home domain SIP 
proxy to subsequent proxies. (Nominally this  authentication extends 
to the callee, but it seems unlikely that an end user will be 
prepared to validate certificates in s system that works hard to 
minimize the need for a PKI that encompasses end users in the first 
place.) More to the point, the 4474 mechanism provides assurance with 
regard to the identity of the caller, and the integrity of some SIP 
header fields. It does not appear to provide integrity for the SDP 
payload, so it does not counter attacks against the integrity of the 
SDP. This latter function is what the authors note is needed to 
prevent a MITM from tampering with the SDP capability negotiation, to 
cause non-secure media stream options to be selected inappropriately.

The authors also note the potential for DoS attacks against an 
answerer, based on sending a very large set of offers, using a very 
complex capability negotiation structure. The I-D says that the 
answerer MUST protect itself against such attacks as indicated in 
Section 3.10.  In fact, the correct reference is to section 3.11. 
Moreover, that section merely warns implementers about this problem 
and suggests some heuristics that an answerer could apply when 
processing an offer. Thus it is questionable to have a MUST in the 
security considerations sections that refers to text that offers such 
high level implementation advice. The security considerations section 
ends with a similar requirement

"Still, the answerer MUST ensure that it does not needlessly consume 
large amounts of memory or CPU resources when processing those as 
well as be prepared to handle the case where a large number of 
potential configurations still need to be processed."

I don't know how one would objectively verify that an implementation 
meets this requirement. That will make it hard to progress this 
document later, when folks have to demonstrate that implementations 
meet all the MUSTs.

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