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

[Michael Tuexen <[e-mail]>]

> On 28. May 2019, at 16:09, Nagesh shamnur <[e-mail]> wrote:
> 
> 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.
Hi Nagesh,

thanks for providing feedback and sorry for the late response.
See my comments in-line.

Best regards
Michael

>  
> 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.
I don't consider them contradicting. The RANDOM parameter is defined in a way to
handle random numbers of arbitrary size. The current usage of this parameter in
this document is for 32 byte random numbers. So this is a special case.

This allows us to use this parameter in the future also for random numbers of other
sizes.
>  
> 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..
The receiver of a CHUNKS parameter has to ensure that it sends listed chunks only
in an authenticated way. If the does not know a listed chunk type, it will not send
it and therefore no action is really required.

For a clarification, one could add such a sentence. But it is an editorial thing in
my view.
>  
> 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.
You use this error cause when receiving an AUTH chunk using an HMAC Identifier you don't
support. This is only one value you need to support.
> 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.
Whether user data transfer can happen or not depends on whether the DATA and or SACK
chunks are requested to the authenticated. You might only request the authentication
of control chunks like ASCONF/ASCONF-ACK.

The API defined in 6458 allows the application to figure out
* if SCTP AUTH support has been negotiated successfully
* which chunks are required to be authenticated.

So it is easy for the application to ensure that the required configuration has 
been made and can continue or abort the communication.
>                 
>                 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.
Not sure what you mean by "as given".

The concatenation has to happen in the sequence:
* The RANDOM parameter first,
* followed by the CHUNKS parameter, if present,
* and finally the HMAC-ALGO

It does not matter in which sequence the parameters occur in the packet.

I think this is covered by the text in the RFC, but it could be clearer. If you prefer
we can discuss an improved text and file an editorial errata.
> 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
It should not matter in which sequence the parameters are in the packet. So no need to
specify that.
>                 
>                 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.
The order in which the parameters are in the INIT/INIT-ACK is is not relevant.
>                 
> 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.
When RFC 4895 was written, RFC 5061 didn't exist.

The negotiation of SCTP AUTH support is based on the inclusion of the RANDOM and
HMAC-ALGO parameter in the INIT/INIT-ACK.

If you support RFC 5061, you can add SCTP-AUTH to the list of supported chunks,
but that is not necessary. FreeBSD does this, since I think it is more consistent,
but that is not required.

Best regards
Michael
>                 
> 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