[Swan-dev] IKEv1 Aggr Mode bug: The final message MAY NOT be sent under protection of the ISAKMP SA

[Paul Wouters]

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 <notifications at github.com>
Cc: Subscribed <subscribed at noreply.github.com>
To: libreswan/libreswan <libreswan at noreply.github.com>
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]