Subject: Re: Secdir early review of draft-ietf-tsvwg-dtls-for-sctp-05

From: Michael Tüxen <[email-masked]>
Date: Fri, 21 May 2010 12:30:10 +0200

Hi Tobias,

thank you very much for the review. See my comments in-line.

Best regards
Michael

On May 12, 2010, at 3:47 AM, Tobias Gondrom wrote:

> FYI
> 
> 
> -------- Original Message --------
> Subject:	Secdir early review of draft-ietf-tsvwg-dtls-for-sctp-05
> Date:	Wed, 12 May 2010 01:02:45 +0100
> From:	Tobias Gondrom <[email-masked]>
> To:	[email-masked]
> CC:	[email-masked]
> 
> Dear TSVWG, dear James and Gorry, dear authors,
> 
> as requested (as a member of the Security Directorate) I conducted an
> early security review of the draft.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-dtls-for-sctp-05.txt
> 
> 
> Please consider this as my personal comments and advise and not as a
> formal security review.
> Please also note, I am not on the TSVWG mailinglist and will only
> receive answers or emails directed at me.
> 
> Anyhow the normal secdir disclaimer still applies:
> 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.
> 
> Please forgive me if I raise obvious or maybe even "stupid" questions
> below, but considering the documents stage I wanted to provide a
> thorough review and rather raise too many questions early than miss
> s.th. to be done later.
> 
> Anyway here it is:
> As far as I understood the draft describes how to implement Datagram
> Transport Layer Security (DTLS, rfc4347) for Stream Control Transmission
> Protocol (SCTP, rfc4960) which in turn is mainly designed to transport
> Public Switched Telephone Network (PSTN) signaling messages over IP
> networks. It shall provide the security equivalent of DTLS/TLS
> (authentication, message integrity and privacy) and use the transport
> features of SCTP (and extensions)
> 
> 0. First some general remarks:
> 0.1. In 1.1 Overview you described to support almost all transport
> features and extensions to SCTP: as I am a bit knew to SCTP, can you
> help me out: from the draft I take you mainly refer to 5061 and 3758,
> correct? Any other extensions you have in mind to use and which ones
> will not be excluded?
SCTP stream reset, which is defined in
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-strrst
However, I do not want to add a dependency, so I did not
explicitly refer to it. 
> 
> 0.2. I agree with the authors of DTLS that DoS is a major concern and
> the stateless cookie should be used to protect against amplify attacks.
> But actually does this collide with issue 9.1 below regarding cookie to
> protect amplification attacks and IP addresses in SCTP?
I agree with you that the cookie mechanism in DTLS is important and
useful. SCTP has a similar mechanism. It includes the cookie in the
INIT-ACK and it is reflected by the client in the COOKIE-ECHO.
So this kind of protection is already available in the SCTP layer.
You could use the DTLS cookie in addition, but you do not gain
any further protection.
> And I also wonder how much the fact that errors do not result in
> termination of transmission and the unordered transmission of datagrams
> may contribute to allow an attacker to run (small size) brute force
> attempts to break a cipher.
I'm not sure what you are considering:
DTLS/UDP also discards packets which to not pass the HMAC validation.
One difference is that the messages are additionally protected by
SCTP-AUTH, so if you do not know the secret for SCTP-AUTH, which is
derived from the shared secret, the SCTP layer will already discard the
packet and not the DTLS layer. But the result is the same.
> 
> 0.3. Furthermore considering that the handshake date can be quite large
> and the server must keep all data until all datagrams arrive, attacks
> only transmitting partial DTLS handshakes to flood servers may be a
> serious DoS risk (think of memory) as well.
Where is this different from DTLS/UDP, where you store message fragments?
> 
> Issues & Questions:
> 1. Regarding section 3.3 Replay Detection: “Replay detection of DTLS
> MUST NOT be used.”
> => I would ask whether this improves odds for an attacker to try and
> guess sequence numbers, for an attack.
Well, the same kind of replay protection is provided by SCTP. Once
a TSN is used, a receiver will drop further receptions of it. An
attacker can not change the message contents, since it is protected
by SCTP-AUTH. 
> Btw. I hope there is no relationship between SCTP SNs and DTLS SNs? (at
> least there SHOULD NOT be any. ;-) )
They are counted separately. However, when you observer the traffic,
you can see both numbers in the clear.
Once you change the epoch, you reset the DTLS SN, but not the SCTP ones.
> 
> 2. Question regarding 3.5. Retransmission of Messages: "DTLS procedures
> for retransmissions MUST NOT be used."
> => seems to be ok, just wondering how is the impact on operation? AFAIK
> the DTLS:WAITING then has only one exit (#3 in DTLS section 4.2.4)?
Correct. DTLS/SCTP can assume that all messages arrive exactly once
in the correct order.
> 
> 3. regarding 4.SCTP Considerations
> “4.1. Every SCTP user message MUST consist of exactly one DTLS record.”
> => in general the SCTP message:DTLS record mapping is not 1:1 but 1:N
> (natural number). Does this new narrowing to the subset make it much
> easier for an attacker to distinguish message types and could he
> leverage that, e.g. improving his odds for a DoS?
RFC 4347 says:
Multiple DTLS records may be placed in a single datagram.
So an implementation can put each DTLS record in its own datagram.
The same applies to DTLS/DCCP. So I see so substantial change here.
From a security point of view, there is no difference. The record
header is always transmitted in the clear and contains the length.
So an attacker can always easily reconstruct the individual records.
> 
> 4. Regarding 4.3. Payload Protocol Identifier Usage “Application
> protocols running over DTLS over SCTP SHOULD register and use a separate
> payload protocol identifier (PPID) and SHOULD NOT reuse the PPID that
> they registered for running directly over SCTP.”
> => Considering the very different security properties between DTLS/SCTP
> and SCTP only, might it be necessary to state this as a “MUST NOT reuse
> the PPID”... in order to prevent potential spoofing vulnerabilities of
> applications in higher layers?
Not sure what you exactly mean. Currently you can derive the upper
layer protocol most of the times from the port numbers used. If you
do not want that, you use non-registered port numbers. The same
applies for the PPID. If you do not want to provide a hint, use
PPID 0. PPIDs are very nice for packet analyzers, they can provide
a hint which protocol is used. And you can bundle several protocols
in one SCTP packet and they can dissected the different protocols
accordingly. However, if you do not want to provide the hint, use 0
instead.
If you really think that MUST NOT is better than SHOULD NOT, I'm fine
with it. We should only allow for providing 0, in case the application
does not want to say anything. 
> 
> 5. Regarding 4.4. Stream Usage: All DTLS messages of the
> ChangeCipherSpec, Alert, or Handshake protocol MUST be transported on
> stream 0 with unlimited reliability and with the ordered delivery feature.
> => I understand this requirement and agree with it.
> But, can in this case the ordered delivery feature on stream 0 be
> misused to DoS an ongoing transfer by using these message types? If so,
> how could this be prevented?
If an attacker wants to do that, it must know the shared secret used
for SCTP-AUTH which is derived from the master secret. So I guess
this is not possible. Considering the initial phase, were the master
secret is not yet established, it is possible. But this is the same
for DTLS/UDP. If you insert messages with the correct DTLS sequence
numbers, you can DoS the setup.
> 
> 6. Regarding 4.5. Chunk Handling paragraph 2 “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.
> => True. To go one step further, may it be advisable to explicitely
> mention that PR-SCTP SHOULD be used.
PR-SCTP is an option and not all SCTP support it. The nice thing is
that DTLS/SCTP support PR-SCTP if it is used, but there is not
reason to mandate its usage. It is only giving rules that if you
use it, you must use it in this way.
> 
> 7. Regarding 4.6. Handshake “...Before sending a ChangeCipherSpec
> message all outstanding SCTP user messages MUST have been acknowledged
> by the SCTP peer and MUST NOT be revoked anymore by the SCTP peer.”
> => Though I see the underlying idea I would disagree with this. Although
> it seems not to pose a material risk, considering a Man-in-the-middle
> could prevent ChangeCipherSpec from happening by removing one message or
> ack within each timeout span thus preventing any ChangeCipherSpec.
I do not understand your point. Could you elaborate?

The reason we put this stuff in is the following: We must make sure
that the DTLS layer doesn't discard any messages since DTLS/SCTP
provides a reliable service, if the user requests it. DTLS however,
is free to discard messages from old epochs (at least after some time).
So we must make sure that "old epochs are cleared up before a new starts".

Please not that an attacker can remove a packet and its retransmissions
and it will result in a stalled transfer. But this is the same for TLS/TCP.
> 
> 8. regarding 4.8. Shutdown
> => maybe a stupid question: I can see that this tries to satisfy rfc4346
> page assumption “...that closing a connection reliably delivers pending
> data before destroying the transport.”
> But is this appropriate in this case of underlying unordered SCTP use?
Yes, it is. A user of SCTP can expect a reliable service (if he wants)
and only has less restrictions on ordering. So it must be the same.

An SCTP user can also just use on stream, ordered transfer. Then
it is much like TLS/TCP, just message oriented instead of byte stream.
> And could it potentially allow an attacker to force the session be kept
> open, e.g. if only very few outstanding messages or their ack do not
> reach the peer?
The attacker can do the same as for TLS/TCP.
> 
> 9. Regarding 6. Security Considerations
> 9.1. “It is possible to authenticate DTLS endpoints based on
> IP-addresses in certificates. SCTP associations can use multiple
> addresses per SCTP endpoint. Therefore it is possible that DTLS records
> will be sent from a different IP-address than that originally
> authenticated. This is not a problem provided that no security decisions
> are made based on that IP-address. This is a special case of a general
> rule: all decisions should be based on the peer's authenticated
> identity, not on its transport layer identity.”
> => actually doesn't this pose a problem when DTLS uses the Cookie
> countermeasure to prevent DoS attacks with handshake (refer to DTLS
> section 4.2.1)?
No. You do not base any identity decisions an the cookie. It is just
that you verify that the peer owns the IP address it is providing you.
That is all. You do not use this information for further processing
inside DTLS.

The text above is actually not new. It is similar to section 9 of
RFC 3436, which describes the usage of TLS/SCTP.
> 
> 9.2. “For each message, the SCTP user also provides a stream identifier,
> a flag to indicate whether the message is sent ordered or unordered and
> a payload protocol identifier. Although DTLS can be used to provide
> privacy for the actual user message, none of these three are protected
> by DTLS. They are sent as clear text, because they are part of the SCTP
> DATA chunk header.”
> => Hm, the fact that the PPID is clear text seems like a
> privacy/information leakage problem to me, especially as it will
> disclose the application running on top of DTLS. Or wouldn't it?
Well, it is similar to the port number used. If the application does
not want to provide a hint, it can use 0.
> => comment: stream identifier and ordered/unordered flag allows to infer
> which message type in DTLS is transferred. But unavoidable and should be
> ok.
Yes it can't be avoided. That is why I put it into the document.
If you want to avoid it, you must encrypt in the SCTP layer. But
that would require changes inside SCTP, which is not what is intended
by this document.

Please let me know what you think. Currently I see no required changes
on the document, except for the suggested for the PPID SHOULD NOT to
MUST NOT, but I would like to get some feedback from you first.

Thanks again for the review.

Best regards
Michael
> 
> Best wishes,
> 
> Tobias
> 
> 
> Tobias Gondrom
> Sec-Dir member/LTANS chair
> email: 
> [email-masked]
> 
> 
> 
>