Re: [tsvwg] Ambiguities in RFC 4895: Auth chunks for SCTP

[Nagesh shamnur <[e-mail]>]

Dear All,
                Any thoughts on the below mail regarding SCTP RFC 4895 issues?

Regards,
Nagesh S


From: Nagesh shamnur
Sent: 28 May 2019 19:39
To: '[e-mail]' <[e-mail]>
Cc: Ashutosh prakash <[e-mail]>
Subject: Ambiguities in RFC 4895: Auth chunks for SCTP

Hi Group,
                Greetings. While going the RFC 4895: Auth chunks for SCTP, I found there are some discrepancies which might have been encountered by everyone who have implemented this RFC. So, for the benefit of all, I have listed all the issues which I found has problem and how to address these issues. Request all to check and provide your feedback on the same.
                Considering the count, I feel, it calls for a bis document.

Issue-1:
--------
Type: Technical

3.1. Random Parameter (RANDOM)

Issue text:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8002      | Parameter Length                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                                                                                                        |
\                         Random Number                                                                             /
/                                                                                   +-------------------------------\
|                                                                                  | Padding                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Random Number: n bytes (unsigned integer)
                This value represents an arbitrary Random Number in network byte
                order.

Modified to:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8002      | Parameter Length                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                                                                                                        |
\                                                            Random Number (32 bytes)                    /
/                                                                                                                                        \
|                                                                                                                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Random Number: 32 bytes (unsigned integer)
                This value represents a 32 bytes of Random Number in network byte
                order.

Notes:
                The parameter random in the section 3.1 mentions that the length of
                the random parameter is of variable length and so padding bytes are
                required, whereas in section 6, it clearly says that the length of
                the random parameter needs to be exactly 32 bytes. Both the sections
                are contradicting each other and hence needs to be synchronized.

Issue-2:
--------
Type: Technical

Handling of invalid or unsupported chunks

Issue text:
                RFC 4895 doesn't explain the handling of invalid or unsupported chunks.
                which can be received in the Chunk List Parameter (CHUNKS) (sec 3.2).

Modified to:
                While handling the parameter Chunk List Parameter (CHUNKS), if a
                chunk type is unknown or unrecognized chunk, then the receiver
                MUST ignore this chunk and don't need to add it to AUTH chunk list.

Notes:
                Since these chunks are unrecognized chunks, the local node would
                not send these chunks to peer and hence situation doesn't arise
                for sending these chunks in an authenticated way to peer node.
                It is better to be present in the RFC explicitly stating the action
                to be taken, when such a case arises.

Issue-3:
--------
Type: Technical

4.1. Unsupported HMAC Identifier Error Cause

Issue text:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code = 0x0105                   | Cause Length = 6                                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Identifier                             | Padding                                                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Modified to:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code = 0x0105                     | Cause Length = 6                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Identifier 1                           | HMAC Identifier 2                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                                                                                                         /
\                                                                        ...                                                            \
/                                                                                                                                        /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Identifier n                         | Padding                                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Notes:
                Though currently only 2 HMAC algorithms are supported SHA-1 and SHA-256,
                but for extensibility, in future new HMAC algorithms might be registered.
                In such case, the current packet format, doesn't support such an
                extension.

                Also, even when only 2 HMAC algorithms (SHA-1 and SHA-256) is currently
                supported, sec 3.3 (HMAC-ALGO) still supports more than 2 identifiers,
                the same format can be even extended to unsupported HMAC Identifier Error
                cause.

Issue-4:
--------
Type: Technical

 AUTH negotiation Procedure

Issue text:
                Authenticated chunks negotiation sub-section is not present, due to
                which negotiation procedure is not well explained and documented thus
                leading to ambiguities in association states between local and remote
                nodes.

Modified to:
                Need to add a sub-section "Authenticated chunks negotiation" as a part
                of section 6 which explains the AUTH negotiation procedure.

Notes:
                If the local node supports AUTH and peer doesn't support AUTH, then
                the AUTH related parameters sent in INIT by local node will be ignored
                by peer node since the upper 2 bits for AUTH related parameters is 10
                which as per RFC 4960, needs to ignore and continue processing with other
                parameters in the INIT/INIT-ACK chunk.

                Eventually association would get established but meaningful data transfer
                wouldn't happen since one endpoint would be expecting data in an
                authenticated way but the other endpoint would be sending the in un-AUTH
                mode, resulting in association getting closed eventually.

                Presence of this sub-section is required, absence of this sub-section
                is leading to ambiguity with respect to association capability at local
                and remote node (one side will be AUTH enabled and other side isn't). Also
                both the endpoints of the association should know this by the time association
                establishment procedure is completed and thus both sides needs to switch
                to non-AUTH mode for compatibility.

Issue-5:
--------
Type: Editorial

Order of concatenation of parameters to form byte vectors

Issue text:
                The RANDOM parameter, the CHUNKS parameter, and the HMAC-ALGO
                parameter sent by each endpoint are concatenated as byte vectors.

Modified to:
                The RANDOM parameter, the CHUNKS parameter, and the HMAC-ALGO
                parameter sent by each endpoint are concatenated as byte vectors in
                the same order as given.

Notes:
                Section 6.1: Establishment of an Association Shared Key though explains
                that the creation of key vectors by appending RANDOM, chunks parameter
                and HMAC-ALGO parameter which is sent by each endpoint. But it doesn't
                explicitly states the order in which the same needs to be encoded. Though
                all the implantations are encoding the same in the order of the text in the
                RFC, it is thus better to state it explicitly to avoid different
                interpretations by the implementers

                Subsequent paragraph mentions the order of concatenation of shared key,
                shorter key vector and larger key vector, but it doesn't clearly mandates
                the encoding order for parameter to generate key vector thus making room
                for discrepancies.

Issue-6:
--------
Type: Technical

Inclusion and handling of EXTENSION parameter as defined in RFC 5061

Issue text:
                The current RFC 4895 doesn't mandates the sending and processing of
                EXTENSION parameter (RFC 5061 sec 4.2.7).

Modified to:
                Add the requirement to send and receive EXTENSION parameter in
                INIT/INIT-ACK chunk, if endpoints requires AUTH to be supported.

Notes:
                The endpoint supporting both RFC 4895 and RFC 5061 send EXTENSION
                parameter when it sends INIT/INIT-ACK and also expects peer to send
                the same. lksctp has mandated such a behavior. So, to ensure
                inter-operability, it was discussed in mailing list in the past to
                include this parameter, when supporting only AUTH to ensure
                inter-operability.
                https://sourceforge.net/p/lksctp/mailman/message/20743069/

Regards,
Nagesh S