denozord/strongswan-ext
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
13,466 Commits 1 Branch 0 Tags
70e0be072bca5a1af768da244e3cbf140ea0e172
Commit Graph
296 Commits
Author SHA1 Message Date
Tobias Brunner 70e0be072b ikev1: Move defragmentation to message_t 2014-10-10 09:30:26 +02:00
Tobias Brunner 2e7a2c06a1 message: fragment() generates message and fragments and caches them 2014-10-10 09:30:26 +02:00
Tobias Brunner e0b35142c1 message: Make packet argument optional in generate() 2014-10-10 09:30:26 +02:00
Tobias Brunner 127a98dc90 ikev1: Move fragment generation to message_t 2014-10-10 09:30:26 +02:00
Tobias Brunner 147fe503af ike: Rename encryption_payload to encrypted_payload 2014-10-10 09:30:25 +02:00
Martin Willi 2dee0a85a6 encoding: Accept all exchange types for non IKEv1/IKEv2 major versions 2014-09-22 13:42:11 +02:00
Tobias Brunner 8a6b01dd2a ikev1: Don't cache last block of INFORMATIONAL messages as IV 
We don't expect a response with the same MID, but apparently some
devices (e.g. FRITZ!Box) do that for DPDs, while still treating the
response as a new exchange.  By storing the last message block as IV
we can't decrypt the first block of such a response.

Fixes #661.
 2014-09-12 13:56:18 +02:00
Tobias Brunner 2e62f51bcc ikev1: Log IV when encrypting messages 2014-09-12 13:56:17 +02:00
Tobias Brunner 2f7fef569b ikev1: Skip unusable IPComp proposals 
Fixes #661.
 2014-09-12 13:56:06 +02:00
Tobias Brunner 84337ac8d0 ikev1: Properly handle different proposal numbering schemes 
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.
 2014-09-12 13:55:00 +02:00
Martin Willi d1eff687cf encoding: Don't explicitly include <arpa/inet.h> 2014-06-04 15:53:03 +02:00
Martin Willi 3ecfc83c6b payload: Use common prefixes for all payload type identifiers 
The old identifiers did not use a proper namespace and often clashed with
other defines.
 2014-06-04 15:53:03 +02:00
Martin Willi c4c9d291d2 ikev1: Add an option to accept unencrypted ID/HASH payloads 
Even in Main Mode, some Sonicwall boxes seem to send ID/HASH payloads in
unencrypted form, probably to allow PSK lookup based on the ID payloads. We
by default reject that, but accept it if the
charon.accept_unencrypted_mainmode_messages option is set in strongswan.conf.

Initial patch courtesy of Paul Stewart.
 2014-04-17 08:52:28 +02:00
Tobias Brunner a30e0001e4 ikev1: Accept SPI size of any length <= 16 in ISAKMP proposal 
Fixes #533.
 2014-03-31 14:32:44 +02:00
Martin Willi f316116c88 ike: Support encoding of attribute certificates in CERT payloads 2014-03-31 11:14:58 +02:00
Andreas Steffen 6db81edac3 Added IFOM_CAPABILITY notify message type 2013-11-01 14:07:11 +01:00
Tobias Brunner e8229ad558 iv_gen: Provide external sequence number (IKE, ESP) 
This prevents duplicate sequential IVs in case of a HA failover.
 2013-10-11 15:55:40 +02:00
Tobias Brunner b5010707a0 ikev2: Use IV generator to encrypt encrypted payload 2013-10-11 15:55:40 +02:00
Martin Willi a1379e3210 ikev1: Support parsing of AH+IPComp proposals 2013-10-11 10:15:21 +02:00
Martin Willi d489e75579 ikev1: Accept more than two certificate payloads 2013-10-11 10:15:21 +02:00
Martin Willi 3771b85806 ikev1: Support en-/decoding of SA payloads with AH algorithms 2013-10-11 10:15:21 +02:00
Martin Willi 61b0079881 message: print type of configuration payload 2013-09-03 16:26:19 +02:00
Martin Willi 8e4b258030 message: print attributes for IKEv1 configuration payloads as well 2013-09-03 16:26:19 +02:00
Tobias Brunner 0ceb288815 Fix various API doc issues and typos 
Partially based on an old patch by Adrian-Ken Rueegsegger.
 2013-07-18 18:30:36 +02:00
Tobias Brunner 84693a3d79 linked-list: Remove barely used has_more() method 
This required some refactoring when handling encrypted payloads.

Also changed log messages so that "encrypted payload" is logged instead
of "encryption payload" (even if we internally still call it that) as
that's the name used in RFC 5996.
 2013-07-17 17:42:53 +02:00
