draft-ietf-tsvwg-sctp-auth-01.txt   draft-ietf-tsvwg-sctp-auth-02.txt 
Network Working Group M. Tuexen Network Working Group M. Tuexen
Internet-Draft Muenster Univ. of Applied Sciences Internet-Draft Muenster Univ. of Applied Sciences
Expires: April 18, 2006 R. Stewart Expires: September 7, 2006 R. Stewart
P. Lei P. Lei
Cisco Systems, Inc. Cisco Systems, Inc.
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
October 15, 2005 March 6, 2006
Authenticated Chunks for Stream Control Transmission Protocol (SCTP) Authenticated Chunks for Stream Control Transmission Protocol (SCTP)
draft-ietf-tsvwg-sctp-auth-01.txt draft-ietf-tsvwg-sctp-auth-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes a new chunk type, several parameters and This document describes a new chunk type, several parameters and
procedures for SCTP. This new chunk type can be used to authenticate procedures for SCTP. This new chunk type can be used to authenticate
SCTP chunks by using shared keys between the sender and receiver. SCTP chunks by using shared keys between the sender and receiver.
The new parameters are used to establish the shared keys. The new parameters are used to establish the shared keys.
Table of Contents Table of Contents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
3.1. Random Parameter (RANDOM) . . . . . . . . . . . . . . . . 4 3.1. Random Parameter (RANDOM) . . . . . . . . . . . . . . . . 4
3.2. Chunk List Parameter (CHUNKS) . . . . . . . . . . . . . . 4 3.2. Chunk List Parameter (CHUNKS) . . . . . . . . . . . . . . 4
3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) . . . . . . 5 3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) . . . . . . 5
4. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 7 4. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Unsupported HMAC Identifier error cause . . . . . . . . . 7 4.1. Unsupported HMAC Identifier error cause . . . . . . . . . 7
5. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 7 5. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Authentication Chunk (AUTH) . . . . . . . . . . . . . . . 8 5.1. Authentication Chunk (AUTH) . . . . . . . . . . . . . . . 8
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Establishment of an association shared key . . . . . . . . 9 6.1. Establishment of an association shared key . . . . . . . . 9
6.2. Sending authenticated chunks . . . . . . . . . . . . . . . 10 6.2. Sending authenticated chunks . . . . . . . . . . . . . . . 10
6.3. Receiving authenticated chunks . . . . . . . . . . . . . . 10 6.3. Receiving authenticated chunks . . . . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . . 13 11. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
SCTP uses 32 bit verification tags to protect itself against blind SCTP uses 32 bit verification tags to protect itself against blind
attackers. These values are not changed during the lifetime of an attackers. These values are not changed during the lifetime of an
SCTP association. SCTP association.
Looking at new SCTP extensions there is the need to have a method of 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 proving that an SCTP chunk(s) was really sent by the original peer
that started the association and not by a malicious attacker. that started the association and not by a malicious attacker.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
+----------------+------------------------------------------------+ +----------------+------------------------------------------------+
| 0x8002 | Random Parameter (RANDOM) | | 0x8002 | Random Parameter (RANDOM) |
| 0x8003 | Chunk List Parameter (CHUNKS) | | 0x8003 | Chunk List Parameter (CHUNKS) |
| 0x8004 | Requested HMAC Algorithm Parameter (HMAC-ALGO) | | 0x8004 | Requested HMAC Algorithm Parameter (HMAC-ALGO) |
+----------------+------------------------------------------------+ +----------------+------------------------------------------------+
Table 1 Table 1
It should be noted that the parameter format requires the receiver to It should be noted that the parameter format requires the receiver to
ignore the parameter and continue processing if it is not understood. ignore the parameter and continue processing if it is not understood.
This is accomplished as described in RFC2960 [4] section 3.2.1. by This is accomplished as described in RFC2960 [4] section 3.2.1. by
the use of the upper bit of the parameter type. the use of the upper bits of the parameter type.
3.1. Random Parameter (RANDOM) 3.1. Random Parameter (RANDOM)
This parameter is used to carry an arbitrary length random number. This parameter is used to carry an arbitrary length random number.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8002 | Parameter Length | | Parameter Type = 0x8002 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 36 skipping to change at page 5, line 36
Chunk Type n: 1 byte (unsigned integer) Chunk Type n: 1 byte (unsigned integer)
Each Chunk Type listed is required to be authenticated when sent Each Chunk Type listed is required to be authenticated when sent
by the peer. by the peer.
The CHUNKS parameter MUST be included once in the INIT or INIT-ACK The CHUNKS parameter MUST be included once in the INIT or INIT-ACK
chunk if the sender wants to receive authenticated chunks. Its chunk if the sender wants to receive authenticated chunks. Its
maximum length is 260 bytes. maximum length is 260 bytes.
The chunk types for INIT, INIT-ACK, SHUTDOWN-COMPLETE and AUTH chunks The chunk types for INIT, INIT-ACK, SHUTDOWN-COMPLETE and AUTH chunks
MUST not be listed in the CHUNKS parameter. However, if a CHUNKS MUST NOT be listed in the CHUNKS parameter. However, if a CHUNKS
parameter is received then the types for INIT, INIT-ACK, SHUTDOWN- parameter is received then the types for INIT, INIT-ACK, SHUTDOWN-
COMPLETE and AUTH chunks MUST be ignored. COMPLETE and AUTH chunks MUST be ignored.
3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) 3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO)
This parameter is used to list the HMAC identifiers the peer has to This parameter is used to list the HMAC identifiers the peer MUST
use. use.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8004 | Parameter Length | | Parameter Type = 0x8004 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Identifier 1 | HMAC Identifier 2 | | HMAC Identifier 1 | HMAC Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
skipping to change at page 6, line 25 skipping to change at page 6, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Identifier n | Padding | | HMAC Identifier n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Figure 3
Parameter Type: 2 bytes (unsigned integer) Parameter Type: 2 bytes (unsigned integer)
This value MUST be set to 0x8004. This value MUST be set to 0x8004.
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This value is the length of the number of HMAC identifiers times 2 This value is the length of the number of HMAC identifiers
plus 4. multiplied by 2 plus 4.
HMAC Identifier n: 2 bytes (unsigned integer) HMAC Identifier n: 2 bytes (unsigned integer)
The values is an HMAC Identifier which should be used. The values The values is an HMAC Identifier which should be used. The values
are listed by priority. Highest priority first. are listed by priority. Highest priority first.
The HMAC-ALGO parameter MUST be included once in the INIT or INIT-ACK The HMAC-ALGO parameter MUST be included once in the INIT or INIT-ACK
chunk if the sender wants to send or receive authenticated chunks. chunk if the sender wants to send or receive authenticated chunks.
The following Table 2 shows the currently defined values for HMAC The following Table 2 shows the currently defined values for HMAC
identifiers. identifiers.
+-----------------+--------------------------+ +-----------------+--------------------------+
| HMAC Identifier | Message Digest Algorithm | | HMAC Identifier | Message Digest Algorithm |
+-----------------+--------------------------+ +-----------------+--------------------------+
| 0 | Reserved | | 0 | Reserved |
| 1 | SHA-1 defined in [7] | | 1 | SHA-1 defined in [6] |
| 2 | MD-5 defined in [1] | | 2 | MD-5 defined in [1] |
+-----------------+--------------------------+ +-----------------+--------------------------+
Table 2 Table 2
Every endpoint supporting SCTP chunk authentication MUST support the Every endpoint supporting SCTP chunk authentication MUST support the
HMAC based on the SHA-1 algorithm. HMAC based on the SHA-1 algorithm.
4. New Error Cause 4. New Error Cause
skipping to change at page 8, line 8 skipping to change at page 8, line 8
This value is the HMAC Identifier which is not supported. This value is the HMAC Identifier which is not supported.
5. New Chunk Type 5. New Chunk Type
This section defines the new chunk type that will be used to This section defines the new chunk type that will be used to
authenticate chunks. Table 4 illustrates the new chunk type. authenticate chunks. Table 4 illustrates the new chunk type.
+------------+-----------------------------+ +------------+-----------------------------+
| Chunk Type | Chunk Name | | Chunk Type | Chunk Name |
+------------+-----------------------------+ +------------+-----------------------------+
| 0x83 | Authentication Chunk (AUTH) | | 0x0F | Authentication Chunk (AUTH) |
+------------+-----------------------------+ +------------+-----------------------------+
Table 4 Table 4
It should be noted that the AUTH-chunk format requires the receiver It should be noted that the AUTH-chunk format requires the receiver
to ignore the chunk if it is not understood and silently discard all to ignore the chunk if it is not understood and silently discard all
chunks that follow. This is accomplished as described in RFC2960 [4] chunks that follow. This is accomplished as described in RFC2960 [4]
section 3.2. by the use of the upper bit of the chunk type. section 3.2. by the use of the upper bits of the chunk type.
5.1. Authentication Chunk (AUTH) 5.1. Authentication Chunk (AUTH)
This chunk is used to hold the result of the HMAC calculation. This chunk is used to hold the result of the HMAC calculation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x83 | Flags=0 | Length | | Type = 0x0F | Flags=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Key Identifier | HMAC Identifier | | Shared Key Identifier | HMAC Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
\ HMAC / \ HMAC /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Figure 5
Type: 1 byte (unsigned integer) Type: 1 byte (unsigned integer)
This value MUST be set to 0x83 for all AUTH-chunks. This value MUST be set to 0x0F for all AUTH-chunks.
Flags: 1 byte (unsigned integer) Flags: 1 byte (unsigned integer)
Set to zero on transmit and ignored on receipt. Set to zero on transmit and ignored on receipt.
Length: 2 bytes (unsigned integer) Length: 2 bytes (unsigned integer)
This value holds the length of the HMAC plus 8. This value holds the length of the HMAC plus 8.
Shared Key Identifier: 2 bytes (unsigned integer) Shared Key Identifier: 2 bytes (unsigned integer)
This value describes which endpoint pair shared key is used. This value describes which endpoint pair shared key is used.
HMAC Identifier: 2 bytes (unsigned integer) HMAC Identifier: 2 bytes (unsigned integer)
This value describes which message digest is being used. Table 2 This value describes which message digest is being used. Table 2
shows the currently defined values. shows the currently defined values.
HMAC: n bytes (unsigned integer) HMAC: n bytes (unsigned integer)
This hold the result of the HMAC calculation. This hold the result of the HMAC calculation.
The control chunk AUTH can appear at most once in an SCTP packet. The control chunk AUTH MUST NOT appear more than once in an SCTP
All control and data chunks which are placed after the AUTH chunk in packet. All control and data chunks which are placed after the AUTH
the packet are sent in an authenticated way. Those chunks placed in chunk in the packet are sent in an authenticated way. Those chunks
a packet before the AUTH chunk are not authenticated. Please note placed in a packet before the AUTH chunk are not authenticated.
that DATA chunks can not appear before control chunks in an SCTP Please note that DATA chunks can not appear before control chunks in
packet. an SCTP packet.
6. Procedures 6. Procedures
6.1. Establishment of an association shared key 6.1. Establishment of an association shared key
An SCTP endpoint willing to receive or send authenticated chunks MUST An SCTP endpoint willing to receive or send authenticated chunks MUST
send one RANDOM parameter in its INIT or INIT-ACK chunk. The RANDOM send one RANDOM parameter in its INIT or INIT-ACK chunk. The RANDOM
parameter SHOULD contain a 32 byte random number. In case of INIT parameter SHOULD contain a 32 byte random number. In case of INIT
collision, the rules governing the handling of this random number collision, the rules governing the handling of this random number
follow the same pattern as those for the Verification Tag, as follow the same pattern as those for the Verification Tag, as
skipping to change at page 9, line 39 skipping to change at page 9, line 39
received in an authenticated way. This list is included in the INIT received in an authenticated way. This list is included in the INIT
and INIT-ACK and MAY be omitted if it is empty. Since this list does and INIT-ACK and MAY be omitted if it is empty. Since this list does
not change during the lifetime of there is no problem in case of INIT not change during the lifetime of there is no problem in case of INIT
collision. collision.
Each SCTP endpoint MUST include in the INIT and INIT-ACK a HMAC-ALGO Each SCTP endpoint MUST include in the INIT and INIT-ACK a HMAC-ALGO
parameter containing a list of HMAC Identifiers it requests the peer parameter containing a list of HMAC Identifiers it requests the peer
to use. The receiver of a HMAC-ALGO parameter SHOULD use the first to use. The receiver of a HMAC-ALGO parameter SHOULD use the first
listed algorithm it supports. The HMAC algorithm based on SHA-1 MUST listed algorithm it supports. The HMAC algorithm based on SHA-1 MUST
be supported and included in the HMAC-ALGO parameter. An SCTP be supported and included in the HMAC-ALGO parameter. An SCTP
endpoint MUST not change the parameters listed in the HMAC-ALGO endpoint MUST NOT change the parameters listed in the HMAC-ALGO
parameter during the lifetime of the endpoint. parameter during the lifetime of the endpoint.
Both endpoints of an association MAY have endpoint pair shared keys Both endpoints of an association MAY have endpoint pair shared keys
which are byte vectors and preconfigured or established by another which are byte vectors and preconfigured or established by another
mechanism. They are identified by the shared key identifier. If no mechanism. They are identified by the shared key identifier. If no
endpoint pair shared keys are preconfigured or established by another endpoint pair shared keys are preconfigured or established by another
mechanism an empty byte vector is used. mechanism an empty byte vector is used.
From these endpoint pair shared keys the association shared keys are From these endpoint pair shared keys the association shared keys are
computed by concatenating the endpoint pair shared key with the computed by concatenating the endpoint pair shared key with the
random numbers exchanged in the INIT and INIT-ACK. This is performed random numbers exchanged in the INIT and INIT-ACK. This is performed
by selecting the smaller random number and concatenating it to the by selecting the smaller random number value and concatenating it to
endpoint pair shared key. Then concatenating the larger of the the endpoint pair shared key, and then concatenating the larger of
random numbers to that. If both random numbers are equal they may be the random number values to that. If both random numbers are equal,
concatenated to the endpoint pair key in any order. The then the concatenation order is the random number with the shorter
concatenation is performed on byte vectors representing all numbers length, followed by the endpoint shared key, followed by the random
in network byte order. The result is the association shared key. number with the longer length. If the random number lengths are the
same, then they may be concatenated to the endpoint pair key in any
order. The concatenation is performed on byte vectors representing
all numbers in network byte order. The result is the association
shared key.
6.2. Sending authenticated chunks 6.2. Sending authenticated chunks
Both endpoints MUST send all those chunks authenticated where this Endpoints MUST send all requested chunks authenticated where this has
has been requested by the peer. The other chunks MAY be sent been requested by the peer. The other chunks MAY be sent
authenticated or not. If endpoint pair shared keys are used one of authenticated or not. If endpoint pair shared keys are used, one of
them has to be selected for authentication. them MUST be selected for authentication.
To send chunks in an authenticated way, the sender has to include To send chunks in an authenticated way, the sender MUST include these
these chunks after an AUTH chunk. This means that a sender MUST chunks after an AUTH chunk. This means that a sender MUST bundle
bundle chunks in order to authenticate them. chunks in order to authenticate them.
The sender MUST calculate the MAC using the hash function H as The sender MUST calculate the MAC using the hash function H as
described by the MAC Identifier and the shared association key K described by the MAC Identifier and the shared association key K
based on the endpoint pair shared key described by the shared key based on the endpoint pair shared key described by the shared key
identifier. The 'data' used for the computation of the AUTH-chunk is identifier. The 'data' used for the computation of the AUTH-chunk is
given by Figure 6 and all chunks that are placed after the AUTH chunk given by Figure 6 and all chunks that are placed after the AUTH chunk
in the SCTP packet. RFC2104 [2] can be used as a guideline for in the SCTP packet. RFC2104 [2] can be used as a guideline for
generating the MAC. generating the MAC.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x83 | Flags=0 | Chunk Length | | Type = 0x0F | Flags=0 | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Key Identifier | HMAC Identifier | | Shared Key Identifier | HMAC Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
\ 0 / \ 0 /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Figure 6
Please note that all fields are in network byte order and that the Please note that all fields are in network byte order and that the
field which will contain the complete HMAC is filled with zeroes. field which will contain the complete HMAC is filled with zeroes.
The length of the field shown as 0 is the length of the HMAC The length of the field shown as 0 is the length of the HMAC
described by the HMAC Identifier. The padding of all chunks being described by the HMAC Identifier. The padding of all chunks being
authenticated has to be included in the HMAC computation. authenticated MUST be included in the HMAC computation.
The sender fills the HMAC into the HMAC field and sends the packet. The sender fills the HMAC into the HMAC field and sends the packet.
6.3. Receiving authenticated chunks 6.3. Receiving authenticated chunks
The receiver has a list of chunk types which it expects to be The receiver has a list of chunk types which it expects to be
received only after an AUTH-chunk. This list has been sent to the received only after an AUTH-chunk. This list has been sent to the
peer during the association setup. It MUST silently discard these peer during the association setup. It MUST silently discard these
chunks if they are not placed after an AUTH chunk in the packet. chunks if they are not placed after an AUTH chunk in the packet.
The receiver MUST use the HMAC algorithm indicated in the HMAC The receiver MUST use the HMAC algorithm indicated in the HMAC
Identifier field. If this algorithm is not known the AUTH chunk and Identifier field. If this algorithm was not specified by the
all chunks after it MUST be discarded and an ERROR chunk SHOULD be receiver in the HMAC-ALGO parameter in the INIT or INIT-ACK chunk
sent with the error cause defined in Section 4.1. during association setup, the AUTH chunk and all chunks after it MUST
be discarded and an ERROR chunk SHOULD be sent with the error cause
defined in Section 4.1.
If the endpoints has no endpoint pair shared key for the peer it MUST If the endpoint has no endpoint pair shared key for the peer, it MUST
us an empty endpoint pair shared key regardless which Shared Key use an empty endpoint pair shared key regardless which Shared Key
Identifier is present in the AUTH chunk. If the endpoint has at Identifier is present in the AUTH chunk. If the endpoint has at
least one endpoint pair shared key for the peer it MUST use the key least one endpoint pair shared key for the peer, it MUST use the key
specified by the Shared Key Identifier if a key has been configured specified by the Shared Key Identifier if a key has been configured
for that Shared Key Identifier. If no endpoint pair shared key has for that Shared Key Identifier. If no endpoint pair shared key has
been configured for that Shared Key Identifier all authenticated been configured for that Shared Key Identifier, all authenticated
chunks MUST be silently discarded. chunks MUST be silently discarded.
The receiver now performs the same calculation as described for the The receiver now performs the same calculation as described for the
sender based on Figure 6. If the result of the calculation is the sender based on Figure 6. If the result of the calculation is the
same as given in the HMAC field, all chunks following the AUTH chunk same as given in the HMAC field, all chunks following the AUTH chunk
are processed. If the field does not match the result of the are processed. If the field does not match the result of the
calculation all these chunks MUST be silently discarded. calculation, all the chunks following the AUTH chunk MUST be silently
discarded.
It should be noted that if the receiver wants to tear down an It should be noted that if the receiver wants to tear down an
association in an authenticated way only, the handling of malformed association in an authenticated way only, the handling of malformed
packets should be in tune with this. packets should be in tune with this.
It should also be noted that if an endpoints accepts ABORT chunks If the receiver of the packet does not have a TCB when it needs to
only in an authenticated way it may take longer to detect that the process the AUTH chunk, it MUST ignore the AUTH chunk. This applies
peer is no longer available. If an endpoint accepts COOKIE chunks to a packet containing an AUTH chunk as a first chunk and an COOKIE-
only in an authenticated way the restart procedure does not work. ECHO chunk as the second chunk received in the CLOSED state. If the
receiver has a TCB, it MUST process the AUTH chunk as described
above.
It should also be noted that if an endpoint accepts ABORT chunks only
in an authenticated way, it may take longer to detect that the peer
is no longer available. If an endpoint accepts COOKIE chunks only in
an authenticated way, the restart procedure does not work.
7. Examples 7. Examples
This section gives examples of message exchanges for association This section gives examples of message exchanges for association
setup. setup.
The simplest way of using the extension described in this document is The simplest way of using the extension described in this document is
given by the following message exchange. given by the following message exchange.
---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
skipping to change at page 12, line 35 skipping to change at page 12, line 50
8. IANA Considerations 8. IANA Considerations
A chunk type for the AUTH chunk has to be assigned by IANA. It is A chunk type for the AUTH chunk has to be assigned by IANA. It is
suggested to use the value given above. suggested to use the value given above.
Parameter types have to be assigned for the RANDOM, CHUNKS, and HMAC- Parameter types have to be assigned for the RANDOM, CHUNKS, and HMAC-
ALGO parameter by IANA. It is suggested to use the values given ALGO parameter by IANA. It is suggested to use the values given
above. above.
An error cause for the Unsupported HMAC Identifier error cause has to
be assigned. It is suggested to use the value given above.
HMAC Identifiers have to be maintained by IANA. Three initial values HMAC Identifiers have to be maintained by IANA. Three initial values
should be assigned by IANA as described above. should be assigned by IANA as described above.
9. Security Considerations 9. Security Considerations
This section is still incomplete.
If no endpoint pair shared key is used an attacker which captures the If no endpoint pair shared key is used an attacker which captures the
association setup message exchange can later insert arbitrary packets association setup message exchange can later insert arbitrary packets
in an authenticated way. However, if the attacker did not capture in an authenticated way. However, if the attacker did not capture
this initial message exchange he can not successfully inject chunks this initial message exchange he can not successfully inject chunks
which are required to be authenticated. which are required to be authenticated.
If an enpoint pair shared key is used even a true man in the middle If an enpoint pair shared key is used even a true man in the middle
can not inject chunks which are required to be authenticated even if can not inject chunks which are required to be authenticated even if
he intercepts the initial message exchange. he intercepts the initial message exchange.
Because SCTP has already a mechanism built-in that handles the Because SCTP has already a mechanism built-in that handles the
reception of duplicated chunks the presented solution makes use of reception of duplicated chunks the presented solution makes use of
this functionality and does not provide a method to avoid replay this functionality and does not provide a method to avoid replay
attacks by itself. Of course, this only works within each SCTP attacks by itself. Of course, this only works within each SCTP
association. Therefore a separate shared key is used for each SCTP association. Therefore a separate shared key is used for each SCTP
association to handle replay attacks covering multiple SCTP association to handle replay attacks covering multiple SCTP
associations. associations.
10. Acknowledgments 10. Acknowledgments
The authors wish to thank Sascha Grau, Ivan Arias Rodriguez, for his The authors wish to thank Sascha Grau, Ivan Arias Rodriguez, and
invaluable comments. Irene Ruengeler for their invaluable comments.
11. Normative References 11. Normative References
[1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
skipping to change at page 15, line 41 skipping to change at page 16, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 34 change blocks. 
59 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/