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

[Michael Tuexen <[e-mail]>]

> On 11. Mar 2024, at 11:56, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Hi,
>  In regards to what SCTP-AUTH provides.
>  So the core is source authentication of the protected chunks. So what is provided is that this combination of protected chunks did arrive from the stated source, and was all in the same packets and no part of the protected data has been changed (i.e. integrity).
I agree with the above.
>  In regards to 2) before you sent 2^32 DATA chunks then the above properties also gives you DATA integrity. When one passes 2^32 DATA chunks without rekeying then one suddenly loses user data integrity. This is not obvious and at a minimal needs to be 
I understand what you are saying here. But SCTP AUTH as specified in RFC 4895 was not designed
to protect against this without further interaction.
> stated explicitly. To avoid surprises for anyone I would think it would actually make sense to mandate implementations to actually have code that stops sending DATA chunks unless one rekeys when sctp-auth is used and covering DATA chunks. This because of the change of properties when this criteria is passed.
I do understand that you are focussing on DATA chunks in the context of securing user
data, for example via DTLS/SCTP. But there different use cases not related to DATA
chunks at all. Like the protection of ASCONF chunks...

I'm all for describing what to do in the DTLS over SCTP document. SCTP AUTH is used
there in a specific way to get a specific service. But I'm not sure we need to
do that in the SCTP AUTH document for all users, even if they are not looking at
DATA chunks.
>  So although replay protection may not be necessary, by not having it one gets a lot of much harder to analys properties of the SCTP association. So far in the analysis the control parts appear to be robust from a protocol specification perspective.  So I 
I think so. If not, we need to fix the specification.
> think the security risks with replay of DATA chunks must be addressed, at least to prevent it from happening as the security properties changes so drastically after the 2^32 DATA chunks. I think replay protection would be good as it makes things to
Two questions:
1. Do you think RFC 4895 was intended to provide such a service?
2. Do you think RFC 4895 bis needs to provide this service (assuming you agree to answer the first question with no.)?
> easier to analyse and understand what security properties one gets. But I do understand that introducing replay protection would mean a more significant change as the SCTP-AUTH chunk would likely need to introduce a SCTP-AUTH level sequence number that in expanded form (epoch + sequence number) would need to be included in the MAC calculation to ensure that replay can be prevented.
If you think improving the replay protection is a requirement for RFC 4895bis, I would
not add sequence numbers to the AUTH chunk. I would use a sequence number extension for
* DATA chunks
* I-DATA chunks
* ASCONF chunks
* RE-CONFIG chunks
since they all use sequence numbers that wrap around and I don't see why DATA chunks
are so special. Something similar to
https://www.rfc-editor.org/rfc/rfc5925.html#section-6.2
but you would need to tweak it a bit...

But let us come to an agreement of the scope of changes for RFC 4895bis. Please
answer question 1. and 2. above.

Best regards
Michael
>  Cheers
>  Magnus
>  From: tsvwg <[e-mail]> on behalf of Michael Tuexen <[e-mail]>
> Date: Sunday, 10 March 2024 at 18:52
> To: John Mattsson <john.mattsson=[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc4895-bis-02.txt
> > 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.
> >  - 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.
> > https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00
> Hi John,
> 
> maybe it is better to reach some consensus of what RFC 4895bis needs to provide.
> 
> The intention of RFC 4895 bis to provide a way for the receiver of some chunks
> to make sure they were sent by the sender and not by an attacker. They main
> use case was protecting ASCONF and ASCONF ACK chunks.
> 
> Do we agree on this?
> 
> Looking at the Security Issues listed in the presentation you cite, I see
> 
> (1) Reflection of authenticated DATA chunks.
> I agree, the possibility of reflecting authenticated DATA chunks was not
> intended and should be fixed in RFC 4895bis. But this is not specific
> to DATA chunks. It applies to all chunks sent in an authenticated way.
> 
> (2) Replay of authenticated DATA chunks
> Improving the replay protection was not a goal of RFC 4895. It might be
> used in combination with other mechanisms like an appropriate key management
> to provide this. I do understand that something like DTLS/SCTP needs to
> provide this, but I do not see it as an security issue of RFC 4895.
> 
> (3) Single key used with different HMAC algorithms
> I wasn't aware that this might be a problem. But it will be fixed in RFC 4895bis.
> 
> (4) Reflection of authenticated control chunks
> This is (1). RFC 4895 makes no difference between DATA and control chunks.
> 
> (5) Replay of control chunks
> As stated in (2), there is no intention to improve the base protocol here.
> Also, the base protocol should not have any problems with respect to
> control chunks not using sequence numbers. So I don't understand why replayed
> HEARTBEAT ACK chunks should result in a problem. If they do, they do it right
> now and that would need to be improved in the base protocol.
> If you want to protect against problems with sequence number wrap arounds,
> you always have to consider DATA and SACK, ASCONF and ASCONF ACK, RE-CONFIG
> chunks.
> 
> So I do see (1) and (4) as a single security issue and (3) as another one
> for RFC 4895. Both will be fixed in RFC 4895bis by using some sort of
> key derivation.
> 
> Do you think improving RFC 4895 to also provide (2) and (5) needs also
> to be done? I don't think so, but I would like to discuss this explicitly.
> 
> Best regards
> Michael
> >  - 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.
> >                +-----------------+----------------------------------------------+
> >               | 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".
> >  - 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.
> >  - 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.
> >  - 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.
> >  (If this is not fixed the document need to clearly describe that it does not provide integrity of user data. The document does 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).
> >  Cheers,
> > John