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

[Joseph Salowey <[e-mail]>]

On Mon, Dec 1, 2014 at 11:28 AM, Michael Tuexen <[e-mail]>
wrote:

> On 01 Dec 2014, at 19:39, Joseph Salowey <[e-mail]> 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.


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


> >
> > Cheers,
> >
> > Joe
>
>