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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf