This issue was raised at github. The relevant text from RFC 2409 (which
has a very confusing MAY NOT statement) is:
Similarly, Aggressive Mode is an instantiation of the ISAKMP
Aggressive Exchange. The first two messages negotiate policy,
exchange Diffie-Hellman public values and ancillary data necessary
for the exchange, and identities. In addition the second message
authenticates the responder. The third message authenticates the
initiator and provides a proof of participation in the exchange. The
XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY
NOT be sent under protection of the ISAKMP SA allowing each party to
postpone exponentiation, if desired, until negotiation of this
exchange is complete.
I read that as "The final message MAY be sent NOT under protection of".
The attached patch is:
index 4f3984557c..4cedbf85f3 100644
--- a/programs/pluto/ikev1.c
+++ b/programs/pluto/ikev1.c
@@ -438,14 +438,14 @@ static const struct state_v1_microcode
v1_state_microcode_table[] = {
*/
{ STATE_AGGR_R1, STATE_AGGR_R2,
SMF_PSK_AUTH | SMF_FIRST_ENCRYPTED_INPUT |
- SMF_ENCRYPTED | SMF_RELEASE_PENDING_P2 |
+ SMF_OUTPUT_ENCRYPTED | SMF_RELEASE_PENDING_P2 |
SMF_RETRANSMIT_ON_DUPLICATE,
P(HASH), P(VID) | P(NATD_RFC),
EVENT_SA_REPLACE, aggr_inI2 },
{ STATE_AGGR_R1, STATE_AGGR_R2,
SMF_DS_AUTH | SMF_FIRST_ENCRYPTED_INPUT |
- SMF_ENCRYPTED | SMF_RELEASE_PENDING_P2 |
+ SMF_OUTPUT_ENCRYPTED | SMF_RELEASE_PENDING_P2 |
SMF_RETRANSMIT_ON_DUPLICATE,
P(SIG), P(VID) | P(NATD_RFC),
EVENT_SA_REPLACE, aggr_inI2 },
I have tested this patch in a new-new, new-old and old-new libreswan to
libreswan test, and it did not cause any regressions. The poster said
it fixes an interop issue with "Volans gateway", from Volans Technology,
Inc in China.
Not encrypting that packet results in NAT detection paloads, and the
SIG payload not being encrypted. So I guess there is no privacy issue.
The use of "final message" and "each party" suggests both ends can
not encrypt their last message. If we always encrypt our final message,
I guess the "gains" talked about in the RFC are lost. But I guess
the patch does increase interoperability and RFC conformance.
So I'll apply it in a few days if I don't hear any objections.
Paul
---------- Forwarded message ----------
Date: Mon, 24 Dec 2018 01:30:43
From: wuw <[email protected]>
Cc: Subscribed <[email protected]>
To: libreswan/libreswan <[email protected]>
Subject: [libreswan/libreswan] ikev1:optionally the last message of aggressive
mode is encrypted (#230)
Libreswan assumes the final message in aggressive mode is encrypted.
if the message is not encrypted, Libreswan return INVALID_FLAGS and rejects
this packet.
But in RFC 2409, Aggressive Mode The final message MAY NOT be sent under
protection of the ISAKMP SA.
_______________________________________________________________________________________________________________________________________________________________________________________________________________
You can view, comment on, or merge this pull request online at:
https://github.com/libreswan/libreswan/pull/230
Commit Summary
* ikev1:optionally the last message of aggressive mode is encrypted
File Changes
* M programs/pluto/ikev1.c (4)
Patch Links:
* https://github.com/libreswan/libreswan/pull/230.patch
* https://github.com/libreswan/libreswan/pull/230.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the
thread.[AC3V-TAfyZRDHW-Q7XgbORGQZ8uSjLN8ks5u8HSTgaJpZM4ZgK21.gif]
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
