AuthInitWithoutChunks.seq - The CHUNKS parameter MAY be omitted in the INIT or INIT-ACK chunk if it is empty
To verify that the CHUNKS parameter MAY be omitted in the INIT or
INIT-ACK chunk if it is empty. The SCTP endpoint will still has the
capable to receive or send authenticated chunks.
./AuthInitWithoutChunks.seq [-tooloption ...] -pkt ./AuthInitWithoutChunks.def
-tooloption : v6eval tool option
See Also: ../common/STD_PKT_COMMON.def
../common/SCTP_COMMON.def
Association is not established between endpoint A and B. Arrange
data in endpoint A such that INIT chunk without CHUNKS parameter
but want to sent packet in authenticated way is sent to endpoint B.
Endpoint A Endpoint B ULP
(CLOSED) (CLOSED)
INIT ------------------>
(without CHUNKS parameter)
<------------------ INIT-ACK
(with AUTH capable)
COOKIE-ECHO ------------------>
<------------------ COOKIE-ACK
AUTH ------------------>
(with Unsupported HMAC Identifier)
<------------------ ERROR
(Unsupported HMAC Identifier Error Cause)
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to B. Send INIT
message containing RANDOM Parameter and HMAC-ALGO Parameter, but
without CHUNKS parameter.
2. Check A: Association is established between endpoint A and B
with AUTH capable.
3. Send AUTH chunk from endpoint A to B with Unsupported HMAC
Identifier.
4. Check B: ERROR should be received at endpoint A. And Error
cause in ERROR is set to "Unsupported HMAC Identifier".
None
RFC 4895
6.1. Establishment of an Association Shared Key
An SCTP endpoint willing to receive or send authenticated chunks MUST
send one RANDOM parameter in its INIT or INIT-ACK chunk. The RANDOM
parameter MUST contain a 32-byte Random Number. The Random Number
should be generated in accordance with RFC 4086 [7]. If the Random
Number is not 32 bytes, the association MUST be aborted. The ABORT
chunk SHOULD contain the error cause 'Protocol Violation'. In case
of INIT collision, the rules governing the handling of this Random
Number follow the same pattern as those for the Verification Tag, as
explained in Section 5.2.4 of RFC 2960 [5]. Therefore, each endpoint
knows its own Random Number and the peer's Random Number after the
association has been established.
An SCTP endpoint has a list of chunks it only accepts if they are
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 not change during the lifetime of the SCTP endpoint there is no
problem in case of INIT collision.
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
to use. The receiver of an HMAC-ALGO parameter SHOULD use the first
listed algorithm it supports. The HMAC algorithm based on SHA-1 MUST
be supported and included in the HMAC-ALGO parameter. An SCTP
endpoint MUST NOT change the parameters listed in the HMAC-ALGO
parameter during the lifetime of the endpoint.
Both endpoints of an association MAY have endpoint pair shared keys
that are byte vectors and pre-configured or established by another
mechanism. They are identified by the Shared Key Identifier. For
each endpoint pair shared key, an association shared key is computed.
If there is no endpoint pair shared key, only one association shared
key is computed by using an empty byte vector as the endpoint pair
shared key.
The RANDOM parameter, the CHUNKS parameter, and the HMAC-ALGO
parameter sent by each endpoint are concatenated as byte vectors.
These parameters include the parameter type, parameter length, and
the parameter value, but padding is omitted; all padding MUST be
removed from this concatenation before proceeding with further
computation of keys. Parameters that were not sent are simply
omitted from the concatenation process. The resulting two vectors
are called the two key vectors.
From the endpoint pair shared keys and the key vectors, the
association shared keys are computed. This is performed by selecting
the numerically smaller key vector and concatenating it to the
endpoint pair shared key, and then concatenating the numerically
larger key vector to that. If the key vectors are equal as numbers
but differ in length, then the concatenation order is the endpoint
shared key, followed by the shorter key vector, followed by the
longer key vector. Otherwise, the key vectors are identical, and may
be concatenated to the endpoint pair key in any order. The
concatenation is performed on byte vectors, and all numerical
comparisons use network byte order to convert the key vectors to a
number. The result of the concatenation is the association shared
key.