Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc4895-bis-02.txt

[Michael Tuexen <[e-mail]>]

> On 10. Mar 2024, at 07:29, John Mattsson <john.mattsson=[e-mail]> wrote:
> 
> Hi,
>  This seems to be work in progress. I assume the plan is to address all the vulnerabilities in some way. I have only focused on the security aspects.
Hi John,

thank you for the review.

Right now my intention is to address the first and third issue brought up in
https://mailarchive.ietf.org/arch/msg/tsvwg/8EyYbU-L-Tl_aMoUhCOuTV-pQ5c/
since allowing the reflection was not intended and we did not know that
it might be critical to use the same keys for different HMAC algorithms.

Right now my thinking is that improving the resistance against replay
attacks is not a feature of SCTP AUTH. For chunk having sequence numbers
like DATA chunk, it can be done by changing the keys appropriately.
However, this belongs to the entity providing such improved protection
like DTLS/SCTP. For control chunks not related to any sequence number
SCTP is already doing such a protection.
Please also note, that SCTP AUTH makes no assumption which chunks are
protected. This is also decided by the upper layer.

>  - I think the document needs an overview that describes the changes from RFC 4895 and why they are done. The draft should e.g., describe that directional keys are introduced to stop reflection attacks. As RFC4895bis intent to continue to operate with RFC 4895 all the security issues with RFC 4895 needs to be clearly described.
Yes, I agree. But I deferred writing the text about the changes, when all the
changes are done.
Right now, I focusses on the main problem, getting in the directioness of the keys.
That way I can get feedback on that.
> https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00
>  - If you decide to follow my previous suggestion to change HMAC to MAC. You could follow my other previous suggestion and register HMAC-SHA-256-128 instead. Having a 256-bit tag seems a bit overkill.
Going from HMAC to MAC is on the ToDo list and I considered to do it first. But
it requires a lot of changes, some are only editorial, some involve the API,
but it is a lot without any functional change. So I decided to get in *one*
directional method first. Then adding more is simple.
I also decided to keep the way of writing, which is using text instead of
formulas. But I guess it will be cleaner to use formulas. In particular
to make the switch from HMAC to MAC simple.
I saving 16 bytes critical?

My plan is to evolve to state where we can handle arbitrary MACs. Just want
to do this with one example, first. Which set of algorithms we then define
initially is something I'm open about.
>                +-----------------+----------------------------------------------+
>               | MAC Identifier | Message Digest Algorithm    
>               | 0               | Reserved                   
>               | 1               | HMAC-SHA-1                             | 2               | Reserved                   
>               | 3               | HMAC-SHA-256                                       
>               | 4               | HMAC-SHA-256-128 with directional keys
>               +-----------------+----------------------------------------------+
>  - "If the peer does not operate in legacy mode, the send context is
>    defined as the concatenation of local key vector followed by the
>    remote key vector.  The receive context is defined as the   
>    concatenation of the remote key vector followed by the local key
>    vector.  For deriving the association shared send and receive keys, a   
>    method described in Section 3.1 of [RFC5926] is used.  The  
>    association shared send key is the result of using HMAC-SHA512 as the   
>    key derivation function with the endpoint shared key as the 
>    Master_Key, the send context as the Context and 512 as the  
>    Output_Length.  The association shared receive key is computed the  
>    same way, just using the receive context as the Context.  In both   
>    cases "SCTP-AUTH" is used as the Label."
>     That this creates directional key contradicts another statement in the draft saying that "Otherwise, the key vectors are identical".
Isn't that mentioned in the paragraph about operating in legacy mode? In that context it is true.
>  - My understanding that the new API text forbids per-packet switching of algorithms leading to the same key being used in several algorithms. This should be clearly described.
I can really parse this sentence. It is correct, that user messages are tied to a key.
But how does that result in "the same key being used in several algorithms"? This is possible
in legacy mode, if one endpoint uses HMAC-SHA1 and the other HMAC-SHA256. But when
not in legacy mode, each side uses a different key. Isn't that acceptable?
>  - My understanding is that the document does not protect against replay of control chunks. If that is not planned, the document should clearly state that is does not provide replay protection. The deduplication mechanism in RFC 9260 is not replay protection, and SCTP-AUTH is a security protocol.

What is replay protection? In my view this is a method to ensure that if
you get a chunk again, no problems arise. It doesn't matter if the packet
comes from an attacker or is duplicated in the network.

My understanding is that SCTP AUTH allows the receiver to verify that the
packet was sent from the peer. Not once, not recently. It is up the
the entity doing the key management to do it appropriately to achieve
its goals.

SCTP AUTH also makes no assumption on what chunks are protected. It only
states, which chunks can not be protected.

I would also be interested which control chunk you think need special
handling. I think every SCTP should handle them appropriately if they
are duplicated.
>  - My understanding is that the document does not protect against replay of data chunks the same direction (yet). I.e., after 2^32 data chunks the TSN reaches the Initial TSN and an on-path attacker can replay authenticated data chunks as the Stream Identifier, and Stream Sequence Number “match”. If user messages are large (more chunks than 2^32), replay can trivially be done after 2^32 chunks when the TSN reaches the Initial TSN.
So you are talking about user messages larger than 6 TB...
Providing protection against such an attack was not a goal of RFC 4895.
Why do you think it was? Why do you think the bis document needs to do
this.
It can be a component for such a protection, for example when used in
combination with DTLS, but it is not providing it by itself.

I guess we should agree on goals for RFC 4895. 

>  (If this is not fixed the document need to clearly describe that it does not provide integrity of user data. The document does 
Where does it make such a statement? It is not making any statement about DATA chunks, except
discussing that AUTH chunks are control chunks and can not be placed after DATA chunks.

So where are your assumptions about services provided from SCTP AUTH are coming from?
> not state that it does, but the reader cannot be expected to understand that the lack of replay protection lead to lack of integrity protection of the user data. The end user is likely interested in integrity of the user data).
It might be, but where is it stated that just using SCTP AUTH gives that service?

Best regards
Michael
>  Cheers,
> John