Tobias Brunner 0adf165c7e Fix crash if the initiator has no suitable proposal available 
Could be triggered with a typo in the ike or esp options when ! is used.
 2013-06-21 11:09:03 +02:00
Martin Willi a0f6f39343 proposals: try next if IKEv2 algorithm could not be mapped to IKEv1 2013-05-06 15:54:32 +02:00
Tobias Brunner 665fac2433 Allow up to 10 NAT-D payloads in IKEv1 messages 2013-03-20 16:20:39 +01:00
Andreas Steffen b038c62e4a added ERX_SUPPORTED IKEv2 Notify 2013-03-02 17:18:37 +01:00
Martin Willi a36b49f3cb Merge branch 'opaque-ports' 
Adds a %opaque port option and support for port ranges in left/rightprotoport.
Currently not supported by any of our kernel backends.
 2013-03-01 11:27:12 +01:00
Martin Willi b443fa6123 Don't reject OPAQUE ports while verifying traffic selector substructure 2013-02-21 11:52:33 +01:00
Tobias Brunner af5452ba76 Allow more than one CERTREQ payload for IKEv2 
There is no reason not to do so (RFC 5996 explicitly mentions multiple
CERTREQ payloads) and some implementations seem to use the same behavior
as had to be used with IKEv1 (i.e. each CA in its own CERTREQ payload).
 2013-02-08 11:28:56 +01:00
Tobias Brunner 21235e1ec2 Merge branch 'ikev1-fragmentation' 
This adds support for the proprietary IKEv1 fragmentation extension.

Conflicts:
	NEWS
 2013-01-12 11:58:26 +01:00
Martin Willi 54a1a75b2f Don't use bio_writer_t.skip() to write length field when appending more data 
If the writer reallocates its buffer, the length pointer might not be valid
anymore, or even worse, point to an arbitrary allocation.
 2013-01-11 14:57:08 +01:00
Volker Rümelin 6d3e7a64a0 IKEv1 support for PKCS#7 wrapped certificates 2013-01-11 10:21:56 +01:00
Volker Rümelin 10eee5fcba Fixed some typos in comments 2013-01-11 10:21:51 +01:00
Tobias Brunner 07df944c9c Add support to create IKE fragments 
All fragments currently use the same fragment ID (1) as that's what
other implementations are doing.
 2012-12-24 12:29:30 +01:00
Tobias Brunner 9b1659f52c Add message rules to properly handle IKE fragments 
These are sent in unencrypted messages and are the only payload
contained in such messages.
 2012-12-24 10:24:48 +01:00
Tobias Brunner ddfad8b67e Reset the encrypted flag when handling IKE messages that contain a fragment 
Racoon sets the encrypted bit for messages containing a fragment, but these
messages are not really encrypted (the fragmented message is though).
 2012-12-24 10:24:48 +01:00
Tobias Brunner 8f0ab6dd36 Payload added to handle IKE fragments 2012-12-24 10:24:48 +01:00
Tobias Brunner ef33a4ab82 Fixed some typos, courtesy of codespell 2012-12-20 09:35:26 +01:00
Volker Rümelin 0ff8d20a89 Add support for draft-ietf-ipsec-nat-t-ike-03 and earlier 
This adds support for early versions of the draft that eventually
resulted in RFC 3947.
 2012-12-19 11:03:42 +01:00
Tobias Brunner 12642a6831 Moved data structures to new collections subfolder 2012-10-24 16:00:49 +02:00
Tobias Brunner fdee6b5f5a Moved packet_t and tun_device_t to networking folder 2012-10-24 15:06:18 +02:00
Tobias Brunner 2e7cc07ecd Moved host_t and host_resolver_t to a new networking subfolder 2012-10-24 15:06:18 +02:00
Martin Willi aa51d5dd25 Increase the limit of acceptable IKEv1 CERTREQ payloads to 20 2012-10-24 13:07:53 +02:00
Tobias Brunner f3d98a6b78 Correctly initialize payload length of encrypted payload 2012-09-28 16:30:26 +02:00
Tobias Brunner 576490ab09 Added method to enumerate EAP types contained in an EAP-Nak 2012-08-31 11:40:28 +02:00
Tobias Brunner cc4eec56f7 Encode EAP-Naks in expanded format if we got an expanded type request 
Since methods defined by the IETF (vendor ID 0) could also be encoded in
expanded type format the previous check was insufficient.
 2012-08-31 11:40:27 +02:00
Tobias Brunner 78e8dca94f Allow clients to request a configured EAP method via EAP-Nak 2012-08-31 11:40:27 +02:00