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

Michael Tuexen <tuexen@fh-muenster.de> Mon, 01 December 2014 19:59 UTC

Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen <tuexen@fh-muenster.de>
In-Reply-To: <CAOgPGoD+qwGNSNhr__+FGAnMqK3AA=OJrFXSagEP-D6ho-V5AA@mail.gmail.com>
Date: Mon, 01 Dec 2014 20:59:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC9C3118-E4C7-49E9-B4E0-07935EF08BDC@fh-muenster.de>
References: <CAOgPGoCrkz5pKT-qCnCNwEVsWE-9zzK9erMAU+_10NSvMTmrtQ@mail.gmail.com> <C4F8E721-C808-4497-B185-112C9A702016@fh-muenster.de> <CAOgPGoD+qwGNSNhr__+FGAnMqK3AA=OJrFXSagEP-D6ho-V5AA@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/AeBdjVnFRwwnTJ1Mdebbba6SB6g
Cc: draft-ietf-tsvwg-sctp-prpolicies.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-sctp-prpolicies-05
Precedence: list

On 01 Dec 2014, at 20:44, Joseph Salowey <joe@salowey.net> wrote:

> 
> 
> On Mon, Dec 1, 2014 at 11:28 AM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> On 01 Dec 2014, at 19:39, Joseph Salowey <joe@salowey.net> 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.
> >
> > I have reviewed this document and believe it is Ready with minor issues.
> 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) :
> >
> >   "If PR-SCTP as defined in [RFC3758
> > ] is used, FORWARD-TSN chunks MUST
> >    also be sent in an authenticated way as described in [
> > 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
> 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?
> 
> [Joe] Yea, I think that would be OK.  
OK, I added:

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


>  
> > 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
> 
> [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
>  
> >
> > Cheers,
> >
> > Joe
> 
>

[secdir] secdir review of draft-ietf-tsvwg-sctp-p… Joseph Salowey
Re: [secdir] secdir review of draft-ietf-tsvwg-sc… Michael Tuexen
Re: [secdir] secdir review of draft-ietf-tsvwg-sc… Joseph Salowey
Re: [secdir] secdir review of draft-ietf-tsvwg-sc… Michael Tuexen