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

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 16 Jan 2009 12:05:30 +0100

Richard,

Thanks for your review. Before addressing your comments, I would like to 
offer you a bit of background information. This draft addresses SDP and 
how SDP can be used to describe a file that is going to be transferred 
using "any other protocol". At the moment, the only "any other protocol" 
described in the document is MSRP, but there could be more in the future. 
Since the draft is about SDP, we try to avoid discussions about MSRP 
(including its security aspects). So, the goal is to extend SDP and use 
an off-the-shelf SIP (or any other higher layer signaling protocol) and 
MSRP (or any other file transfer protocol). We include a minimum 
discussion about MSRP, the minimum that is needed to implement the draft 
and provide interoperability.

Please find some inline comments now.

On 19/12/2008 0:44, Richard Barnes wrote:
> 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).

As I indicated earlier, the document is focusing on SDP. Therefore, we 
should focus on SDP only, because when the implementor decides to use 
MSRP, it will use a standard off-the-shelf MSRP stack and he won't have a 
chance to change the security properties of MSRP.

>
> 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.

I see your point. We need to distinguish between a rough file sender (who 
describes a file but sends another one) and an attacker that modifies the 
SDP. The latter can be easily tracked by using integrity protection in 
SDP. The former can only be tracked by validating the received file 
against the selectors of the file. I will add some text to mandate 
validation.

With respect to Sections 8.2.2 and 8.3.2, there is already text in 
Section 8.2.2 to make the file receiver verify the hash (see second 
paragraph in 8.2.2).

>
> 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.

No, the third paragraph indicates how to protect the SDP Offer/answer, 
not how to protect the file transfer. As I said, the file transfer is not 
in the scope of the document.

>
> 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.
>

Right, there is a point. Essentially, we are assuming a high-level 
protocol, such as SIP, that brings some of this functions. For example, 
an SDP offer transported in a SIP INVITE request is generally never 
automatically accepted and typically always authenticated. I will add 
some text to the security considerations sections to highlight the 
assumptions on the high-level protocol.

> 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?)

I think the text you are looking for is written in the first paragraph in 
Section 8.7, when we say that "one file equals one MSRP session". 
Therefore, it is not possible to re-use an existing MSRP session for 
sending a different file.

This must not be confused with simultaneous MSRP sessions. It is possible 
to have two separate MSRP media streams, each sending a different file 
(or even one one being used for regular text chat). But each of these 
will be different MSRP sessions, and each MSRP session, one and only one 
file can be transmitted.

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

The others (type, size, or hash) are not really mandatory. ONE of them is 
mandatory (anyone), but the others are optional. The reason: the sender 
has to include a minimum description of the file that is trying to send. 
This can be: here is a JPEG file, or here is a file or size xxx bytes, or 
here is a file whose hash is yyy. Or a combination of them. All these 
describe the file. However, the name is locally chosen, and does not 
describe the properties of the file. It is merely a label locally chosen 
by the sender, so, it does not describe the file nor it is of much value 
for the SDP answerer.

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

That is right. I am changing it to MUST. There is one case where the 
file-selector attribute can be empty, but that is not part of the 
offer/answer model: it is to signal capabilities in a 200 response for an 
OPTIONS request (see Section 8.5 in the draft). Since the OPTIONS 
response is not part of the offer/answer model, then it is not impacted 
by the offer/answer procedures.

Thanks for your review. We will be posting an updated version in the 
coming days.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Jan 2009 09:36:11 -0500

Hi Miguel,

Thanks for your reply.  A couple of responses below.
(Some comments trimmed)

--Richard

> using "any other protocol". 

Thanks for the clarification.  I still think a lot of my comments are 
still applicable, since they relate to how the SDP lines with the 
file-transfer protocol -- the part that's specific to this document.

> MSRP, it will use a standard off-the-shelf MSRP stack and he won't have 
> a chance to change the security properties of MSRP.

I agree with this, and think the document does a pretty good job of 
addressing the authenticity/integrity/confidentiality concerns for the 
SDP (my comment was poorly worded).

However, what I meant to say was that the security properties of the 
file-transfer protocol are also important to the overall security of the 
file-transfer mechanism.  So there should be some discussion of them 
here.  For MSRP, it would suffice to cite RFC 4975; if you want to allow 
for others, you could include requirements for security features.

>> bit-for-bit perfect as it goes over the wire. <snip/>
> I see your point. We need to distinguish between a rough file sender 
> (who describes a file but sends another one) and an attacker that 
> modifies the SDP. The latter can be easily tracked by using integrity 
> protection in SDP. The former can only be tracked by validating the 
> received file against the selectors of the file. I will add some text to 
> mandate validation.

Thanks.  I'll review this text when it's available.

