[tsvwg] Status of fourth option

[Michael Tuexen <[e-mail]>]

Dear all,

John, Claudio, Magnus, and myself worked on the fourth option to secure 
SCTP-based communication. Since it was agreed on securing the traffic at
the SCTP packet level and use (D)TLS for the key management, we used the
solution described in
https://www.ietf.org/archive/id/draft-westerlund-tsvwg-sctp-dtls-chunk-03.html
as a starting point.

Such a solution needs to protect the contents of a DTLS chunk.
Let us call this function block the chunk protector. There are also
DTLS messages (like key  updates), which are protected.
Let us call this function block the record protector.

In Figure 1 of the ID, it is shown that the chunk protector gets the
required parameters from the key management of a DTLS implementation
running on top of the SCTP implementation via an API.

Figure 1 does not show the record protection function. Any DTLS messages
would be protected by the record protection function first, the passed to
the SCTP stack as a user message and the resulting DATA chunks (and other
chunks) would be protected by the chunk protector.

John, Claudio, and Magnus assume the record protector and the chunk protector
are the same function (or at least share a per protection operation state).
We all agree that this is implementable with a userland SCTP stack and a DTLS
stack, which provides DTLS messages. It is also possible in a kernel SCTP 
implementation that has a full DTLS stack in the kernel, e.g. WolfSSL has such
an DTLS implementation for Linux.

When implementing this with a kernel implementation, the chunk protector
needs for performance reasons to be part of the SCTP stack running in
the kernel. If the DTLS stack is implemented in userland, the record
protection would be part of the userland. Sharing the per protection
state is hard. Michael proposed therefore, once a DTLS connection
has been established to derive some key material (using the (D)TLS exporter)
and use that for the chunk protection. Also use separate sequence numbers.
This would require kernel and userland stacks to build the chunk protection 
as part of the SCTP stack and would allow to use an unmodified DTLS stack for 
the key management. It would also allow to use a TLS stack for key management.

This change John, Claudio, and Magnus had several issues with.
First it implies defining new security functions that will require
security analysis including formal analysis since it is not just using
DTLS as it is anymore. It will also result that any all-in user space or
all-in kernel implementations has to implement this SCTP security
specific record processing and can’t any longer just use an off-the-shelf
DTLS stack. Resulting in implementation efforts, maintenance and possibly
certification of implementation, thus it would, at least for Ericsson,
delay product delivery to customers.

Since we all agree that a solution should be developed in a timely matter,
and because 3GPP has asked for a solution for a very long time now,
we are reaching out to TSVWG for wider discussion and further input
and possibly a prompt decision on the way forwards.

This status report is agreed by all of us: John, Claudio, Magnus, and myself.

Best regards
Michael