As specified by RFC 7296, section 2.6, the data associated with COOKIE
notifications MUST be between 1 and 64 octets in length (inclusive).
Fixes#3160.
Luckily, the type is only used once when generating payloads and there it
doesn't matter because the encoding rules are the same.
Closesstrongswan/strongswan#135.
This allows us to use it without having to initialize libcharon, which
was required for the logging (we probably could have included debug.h
instead of daemon.h to workaround that but this seems more correct).
Due to the lookup based on the mapped algorithm ID the resulting AH
proposals were invalid.
Fixes#2347.
Fixes: 8456d6f5a8 ("ikev1: Don't require AH mapping for integrity algorithm when generating proposal")
According to the mode-config draft there is no prefix sent for
IPv6 addresses in IKEv1. We still accept 17 bytes long addresses for
backwards compatibility with older strongSwan releases.
Fixes#1304.
Some implementations don't send a Key Length attribute for AES-128.
This was allowed for IKE in early drafts of RFC 3602, however, some
implementations also seem to do it for ESP, where it never was allowed.
And the final version of RFC 3602 demands a Key Length attribute for both
phases so they shouldn't do it anymore anyway.
Fixes#1064.
This fixes a DoS and potential remote code execution vulnerability that was
caused because the original payload type that was returned previously was
used to cast such payload objects to payloads of the indicated type (e.g.
when logging notify payloads with a payload type for the wrong IKE version).
Fixes CVE-2015-3991.
When using a cipher with sequential IVs, we never must pass an identical IV
to the IV generator. To avoid it when using IKEv2 fragmentation, use the lower
bits of the 64-bit message ID as the fragment number.
This commit reverts 84738b1a and 2ed5f569.
As we have no DH group available in the KE payload for IKEv1, the verification
can't work in that stage. Instead, we now verify DH groups in the DH backends,
which works for any IKE version or any other purpose.
The verification introduced with 84738b1aed ("encoding: Verify the length
of KE payload data for known groups") can't be done for IKEv1 as the KE
payload does not contain the DH group.
IKE is very strict in the length of KE payloads, and it should be safe to
strictly verify their length. Not doing so is no direct threat, but allows DDoS
amplification by sending short KE payloads for large groups using the target
as the source address.
Since 42e0a317c6 ("ike: Only parse payloads valid for the current IKE
version") payload types are checked before creating objects. This check
failed for internally used payload types (e.g. proposal substructures),
which have a type >= 256, i.e. outside the IKE payload type range.
The transform identifier used in AH transforms is not the same as the
authentication algorithm identifier used in the transform attributes in
AH (and ESP) transforms.
While the examples in RFC 2408 show proposal numbers starting at 1 and
increasing by one for each subsequent proposal this is not mandatory.
Actually, IKEv1 proposals may start at any number, the only requirement
is that the proposal numbers increase monotonically they don't have to
do so consecutively.
Most implementations follow the examples and start numbering at 1 (charon,
racoon, Shrew, Cisco, Windows XP, FRITZ!Box) but pluto was one of the
implementations that started with 0 and there might be others out there.
The previous assumption that implementations always start numbering proposals
at 0 caused problems with clients that start numbering with 1 and whose first
proposal consists of multiple protocols (e.g. ESP+IPComp).
Fixes#661.
Tobias Brunner