[tsvwg] Comments on draft-tuexen-tsvwg-rfc4895-bis-04

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed draft-tuexen-tsvwg-rfc4895-bis-04 and have some comments:


General:



So an authentication algorithm for SCTP-AUTH should not be required to use HMAC. It appears better to have the algorithms define themselves if they are using HMAC or might be using some other way of deriving the authentication tag. This will require that the algorithms also define a KDF of the input key data if not using HMAC. As in many cases the input shared association key will be longer than the what the algorithm uses.



This specification needs to deprecate the old SHA-1 and SHA-256 algorithms and replace them with new algorithms that uses another key-derivation so that we get directional keys depending on sending and receiving. I would think the most straight forward change here is to derive one send key and one receive key. Where the send key is derived using first the vector that contains the material oneself sent in init, followed by the peers. An the receive key is reverse order of the these vectors. As long as one first check that the peers random values are not identical this appears to generate unique input data for the key derivation function based on direction. But, someone more knowledgeable in the finer point of crytpo should check my assumptions.  Alternatively, one need to have a role label or something that is included to derive two different keys. I would note that maybe is desired as that would avoid API changes.



The next question is what to do with mandatory to support interoperability point. The current HMAC-SHA1 is broken due to the directionality issue, so I think going forward one should not be required to support that. So the question is what to support instead?



The replay attack potential we need to discuss also. If one only want to prevent DATA replay after TSN wraps, i.e. when 2^32 bytes having been sent, then one can include a strong recommendation for rekeying. However, I think we should discuss if one would like to fix this for all chunks by actually include a sequence number (for example 16 bits) in the SCTP-AUTH chunk, and run the MAC over an extended version of that field (64-96  bits in total) so that SCTP-AUTH prevent replay of really old SCTP-AUTH chunks as the epoch would not match and give integrity failure.





Detailed comments:



Abstract needs to mention that this obsoletes 4895.



Section 1:



"Using Transport Layer Security (TLS), as defined in RFC 3436<https://www.ietf.org/archive/id/draft-tuexen-tsvwg-rfc4895-bis-04.html#RFC3436> [RFC3436<https://www.ietf.org/archive/id/draft-tuexen-tsvwg-rfc4895-bis-04.html#RFC3436>], does not help because it only secures SCTP user data."



Should likely be updated with reference to RFC 6083 or rather replacement solution.





"Therefore, an SCTP extension that provides a mechanism for deriving shared keys for each association is presented. These association shared keys are derived from endpoint pair shared keys, which are configured and might be empty, and data that is exchanged during the SCTP association setup."



Especially the first sentence appear to me not to rightly capture what is provided. I think some clarification on the shared key properties in general might be needed.



"The SCTP extension for Dynamic Address Reconfiguration (ADD-IP) requires the usage of the extension described in this document. The SCTP Partial Reliability Extension (PR-SCTP) can be used in conjunction with the extension described in this document."



This extension review and its interaction appears to need to be updated. But, it might be simpler to focus on if there are any extension at this time that would not be compatible with SCPT-AUTH?



I think one can also consider if one like to provide a slightly more detailed overview of the solution to make the document easier to understand for the reader.



Section 3.2:



The chunk types for INIT, INIT-ACK, SHUTDOWN-COMPLETE, and AUTH chunks MUST NOT be listed in the CHUNKS parameter. However, if a CHUNKS parameter is received then the types for INIT, INIT-ACK, SHUTDOWN-COMPLETE, and AUTH chunks MUST be ignored.



What about Init to re-establish an SCTP association after a failover? Is the security context something that is required to be maintained as indicated in Section 10. And is this thus true? Shouldn’t Initi chunks after the association is established be using SCTP-AUTH?



Section 4.1:



Not that this could not happen that an unknown algorithm is used. But it really should not happen. After the Init and Init-ACK each peer will provide what they support. And it does represent a security issue. Because can you after having negotiated use of SCTP-AUTH even trust a packet with a non supported algorithm identifier?



Section 6.1:



An SCTP endpoint MUST NOT change the parameters listed in the HMAC-ALGO parameter during the lifetime of the endpoint.



I think it is unclear what is meant with a lifetime of the endpoint here. I can understand that this would apply for the life time of the SCTP association, but for the life time of the endpoint appears to limiting. I think that this preference list should be bound to a shared key. Thus, if one generate new endpoint pair shared key, one can have a different preference list when using that key?



Section 8:

I think there might be additional extension / changes needed as some of the other potential changes has been agreed on. But, lets figure out how to handle the directionality and in that discussion consider API impact.



Section 9:

Needs to be update to clarify which registries the reference should just be updated, and in which there are any new registrations.



Section 10:

So I think this document is missing a discussion on how to ensure that SCTP Association has unique keys. So as long as the random function are of good quality it is very low probability that the key input vector will be the same between two associations. But, this can in theory occur. Also the level the shared key is used will also impact the likelihood for collisions. If the shared key is strictly between two endpoints then the probability will be on one level. But if the shared key is shared across a set of N endpoints which all may communicate between each other then the reduction of collision resistance is reduced by (N-1)*(N-2).


Cheers

Magnus Westerlind