Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
Extracted elements (25)
Requiring ABORT and COOKIE-ECHO chunks to be authenticated prevents attackers from tearing down or restarting associations, but accepting ABORT only in authenticated form may delay detection of peer unavailability, and requiring authenticated COOKIE-ECHO breaks the normal restart procedure for endpoints that don't know the old association shared key.
The AUTH chunk places the HMAC result before the authenticated data (rather than after) because control chunks must precede DATA chunks in SCTP packets, and because the HMAC result is needed to compute the CRC32C checksum in the common SCTP header before the packet can be sent.
The CHUNKS and HMAC-ALGO parameters use upper bits of the parameter type (0x8xxx) so that receivers that do not understand them will ignore the parameter and continue processing, as specified in RFC 2960 Section 3.2.1. The AUTH chunk type (0x0F) upper bits cause receivers to ignore the chunk and silently discard all following chunks if not understood.
An SCTP endpoint willing to receive or send authenticated chunks MUST send one RANDOM parameter in its INIT or INIT-ACK chunk containing a 32-byte Random Number. If the Random Number is not 32 bytes, the association MUST be aborted with a 'Protocol Violation' error cause.
Each SCTP endpoint MUST include an HMAC-ALGO parameter in the INIT and INIT-ACK. The receiver SHOULD use the first listed algorithm it supports. An endpoint MUST NOT change the HMAC-ALGO parameters during the lifetime of the endpoint.
Every endpoint supporting SCTP chunk authentication MUST support the HMAC based on the SHA-1 algorithm (HMAC Identifier 1) and MUST include it in the HMAC-ALGO parameter.
If the endpoint has no endpoint pair shared key for the peer, it MUST use Shared Key Identifier zero with an empty endpoint pair shared key.
If the receiver's HMAC verification fails (computed HMAC does not match the HMAC field), all chunks following the AUTH chunk MUST be silently discarded.
The AUTH chunk MUST NOT appear more than once in an SCTP packet. All control and data chunks placed after the AUTH chunk are authenticated; chunks placed before it are not.
The chunk types for INIT, INIT-ACK, SHUTDOWN-COMPLETE, and AUTH MUST NOT be listed in the CHUNKS parameter. If a CHUNKS parameter is received containing these types, they MUST be ignored.
The cookie contained in an INIT-ACK chunk and in a COOKIE-ECHO chunk MUST NOT contain any endpoint pair shared keys.
The receiver MUST silently discard chunks from its required-authenticated list if they are not placed after an AUTH chunk. If an unsupported HMAC algorithm is indicated in the AUTH chunk, the AUTH chunk and all following chunks MUST be discarded and an ERROR chunk SHOULD be sent.
To send chunks in an authenticated way, the sender MUST include those chunks after an AUTH chunk, requiring bundling. The MAC is computed over the AUTH chunk (with HMAC field set to zero) followed by all subsequent chunks in the packet, including their padding.
When a packet arrives with AUTH as first chunk and COOKIE-ECHO as second chunk and no STCB exists, the receiver MUST authenticate using parameters from the COOKIE-ECHO chunk. If authentication succeeds, COOKIE-ECHO and all following chunks MUST be processed.
Association shared keys are derived by concatenating the endpoint pair shared key with the two key vectors (from RANDOM, CHUNKS, and HMAC-ALGO parameters), ordered by numerical value of the key vectors in network byte order. Padding is removed before concatenation.
The CHUNKS parameter (type 0x8003) specifies which chunk types the peer is required to send only in authenticated form. It must be included once in INIT or INIT-ACK if the sender wants to receive authenticated chunks, and has a maximum length of 260 bytes.
The HMAC-ALGO parameter (type 0x8004) lists the HMAC Identifiers the sender requests the peer to use, ordered by sender preference. It must be included once in INIT or INIT-ACK if the sender wants to send or receive authenticated chunks.
The RANDOM parameter (type 0x8002) carries a random number used during association setup to derive shared keys. It must be included once in INIT or INIT-ACK if the sender wants to send or receive authenticated chunks, and must contain a 32-byte Random Number.
The Unsupported HMAC Identifier error cause (cause code 0x0105) is sent when an AUTH chunk is received with an HMAC Identifier that was not specified by the receiver during association setup. Its fixed length is 6 bytes, with 2 bytes of padding.
RFC 4895 registers: AUTH chunk type (value 15) in SCTP CHUNK TYPES; RANDOM (0x8002), CHUNKS (0x8003), and HMAC-ALGO (0x8004) in SCTP INIT and INIT ACK Chunk Parameter Types; Unsupported HMAC Identifier (0x0105) in SCTP CAUSE CODES; and a new HMAC IDENTIFIERS table with values 0 (Reserved), 1 (SHA-1), 2 (Reserved), 3 (SHA-256).
Each endpoint presenting multiple algorithms in HMAC-ALGO must be prepared for the peer to use the weakest algorithm listed. If an endpoint pair uses non-NULL shared keys but still accepts a NULL key, an attacker who captured the initial handshake can inject authenticated chunks using the NULL key.
The extension does not itself prevent replay attacks; it relies on SCTP's existing duplicate chunk handling mechanism. A separate shared key is used per association to handle replay attacks across multiple associations.
Without endpoint pair shared keys, the extension only protects against modification or injection by attackers who did not capture the initial handshake. With endpoint pair shared keys, even a man-in-the-middle who intercepts the initial exchange cannot inject authenticated chunks.
The AUTH chunk (type 0x0F) wire format contains: 1-byte Type (0x0F), 1-byte Flags (must be zero), 2-byte Length (HMAC length + 8), 2-byte Shared Key Identifier, 2-byte HMAC Identifier, variable-length HMAC field, and 0-3 bytes zero padding for 32-bit alignment.
The RANDOM parameter wire format has a 2-byte Parameter Type (0x8002), 2-byte Parameter Length (Random Number length + 4), a variable-length Random Number field, and 0-3 bytes of zero padding to achieve 32-bit alignment.