> Section 8.2.2 to make the file receiver verify the hash (see second 

I saw that text, but I wondered why it's not a MUST.  It would be nice 
to also have SHOULD-level requirements to verify other selector criteria 
as well.

> not how to protect the file transfer. As I said, the file transfer is 
> not in the scope of the document.

Acknowledged.  I had misunderstood the intent of the first part of the 
Security Considerations.  However, see my response above on the fact 
that the security of the file-transfer protocol needs to at least be 
mentioned in this document.

> assumptions on the high-level protocol.

That sounds good.  It's OK to make assumptions like this, but there 
needs to be some text to say that it's necessary for the sender to be 
able to authenticate the receiver.  (Otherwise, you end up with the 
moral equivalent of anonymous FTP!)

> I think the text you are looking for is written in the first paragraph 
> in Section 8.7, when we say that "one file equals one MSRP session". 
> This must not be confused with simultaneous MSRP sessions. It is 
> possible to have two separate MSRP media streams, each sending a 
> different file (or even one one being used for regular text chat). But 
> each of these will be different MSRP sessions, and each MSRP session, 
> one and only one file can be transmitted.

Here's where I think the confusion lies: If I wanted to signal a new 
MSRP session to transfer a file with the same selector -- NOT cancel the 
current session, just initiate a second one -- my UA would send an offer 
that is identical to the first one except for the "file-transfer-id" 
attribute.  This usage is not possible with the current text.

This use case is not extraordinarily important, but it's not trivial 
either: E.g., if the selector had only the file-name and file-type 
portions filled in, then the same selector might match many files (say, 
different versions a log file that get rotated).

I don't really care if this use case gets ruled out, but it would be 
helpful if you could clarify whether it's in or out.  If it's out, no 
normative text needs to change.  If it's in, you might need a different 
"cancel" mechanism than a change in file-transfer-id, but it seems like 
normal session-termination techniques (BYE) would apply.

> offer/answer model: it is to signal capabilities in a 200 response for 
> an OPTIONS request (see Section 8.5 in the draft). Since the OPTIONS 

It's always nice to get something right :)  It might be worth noting the 
special case, just so people are aware.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 19 Jan 2009 15:44:39 +0100

Hi Richard:

Some further discussion down. I have also trimmed to the relevant parts.

> I saw that text, but I wondered why it's not a MUST. It would be nice to
> also have SHOULD-level requirements to verify other selector criteria as
> well.
>

The text under discussion says:

If the SDP answer contains a supported hashing algorithm in the 'hash' 
selectors of the 'file-selector' attribute, then the file receiver SHOULD 
compute the hash of the file after its reception and check it against the 
hash received in the answer.

There are several reasons for not upgrading this text to a MUST strength.
1) This is a local action that takes place entirely in one of the 
endpoints and does not affect interoperability. It is clear that there is 
a high recommendations for implementations to verify that the file has 
been correctly received, but on top of it there is a local policy or even 
implementation capabilities. Since interoperability is not affected, I 
don't see a big reason for having a MUST strength.

2) The  'hash' selector is optional. So, having a text that says "if you 
happen to know the hash please verify that the file computes to that 
hash" does not offer much security. Any rough implementation would simply 
not indicate the hash from the selector list.

> attribute. This usage is not possible with the current text.

So, you want to send once more the same file in a new MSRP session. So, 
then it is a DIFFERENT MSRP session, and this MSRP session is signaled in 
SDP in an additional m= line. It is also a different file transfer id as 
you mentioned. I don't see which parts of the draft will prevent this 
(weird) use case. I think Figure 3 allows it. In particular, the 
discussion around figure 3 lies about the comparison of two SDP offers 
emitted in different times.

> different versions a log file that get rotated).

Then, what you are trying to do is to finish a given file transfer 
operation (with the current methods for finishing MSRP sessions) and 
re-issuing a new file transfer operation, later in time, but with the 
same file. This new operation will contain a newly created 
file-transfer-id, preferable over a newly created MSRP session, since the 
old one is going to be over for quite some time.

All in all, there is nothing that relates the old (completed) file 
transfer with the new one, except for the name of the file.

/Miguel

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Jan 2009 22:19:52 -0500

Hey Miguel,
A couple more comments, again trimmed.  I think we're converging...
--Richard

>> also have SHOULD-level requirements to verify other selector criteria as
<snip>
> endpoints and does not affect interoperability. It is clear that there 
> is a high recommendations for implementations to verify that the file 
> has been correctly received, but on top of it there is a local policy or 
> even implementation capabilities. Since interoperability is not 
> affected, I don't see a big reason for having a MUST strength.

Just because it's host-local doesn't mean it's out of scope.  Checks 
values in a message are frequently specified at a MUST level (though not 
always, I admit).  See, for example, the host identity checks in HTTPS 
(RFC 2818, Section3.1), or the validation techniques for PKIX 
certificates (RFC 5280, Section6).

> hash" does not offer much security. Any rough implementation would 
> simply not indicate the hash from the selector list.

