SECDIR review of draft-ietf-mmusic-file-transfer-mech-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!"?





_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]