draft-ietf-tsvwg-dtls-for-sctp-05.txt   draft-ietf-tsvwg-dtls-for-sctp-06.txt 
Network Working Group M. Tuexen Network Working Group M. Tuexen
Internet-Draft R. Seggelmann Internet-Draft R. Seggelmann
Intended status: Standards Track Muenster Univ. of Applied Sciences Intended status: Standards Track Muenster Univ. of Applied Sciences
Expires: September 23, 2010 E. Rescorla Expires: March 5, 2011 E. Rescorla
RTFM, Inc. RTFM, Inc.
March 22, 2010 September 1, 2010
Datagram Transport Layer Security (DTLS) for Stream Control Transmission Datagram Transport Layer Security (DTLS) for Stream Control Transmission
Protocol (SCTP) Protocol (SCTP)
draft-ietf-tsvwg-dtls-for-sctp-05.txt draft-ietf-tsvwg-dtls-for-sctp-06.txt
Abstract Abstract
This document describes the usage of the Datagram Transport Layer This document describes the usage of the Datagram Transport Layer
Security (DTLS) protocol over the Stream Control Transmission Security (DTLS) protocol over the Stream Control Transmission
Protocol (SCTP). Protocol (SCTP).
Security features provided by DTLS over SCTP include authentication, DTLS over SCTP provides communications privacy for applications that
message integrity and privacy of user messages. Applications using use SCTP as its transport protocol and allows client/server
DTLS over SCTP can use almost all transport features provided by SCTP applications to communicate in a way that is designed to prevent
and its extensions. eavesdropping and detect tampering or message forgery.
Applications using DTLS over SCTP can use almost all transport
features provided by SCTP and its extensions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on March 5, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 13
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 4 3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
This document describes the usage of the Datagram Transport Layer This document describes the usage of the Datagram Transport Layer
Security (DTLS) protocol, as defined in [RFC4347], over the Stream Security (DTLS) protocol, as defined in [RFC4347], over the Stream
Control Transmission Protocol (SCTP), as defined in [RFC4960]. Control Transmission Protocol (SCTP), as defined in [RFC4960].
Security features provided by DTLS over SCTP include authentication, DTLS over SCTP provides communications privacy for applications that
message integrity and privacy of user messages. Applications using use SCTP as its transport protocol and allows client/server
DTLS over SCTP can use almost all transport features provided by SCTP applications to communicate in a way that is designed to prevent
and its extensions. eavesdropping and detect tampering or message forgery.
Applications using DTLS over SCTP can use almost all transport
features provided by SCTP and its extensions.
TLS, from which DTLS was derived, is designed to run on top of a TLS, from which DTLS was derived, is designed to run on top of a
byte-stream oriented transport protocol providing a reliable, in- byte-stream oriented transport protocol providing a reliable, in-
sequence delivery. Thus, TLS is currently mainly being used on top sequence delivery. Thus, TLS is currently mainly being used on top
of the Transmission Control Protocol (TCP), as defined in [RFC0793]. of the Transmission Control Protocol (TCP), as defined in [RFC0793].
TLS over SCTP as described in [RFC3436] has some serious limitations: TLS over SCTP as described in [RFC3436] has some serious limitations:
o It does not support the unordered delivery of SCTP user messages. o It does not support the unordered delivery of SCTP user messages.
skipping to change at page 4, line 8 skipping to change at page 4, line 10
o the partial reliability extension as defined in [RFC3758]. o the partial reliability extension as defined in [RFC3758].
o the dynamic address reconfiguration extension as defined in o the dynamic address reconfiguration extension as defined in
[RFC5061]. [RFC5061].
However, the following limitations still apply: However, the following limitations still apply:
o The maximum user message size is 2^14 bytes, which is the DTLS o The maximum user message size is 2^14 bytes, which is the DTLS
limit. limit.
o The DTLS user can not perform the SCTP-AUTH key management, o The DTLS user cannot perform the SCTP-AUTH key management, because
because this is done by the DTLS layer. this is done by the DTLS layer.
The method described in this document requires that the SCTP The method described in this document requires that the SCTP
implementation supports the optional feature of fragmentation of SCTP implementation supports the optional feature of fragmentation of SCTP
user messages as defined in [RFC4960] and the SCTP authentication user messages as defined in [RFC4960] and the SCTP authentication
extension defined in [RFC4895]. extension defined in [RFC4895].
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
skipping to change at page 4, line 46 skipping to change at page 5, line 4
TLS: Transport Layer Security. TLS: Transport Layer Security.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. DTLS Considerations 3. DTLS Considerations
3.1. Version of DTLS
3.1. Future Versions of DTLS This document is based on [RFC4347] and it is expected that DTLS/SCTP
as described in this document will work with future versions of DTLS.
This document is based on [RFC4347]. If a new RFC updates or
obsoletes [RFC4347], this documents also applies to the newer
document defining DTLS unless this document also gets updated or
revised.
3.2. Message Sizes 3.2. Message Sizes
DTLS limits the DTLS user message size to the current Path MTU minus DTLS limits the DTLS user message size to the current Path MTU minus
the header sizes. This limit SHOULD be increased to 2^14 Bytes for the header sizes. For the purposes of running over SCTP, the DTLS
DTLS over SCTP. path MTU MUST be considered to be 2^14.
3.3. Replay Detection 3.3. Replay Detection
Replay detection of DTLS MUST NOT be used. The replay detection of DTLS may result in the DTLS layer dropping
messages. Since DTLS/SCTP provides a reliable service if requested
by the application, replay detection cannot be used. Therefore,
replay detection of DTLS MUST NOT be used.
3.4. Path MTU Discovery 3.4. Path MTU Discovery
Path MTU discovery of DTLS MUST NOT be used. SCTP provides Path MTU discovery and fragmentation / reassembly for
user-messages. According to Section 3.2 DTLS can send maximum sized
messages. Therefore, Path MTU discovery of DTLS MUST NOT be used.
3.5. Retransmission of Messages 3.5. Retransmission of Messages
DTLS procedures for retransmissions MUST NOT be used. SCTP provides a reliable and in-sequence transport service for DTLS
messages which require it. See Section 4.4. Therefore, DTLS
procedures for retransmissions MUST NOT be used.
4. SCTP Considerations 4. SCTP Considerations
4.1. Mapping of DTLS Records 4.1. Mapping of DTLS Records
The supported maximum length of SCTP user messages MUST be at least The supported maximum length of SCTP user messages MUST be at least
2^14 + 2048 + 13 = 18445 bytes (2^14 + 2048 is the maximum length of 2^14 + 2048 + 13 = 18445 bytes (2^14 + 2048 is the maximum length of
the DTLSCiphertext.fragment and 13 is the size of the DTLS record the DTLSCiphertext.fragment and 13 is the size of the DTLS record
header). In particular, the SCTP implementation MUST support header). In particular, the SCTP implementation MUST support
fragmentation of user messages. fragmentation of user messages.
skipping to change at page 5, line 49 skipping to change at page 6, line 11
Each DTLS connection MUST be established and terminated within the Each DTLS connection MUST be established and terminated within the
same SCTP association. A DTLS connection MUST NOT span multiple SCTP same SCTP association. A DTLS connection MUST NOT span multiple SCTP
associations. associations.
4.3. Payload Protocol Identifier Usage 4.3. Payload Protocol Identifier Usage
Application protocols running over DTLS over SCTP SHOULD register and Application protocols running over DTLS over SCTP SHOULD register and
use a separate payload protocol identifier (PPID) and SHOULD NOT use a separate payload protocol identifier (PPID) and SHOULD NOT
reuse the PPID that they registered for running directly over SCTP. reuse the PPID that they registered for running directly over SCTP.
Using the same PPID does not harm as long as the application can
determine whether DTLS is used or not. However, for protocol
analyzers, for example, it is much easier if a separate PPID is used.
This means in particular that there is no specific PPID for DTLS. This means in particular that there is no specific PPID for DTLS.
4.4. Stream Usage 4.4. Stream Usage
All DTLS messages of the ChangeCipherSpec, Alert, or Handshake All DTLS messages of the ChangeCipherSpec, Alert, or Handshake
protocol MUST be transported on stream 0 with unlimited reliability protocol MUST be transported on stream 0 with unlimited reliability
and with the ordered delivery feature. and with the ordered delivery feature.
All DTLS messages of the ApplicationData protocol MAY be transported DTLS messages of the ApplicationData protocol SHOULD use multiple
over stream 0, but users SHOULD use other streams to avoid possible streams other than stream 0; they MAY use stream 0 for everything if
performance problems due to head of line blocking. they do note care about minimizing head of line blocking.
4.5. Chunk Handling 4.5. Chunk Handling
DATA chunks of SCTP MUST be sent in an authenticated way as described DATA chunks of SCTP MUST be sent in an authenticated way as described
in [RFC4895]. Other chunks MAY be sent in an authenticated way. in [RFC4895]. Other chunks MAY be sent in an authenticated way.
This makes sure that an attacker can not modify the stream in which a This makes sure that an attacker cannot modify the stream in which a
message is sent in or affect the ordered/unordered delivery of the message is sent in or affect the ordered/unordered delivery of the
message. message.
If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST 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 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 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 and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this
dropping. dropping.
4.6. Handshake 4.6. Renegotiation
DTLS supports renegotiation and therefore this feature is also
available by DTLS/SCTP. It is up to the upper layer to use/allow it
or not. Application writers should be aware that allowing
renegotiations may result in changes of security parameters.
4.7. Handshake
A DTLS implementation discards DTLS messages from older epochs after A DTLS implementation discards DTLS messages from older epochs after
some time, as described in section 4.1 of [RFC4347]. This is not some time, as described in section 4.1 of [RFC4347]. This is not
acceptable when the DTLS user performs a reliable data transfer. To acceptable when the DTLS user performs a reliable data transfer. To
avoid discarding messages, the following procedures are required. avoid discarding messages, the following procedures are required.
Before sending a ChangeCipherSpec message all outstanding SCTP user Before sending a ChangeCipherSpec message all outstanding SCTP user
messages MUST have been acknowledged by the SCTP peer and MUST NOT be messages MUST have been acknowledged by the SCTP peer and MUST NOT be
revoked anymore by the SCTP peer. revoked by the SCTP peer.
Prior to processing a received ChangeCipherSpec all other received Prior to processing a received ChangeCipherSpec all other received
SCTP user messages that are buffered in the SCTP layer MUST be read SCTP user messages that are buffered in the SCTP layer MUST be read
and processed by DTLS. and processed by DTLS.
User messages arriving between ChangeCipherSpec and Finished using User messages arriving between ChangeCipherSpec and Finished using
the new epoch have probably passed the Finished and MUST be buffered the new epoch have probably passed the Finished and MUST be buffered
by DTLS until the Finished is read. by DTLS until the Finished is read.
4.7. Handling of Endpoint-pair Shared Secrets 4.8. Handling of Endpoint-pair Shared Secrets
The endpoint-pair shared secret for Shared Key Identifier 0 is empty The endpoint-pair shared secret for Shared Key Identifier 0 is empty
and MUST be used when establishing a DTLS connection. Whenever the and MUST be used when establishing a DTLS connection. Whenever the
master key changes, a 64 byte shared secret is derived from every master key changes, a 64 byte shared secret is derived from every
master secret and provided as a new end-point pair shared secret by master secret and provided as a new end-point pair shared secret by
using the exporter described in [RFC5705]. The exporter MUST use the using the exporter described in [RFC5705]. The exporter MUST use the
label given in Section 5 and no context. The new Shared Key label given in Section 5 and no context. The new Shared Key
Identifier MUST be the old Shared Key Identifier incremented by 1. Identifier MUST be the old Shared Key Identifier incremented by 1.
If the old one is 65535, the new one MUST be 1. If the old one is 65535, the new one MUST be 1.
Before sending the Finished message the active SCTP-AUTH key MUST be Before sending the Finished message the active SCTP-AUTH key MUST be
switched to the new one. switched to the new one.
Once the corresponding Finished message from the peer has been Once the corresponding Finished message from the peer has been
received, the old SCTP-AUTH key SHOULD be removed. received, the old SCTP-AUTH key SHOULD be removed.
4.8. Shutdown 4.9. Shutdown
To prevent DTLS from discarding DTLS user messages while it is To prevent DTLS from discarding DTLS user messages while it is
shutting down, a CloseNotify message MUST only be sent after all shutting down, a CloseNotify message MUST only be sent after all
outstanding SCTP user messages have been acknowledged by the SCTP outstanding SCTP user messages have been acknowledged by the SCTP
peer and MUST NOT still be revoked by the SCTP peer. peer and MUST NOT still be revoked by the SCTP peer.
Prior to processing a received CloseNotify all other received SCTP Prior to processing a received CloseNotify all other received SCTP
user messages that are buffered in the SCTP layer MUST be read and user messages that are buffered in the SCTP layer MUST be read and
processed by DTLS. processed by DTLS.
skipping to change at page 8, line 9 skipping to change at page 8, line 27
all decisions should be based on the peer's authenticated identity, all decisions should be based on the peer's authenticated identity,
not on its transport layer identity. not on its transport layer identity.
For each message, the SCTP user also provides a stream identifier, a For each message, the SCTP user also provides a stream identifier, a
flag to indicate whether the message is sent ordered or unordered and flag to indicate whether the message is sent ordered or unordered and
a payload protocol identifier. Although DTLS can be used to provide a payload protocol identifier. Although DTLS can be used to provide
privacy for the actual user message, none of these three are privacy for the actual user message, none of these three are
protected by DTLS. They are sent as clear text, because they are protected by DTLS. They are sent as clear text, because they are
part of the SCTP DATA chunk header. part of the SCTP DATA chunk header.
DTLS supports cipher suites that contain a NULL cipher algorithm.
Negotiating a NULL cipher algorithm will not provide communications
privacy for applications and will not provide privacy for user
messages.
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Carsten Hohendorf, Alfred Hoenes, Daniel The authors wish to thank Anna Brunstrom, Lars Eggert, Gorry
Mentz, Ian Goldberg, Anna Brunstrom, Stefan Lindskog, and Gorry Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan
Fairhurst for their invaluable comments. Lindskog, Daniel Mentz, and Sean Turner for their invaluable
comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
skipping to change at page 9, line 10 skipping to change at page 9, line 35
RFC 3436, December 2002. RFC 3436, December 2002.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP) Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061, Dynamic Address Reconfiguration", RFC 5061,
September 2007. September 2007.
Authors' Addresses Authors' Addresses
Michael Tuexen Michael Tuexen
Muenster Univ. of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Robin Seggelmann Robin Seggelmann
Muenster Univ. of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: seggelmann@fh-muenster.de Email: seggelmann@fh-muenster.de
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Email: ekr@networkresonance.com Email: ekr@networkresonance.com
 End of changes. 31 change blocks. 
52 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/