Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
RFC 4895
|
| Document |
Type |
|
RFC - Proposed Standard
(August 2007; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4895 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Magnus Westerlund
|
|
Send notices to |
|
mramalho@cisco.com, qxie1@email.mot.com
|
Network Working Group M. Tuexen
Request for Comments: 4895 Muenster Univ. of Applied Sciences
Category: Standards Track R. Stewart
P. Lei
Cisco Systems, Inc.
E. Rescorla
RTFM, Inc.
August 2007
Authenticated Chunks for
the Stream Control Transmission Protocol (SCTP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document describes a new chunk type, several parameters, and
procedures for the Stream Control Transmission Protocol (SCTP). This
new chunk type can be used to authenticate SCTP chunks by using
shared keys between the sender and receiver. The new parameters are
used to establish the shared keys.
Tuexen, et al. Standards Track [Page 1]
RFC 4895 SCTP Authentication Chunk August 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Parameter Types . . . . . . . . . . . . . . . . . . . . . 4
3.1. Random Parameter (RANDOM) . . . . . . . . . . . . . . . . 4
3.2. Chunk List Parameter (CHUNKS) . . . . . . . . . . . . . . 5
3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) . . . . . . 6
4. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Unsupported HMAC Identifier Error Cause . . . . . . . . . 7
5. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Authentication Chunk (AUTH) . . . . . . . . . . . . . . . 8
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Establishment of an Association Shared Key . . . . . . . . 10
6.2. Sending Authenticated Chunks . . . . . . . . . . . . . . . 11
6.3. Receiving Authenticated Chunks . . . . . . . . . . . . . . 12
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 15
8.2. Three New Parameter Types . . . . . . . . . . . . . . . . 15
8.3. A New Error Cause . . . . . . . . . . . . . . . . . . . . 15
8.4. A New Table for HMAC Identifiers . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Tuexen, et al. Standards Track [Page 2]
RFC 4895 SCTP Authentication Chunk August 2007
1. Introduction
SCTP uses 32-bit verification tags to protect itself against blind
attackers. These values are not changed during the lifetime of an
SCTP association.
Looking at new SCTP extensions, there is the need to have a method of
proving that an SCTP chunk(s) was really sent by the original peer
that started the association and not by a malicious attacker.
Using Transport Layer Security (TLS), as defined in RFC 3436 [6],
does not help because it only secures SCTP user data.
Therefore, an SCTP extension that provides a mechanism for deriving
shared keys for each association is presented. These association
shared keys are derived from endpoint pair shared keys, which are
configured and might be empty, and data that is exchanged during the
SCTP association setup.
The extension presented in this document allows an SCTP sender to
authenticate chunks using shared keys between the sender and
receiver. The receiver can then verify that the chunks are sent from
the sender and not from a malicious attacker (as long as the attacker
does not know an association shared key).
The extension described in this document places the result of a
Hashed Message Authentication Code (HMAC) computation before the data
covered by that computation. Placing it at the end of the packet
would have required placing a control chunk after DATA chunks in case
Show full document text