That's a valid argument if the 'hash' selector is the only one that MUST 
be verified.  To strengthen what I said above, it should be that *all* 
the selector attributes MUST be verified: Some selector will always be 
sent, and the file sender is misbehaving if he sends a file that does 
not match the selector.  So whatever the selector is, there should be a 
requirement that the file sender MUST send only a file that matches that 
selector, and that the file receiver MUST verify that the file matches 
the selector, simply to ensure the correct operation of the protocol.

> then it is a DIFFERENT MSRP session, and this MSRP session is signaled 
> in SDP in an additional m= line. It is also a different file transfer id 
> as you mentioned. I don't see which parts of the draft will prevent this 

Ah, I hadn't grokked what you were saying about the different sessions. 
  Now that I understand, this makes sense.  Comment retracted.
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 21 Jan 2009 12:37:38 +0100

Richard Barnes wrote:
>> has been correctly received, but on top of it there is a local policy 
>> or even implementation capabilities. Since interoperability is not 

I can replace the SHOULD with a MUST strength, but:
a) It is not aligned with the conventions used by most of the other SIP RFCs.
b) IMHO it is not aligned with the definition of "MUST" in RFC 2119, 
which says:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.

Obviously, checking that the hash of the file computes the advertised 
hash of the file, is far from being an "absolute requirement".

But I can write a MUST to close this discussion.

> 
>> 2) The  'hash' selector is optional. So, having a text that says "if 
>> you happen to know the hash please verify that the file computes to 
>> that hash" does not offer much security. Any rough implementation 
>> would simply not indicate the hash from the selector list.
> 

Again, I disagree, but just to close the discussion, I will add text that 
indicates the MUST strength with respect the other selectors.

/Miguel

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Jan 2009 09:39:44 -0500

<[email-masked]> wrote:

> Hi Richard. Some inlines comments.
>
> Richard Barnes wrote:
>> Hey Miguel,
>>>> to also have SHOULD-level requirements to verify other selector
>>>> criteria as well.
>> <snip>
> a) It is not aligned with the conventions used by most of the other SIP
> RFCs. b) IMHO it is not aligned with the definition of "MUST" in RFC
> 2119,  which says:
>

You could, but I don't think you should.  Generally, an RFC2119 MUST (or 
even SHOULD) is appropriate to use when not behaving as specified would 
have an impact on interoperability, security, or similar considerations, or 
would otherwise just make things not work.

I don't believe that failing to verify a checksum on a received file has 
that sort of impact, given that the checksum is not a hash used to protect 
file integrity against deliberate attacks.

>> not match the selector.

So what?  An receiver might wish to know if a sender is misbehaving in this 
way, but doing so doesn't actually break the protocol.

>> So whatever the selector is, there should be a
>> selector

This is a reasonable requirement, though I'm not sure I would make it 
stronger than SHOULD.  I can think of situations where you'd want to ignore 
that requirement, but I don't know whether they'd acutally apply to this 
protocol.  For example, it's kind of hard to send a hash or checksum of an 
indefinite-length stream.

>> , and that the file receiver MUST verify that the file matches

Why?  Checking that another protocol participant is behaving correctly 
requires extra time and complexity.  If an implementation wishes to do so, 
that's fine, to an extent, but we should not require such checks unless 
they are actually necessary.

-- Jeff

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Jan 2009 09:47:32 -0500

One more go-round....
--Richard

>> values in a message are frequently specified at a MUST level (though 
>> not always, I admit).  See, for example, the host identity checks in 
>> HTTPS (RFC 2818, Section3.1), or the validation techniques for PKIX 
> RFCs.
> <snip/> 

I tend to side with the philosophy that you should only have a SHOULD 
when there are clear conditions when a host would *not* do what the 
document recommends.  In this case, there doesn't seem to be a good 
reason why a host *wouldn't* verify the selectors.

However, as long as there is a requirement that hosts verify the 
selectors, I would hold this draft up over a MUST/SHOULD debate.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 22 Jan 2009 10:59:24 +0100

I think Richard has came to the conclusion that SHOULD strength (for hash 
verifications) is enough in this case. Therefore, I will proceed 
according to it. Thanks for your comments.

/Miguel

Jeffrey Hutzelman wrote:
> --On Wednesday, January 21, 2009 12:37:38 PM +0100 "Miguel A. Garcia" 
> have an impact on interoperability, security, or similar considerations, 
> or would otherwise just make things not work.
> 
> that sort of impact, given that the checksum is not a hash used to 
> protect file integrity against deliberate attacks.
> 
> So what?  An receiver might wish to know if a sender is misbehaving in 
> this way, but doing so doesn't actually break the protocol.
> 
> stronger than SHOULD.  I can think of situations where you'd want to 
> ignore that requirement, but I don't know whether they'd acutally apply 
> to this protocol.  For example, it's kind of hard to send a hash or 
> checksum of an indefinite-length stream.
> 
> 
> 
> 
> requires extra time and complexity.  If an implementation wishes to do 
> so, that's fine, to an extent, but we should not require such checks 
> unless they are actually necessary.
> 
> -- Jeff