strongSwan - Bug #2614
StrongSwan sends/expects key length for chapoly even though it is a fixed-length key
04.04.2018 17:20 - J Xu

ステータス:

Closed

開始日:

優先度:

Normal

期日:担当者:

Tobias Brunner

予定工数:

0.00時間カテゴリ:

interoperability

対象バージョン:5.6.3

Affected version:

5.6.2

Resolution:

Fixed

説明
Currently when the ChaCha20/Poly1305 ciphersuite is proposed in the SA payload, StrongSwan sends (as initiator) and expects toreceive (as responder) a key length attribute attached to the ENCR transform with the value 256.
However, ChaCha20/Poly1305 as described by RFC 7539 and RFC 7634 has a fixed-length key. RFC 7296 for IKEv2 prohibits
using the key length attribute when the transform uses a fixed-length key:oTheKey Length attribute MUST NOT be used with transforms that usea fixed-length key.
For example, this includes ENCR̲DES,ENCR̲IDEA, and all the Type 2 (Pseudorandom Function) and Type 3(Integrity Algorithm) transforms specified in this document.
Itis recommended that future Type 2 or 3 transforms do not use thisattribute.

StrongSwan responder currently rejects proposals for CHACHA20̲POLY1305 without a key length attribute, so it is unable tointeroperate as a responder against clients which conform to the spec. As initiator it also violates the above and may also causeinteroperability issues with other clients which do not ignore the attribute.
履歴#1 - 04.04.2018 18:11 - Tobias Brunner- トラッカー を Issue から Bug に変更- ステータス を New から Feedback に変更- 優先度 を High から Normal に変更- 対象バージョン を 5.6.3 にセット
Thanks for the report. That's pretty unfortunate. I pushed a fix to the 2614-chacha-keysize branch. Let me know if that works for you.
#2 - 04.04.2018 19:48 - J Xu
Thanks for the quick turnaround. The change 'almost' works, but when specifying both (for example)
ike=chacha20poly1305-prfsha256-ecp256!
esp=chacha20poly1305-ecp256!
I get this:charon: 10[CHD] no keylength defined for CHACHA20̲POLY1305
I think there needs to be a line in keymat̲get̲keylen̲encr() in src/libcharon/sa/keymat.c. Works great for me after that.
#3 - 05.04.2018 08:32 - Martin Willi

That's pretty unfortunate.

Indeed.
I pushed a fix to the 2614-chacha-keysize branch.

14.10.2024

1/2

How does that behave when an unpatched version interoperates with a patched one? I guess when the unpatched version is the exchange initiator,
this is properly handled, but what about other case? Given the randomized rekey times, the role is non-deterministic. Is it even worth to have thecompat code, or do we just hide a problem that then pops up during rekeying?
I can't think of a good solution, but we probably should note this in the release notes then.
#4 - 05.04.2018 08:54 - Tobias Brunner

I think there needs to be a line in keymat̲get̲keylen̲encr() in src/libcharon/sa/keymat.c. Works great for me after that.

Correct, thanks. Fixed in the updated branch.
I pushed a fix to the 2614-chacha-keysize branch.

How does that behave when an unpatched version interoperates with a patched one? I guess when the unpatched version is the exchange
initiator, this is properly handled, but what about other case? Given the randomized rekey times, the role is non-deterministic. Is it even worth
to have the compat code, or do we just hide a problem that then pops up during rekeying?

Hm, right. The compat code only helps if the old release is initiator. I guess we could document that so users could configure lifetimes accordingly(it doesn't help if a fixed version is original initiator, though). But it might not be worth it to just use a specific algorithm (and the alternative ofsomehow taking note that the key size was sent and do the same when initiating the rekeying is also ugly, and again does not help as originalinitiator). So yeah, we perhaps could just get rid of the compat code (obviously simplifies the fix a lot, see 2614-chacha-keysize-no-compat branch)and just document that versions between 5.3.3 and 5.6.2 can't be used with releases that are fixed.
#5 - 12.04.2018 16:21 - Tobias Brunner- カテゴリ を charon から interoperability に変更- ステータス を Feedback から Closed に変更- 担当者 を Tobias Brunner にセット
- Resolution を Fixed にセット
Pushed the non-compat fix to master.

14.10.2024

2/2