The IESG has approved the Internet-Draft 'TLS over SCTP'
<draft-ietf-tsvwg-tls-over-sctp-00.txt> as a Proposed Standard. This
document is the product of the Transport Area Working Group Working
Group. The IESG contact persons are Allison Mankin and Scott Bradner.
Technical Summary
This document describes the usage of the Transport Layer Security (TLS)
protocol, as defined in [RFC2246], over the Stream Control Transmission
Protocol (SCTP), as defined in [RFC2960].
TLS is designed to run on top of a byte-stream oriented transport
protocol providing a reliable, in-sequence delivery. Thus, TLS is
currently mainly being used on top of the Transmission Control Protocol
(TCP), as defined in [RFC793].
SCTP has a number of different features from those of TCP, and this
specification shows how TLS should be used with those features.
This document defines
- how to use the multiple streams feature of SCTP.
- how to handle the message oriented nature of SCTP.
The document prohibits the use of SCTP's unordered message
delivery with TLS, since TLS requires in-sequence delivery in the
underlying transport. SCTP has controls to prevent unordered data
use, so this is a limitation, but it not does not complicate the
mapping to TLS.
The specification describes the use of full TLS handshake on
multiple SCTP streams in an association, full handshake on an
initial stream, followed by abbreviated (session resumption)
handshakes on additional streams, and use of abbreviated
handshakes on all streams, resuming from a TLS handshake
established by a pre-existing association.
Finally, the specification shows how the host multi-homing
feature of SCTP (the ability of the SCTP association to be
bound to multiple interfaces on the same host, with multiple
IP(v4/v6) addresses) interacts with TLS: TLS security
decisions must not be made based on IP-address, but rather on
some other authenticated identity. Following this rule,
a planned extension of SCTP to dynamically add or delete
IP-addresses to the association will also be usable with TLS.
Working Group Summary
The working group supported advancement. The document,
while still a non-working group internet-draft, had several
iterations to make the tradeoffs of choices about the use of
full and abbreviated handshakes clear enough. The TLS Working
Group supported development of the specification by the TSVWG,
and no issues were raised in IETF Last Call from the TLS
Working Group or the IETF community.
Protocol Quality
The document was reviewed for the IESG by Allison Mankin.
