Project

General

Profile

Bug #2614

StrongSwan sends/expects key length for chapoly even though it is a fixed-length key

Added by J Xu about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Category:
interoperability
Target version:
Start date:
Due date:
Estimated time:
Affected version:
5.6.2
Resolution:
Fixed

Description

Currently when the ChaCha20/Poly1305 ciphersuite is proposed in the SA payload, StrongSwan sends (as initiator) and expects to receive (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:

o  The Key Length attribute MUST NOT be used with transforms that use
a 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. It
is recommended that future Type 2 or 3 transforms do not use this
attribute.

StrongSwan responder currently rejects proposals for CHACHA20_POLY1305 without a key length attribute, so it is unable to interoperate as a responder against clients which conform to the spec. As initiator it also violates the above and may also cause interoperability issues with other clients which do not ignore the attribute.

Associated revisions

Revision 5a7b0be2 (diff)
Added by Tobias Brunner about 1 year ago

proposal: Don't specify key length for ChaCha20/Poly1305

This algorithm uses a fixed-length key and we MUST NOT send a key length
attribute when proposing such algorithms.

While we could accept transforms with key length this would only work as
responder, as original initiator it wouldn't because we won't know if a
peer requires the key length. And as exchange initiator (e.g. for
rekeyings), while being original responder, we'd have to go to great
lengths to store the condition and modify the sent proposal to patch in
the key length. This doesn't seem worth it for only a partial fix.
This means, however, that ChaCha20/Poly1305 can't be used with previous
releases (5.3.3 an newer) that don't contain this fix.

Fixes #2614.

Fixes: 3232c0e64ed1 ("Merge branch 'chapoly'")

History

#1 Updated by Tobias Brunner about 1 year ago

  • Tracker changed from Issue to Bug
  • Status changed from New to Feedback
  • Priority changed from High to Normal
  • Target version set to 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 Updated by J Xu about 1 year ago

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 Updated by Martin Willi about 1 year ago

That's pretty unfortunate.

Indeed.

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?

I can't think of a good solution, but we probably should note this in the release notes then.

#4 Updated by Tobias Brunner about 1 year ago

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 of somehow 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 original initiator). 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 Updated by Tobias Brunner about 1 year ago

  • Category changed from charon to interoperability
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

Pushed the non-compat fix to master.

Also available in: Atom PDF