Subject: [secdir] secdir review of draft-ietf-tsvwg-sctp-prpolicies-05

From: Joseph Salowey <[email-masked]>
Date: Mon, 1 Dec 2014 10:39:22 -0800

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.

I have reviewed this document and believe it is Ready with minor issues.

This document describes new policies for the users of the SCTP Partial
Reliability service (SCTP-PR).  These policies cover discarding data after
too many retransmissions and discarding lower priority data.

The security considerations are a bit thin.  They mostly refer to RFC 3758
which is also a bit thin and was published before SCTP-DTLS was available.
There is some useful text in RFC 6083 (SCTP-DTLS) :

  "If PR-SCTP as defined in [RFC3758
<https://tools.ietf.org/html/rfc3758>] is used, FORWARD-TSN chunks
MUST
   also be sent in an authenticated way as described in [RFC4895
<https://tools.ietf.org/html/rfc4895>].  This
   makes sure that it is not possible for an attacker to drop messages
   and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this
   dropping."

I think it would be good to include similar text in this document since it
is relevant.  Are there any problems introduced if the INIT or the INIT-ACK
messages are not protected?

Cheers,

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 1 Dec 2014 20:28:18 +0100

On 01 Dec 2014, at 19:39, Joseph Salowey <[email-masked]> 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.
> 
Hi Joe,

thank you very much for your review. See my comments below.

Best regards
Michael
> 
> This document describes new policies for the users of the SCTP Partial Reliability service (SCTP-PR).  These policies cover discarding data after too many retransmissions and discarding lower priority data.  
> 
> The security considerations are a bit thin.  They mostly refer to RFC 3758 which is also a bit thin and was published before SCTP-DTLS was available.  There is some useful text in RFC 6083 (SCTP-DTLS) :
> 
> ] is used, FORWARD-TSN chunks MUST
> ].  This
> I think it would be good to include similar text in this document since it is relevant.  Are there any problems 
I see your point, but this usage of AUTH in combination with DTLS is not related to the
particular PR-SCTP policy. One could add a sentence stating that if DTLS over SCTP as specified
in RFC 6083, the corresponding security considerations also apply. Would that address your issue?
> introduced if the INIT or the INIT-ACK messages are not protected?  
No. You can't protect them, see
https://tools.ietf.org/html/rfc4895#section-3.2

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 1 Dec 2014 11:44:32 -0800

On Mon, Dec 1, 2014 at 11:28 AM, Michael Tuexen <[email-masked]>
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
> > The security considerations are a bit thin.  They mostly refer to RFC
> 3758 which is also a bit thin and was published before SCTP-DTLS was
> available.  There is some useful text in RFC 6083 (SCTP-DTLS) :
> >

[Joe] Yea, I think that would be OK.

> https://tools.ietf.org/html/rfc4895#section-3.2

[Joe] Ah, OK.  So it seems the INIT negotiation is unprotected and may be
modified by an attacker.  Probably not something to address in this draft,
but I wonder if there are some potential issues here.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 1 Dec 2014 20:59:29 +0100

On 01 Dec 2014, at 20:44, Joseph Salowey <[email-masked]> wrote:

> 
> 
> On Mon, Dec 1, 2014 at 11:28 AM, Michael Tuexen <[email-masked]> wrote:
OK, I added:

If DTLS over SCTP as specified in <xref target='RFC6083'/> is used, the
security considerations of <xref target='RFC6083'/> do apply.

> [Joe] Ah, OK.  So it seems the INIT negotiation is unprotected and may be modified by an attacker.  Probably not something to address in this draft, but I wonder if there are some potential issues here.  
What can an attacker do? If an attacker removes the DATA chunk from the chunks to be authenticated,
the peer can detect this. The only consistent way is to remove the PR-SCTP supported parameter and
the FORWARD TSN parameter from the INIT/INIT-ACK. This means that one side thinks that PR-SCTP is
not supported by the peer and the other side thinks that it is supported. The only thing an attacker
can do is to remove FORWARD-TSN chunks und insert SACKs. This will result in a deadlock situation
of the peer which would have received the FORWARD TSN. But the attacker can do this anyway by
removing other messages. So I don't see an issue here.

Best regards
Michael