Subject: [secdir] SECDIR review of draft-ietf-mmusic-file-transfer-mech-09

From: Richard Barnes <[email-masked]>
Date: Thu, 18 Dec 2008 18:44:39 -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 an SDP syntax for signaling MSRP sessions that 
are to be used *only* for a specific file transfer.  I highlight the 
word "only" because MSRP can already be used for file transfers, but the 
intent of an SDP peer to use a particular MSRP session to transfer a 
file cannot be signaled in SDP.  This document adds syntax to SDP for 
that signaling.

Given the fact that MSRP can already handle file transfers, I was 
expecting this document to address the security trade-offs associated 
with explicitly signaling these transfers.  The current Security 
Considerations section focuses more on the traditional considerations 
around confidentiality and integrity of files transferred over this 
mechanism, without referencing the existing mechanisms in MSRP itself 
(RFC 4975).

Overall, the document is well-written and comprehensible.  However, 
there are a few ambiguities in the main text, and some significant 
repairs that need to be made to the Security Considerations.

SECURITY COMMENTS:

1. The first paragraph of Section 10 is a non-sequitur: Lying about the 
attributes defined in this document has nothing to do with 
integrity-protection.  The file sender can send a bad file that's still 
bit-for-bit perfect as it goes over the wire.  What this section should 
recommend instead is that the file receiver MUST validate all available 
parts of the file-selector attribute (in addition to integrity 
protection).  Similar text should be added to Section 8.2.2 and 8.3.2. 
This validation prevents the file sender from lying about what he's 
sending, and it prevents attackers that can't see the signaling from 
sending bad files to the file receiver.

2. The third paragraph of the Security Considerations (and parts of the 
first two) should be replaced by a reference to RFC 4975, which has a 
much more thorough discussion of integrity and confidentiality for MSRP.

3. There is no discussion of (1) authentication of file receivers or (2) 
authorization of file transfers.  Given that this extension enables the 
"pull" pattern, this discussion is critical.  For example, there's 
nothing in this document to recommend that my UA not blindly return any 
file that another UA asks for.  I would recommend adding some text that 
file transfers MUST be authorized by the file sender's local policy, and 
that this authorization process MAY require that the file receiver be 
authenticated.  The latter requirement will need some discussion of 
authentication, which can primarily be dealt with by referring to RFC 4975.

OTHER COMMENTS:

1. The document discusses in detail when a change of file selector or 
file-transfer-id should trigger a new transmission.  The document also 
seems to assume that a new transmission is only initiated after the 
first transmission is canceled.  It's not clear (to me, anyway) whether 
this is in fact necessary, or whether a "new file transfer operation" 
(as in Figure 3) could be initiated without canceling the current 
operation.  (Perhaps there's a port constraint here?)

2. In Section 8.2.1, why is "name" a MAY for inclusion in the file 
selector, while the others are MUSTs?

3. In Section 8.2.2, shouldn't it be "The file receiver ... MUST add at 
least one of the selectors defined..." (instead of SHOULD)?  What would 
it mean for the recipient to send a blank file-selector?  "Send me a 
file!  Any file!"?

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