[Swan] Can you elaborate on this ?

[Philippe Vouters]

Paul,

Can you give me with no hesitation which actual state corresponds to
OAKLEY_AUTH_ROOF + 2 ? From the lecture of Libreswan source code, 
getting this certainty is not trivial.
OAKLEY_AUTH_ROOF + 2 conditions this loglog'ed message:

         if (smc->flags & SMF_INPUT_ENCRYPTED)
         {
             loglog(RC_LOG_SERIOUS, "packet rejected: should have been 
encrypted");
             SEND_NOTIFICATION(INVALID_FLAGS);
             return;
         }

 From ./include/ietf_constants.h
/* extern enum_names oakley_auth_names; */

#define OAKLEY_PRESHARED_KEY       1
#define OAKLEY_DSS_SIG             2
#define OAKLEY_RSA_SIG             3
#define OAKLEY_RSA_ENC             4
#define OAKLEY_RSA_ENC_REV         5
#define OAKLEY_ELGAMAL_ENC         6
#define OAKLEY_ELGAMAL_ENC_REV     7

#define OAKLEY_AUTH_ROOF           8  /*roof on auth values THAT WE 
SUPPORT */

smc in the code extract above is nothing but:
smc = md->smc;
and as per your explanation on md, I quote you:
"
md is the message digest, the stream of bytes from the incoming packet.
"
*smc->flags should have been set by the Netscreen side.*

*CONCLUSION:*

If Libreswan/Openswan are indeed correct in the SMF_INPUT_ENCRYPTED 
mask, this is another bug on the Netscreen side.

*NOTE:*

Provided Libreswan is proved to be buggy, Openswan 2.6.38 highlights the 
exact same code sequence.

Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

Le 22/01/2013 19:01, Philippe Vouters a écrit :
> Paul, Elison
>
> So far facts :
> - Netscreen thinks it is time for phase 2 when Libreswan is still in 
> phase 1.
> - From Elison's # ipsec auto --status command, Libreswan is expecting 
> Aggregate I2 which does not come.
> - the loglog in the code block I pointed out is triggered.
> - Elison did not show the effect of the 
> SEND_NOTIFICATION(INVALID_FLAGS); on Netscreen side. Apparently this 
> SEND_NOTIFICATION is ignored by Netscreen, backed up by the fact 
> Netscreen thinks it is time for phase 2 when it is not. This should be 
> code missing on the Netscreen side.
>
> Questions:
> - Is the loglog'ed message which is triggered the root cause for 
> Libreswan still expecting I2 and never going through ? Apparently the 
> code extract does reject the network packet.
> - Is the loglog'ed message fully justified ?
>
> Further facts to be collected by Elison:
> A Wireshark trace taken on the Librewan side filtered on 'src or dst 
> <Netscreen IP address> udp port 500 or udp port 4500'. If Elison can 
> put the Wireshark trace onto an FTP server so that I can download it 
> and study it, this ought to be great. I would like to attempt to 
> retrieve the rejected packet.
>
> Philippe Vouters (Fontainebleau/France)
> URL: http://vouters.dyndns.org/
> SIP: sip:Vouters at sip.linphone.org
>
> Le 22/01/2013 17:47, Paul Wouters a écrit :
>> On Tue, 22 Jan 2013, Philippe Vouters wrote:
>>
>>> Part or all of Elison's problems is caused by this in 
>>> ./programs/pluto/ikev1.c:
>>>     {
>>>        /* packet was not encryped -- should it have been? */
>>>
>>>        if (smc->flags & SMF_INPUT_ENCRYPTED)
>>>        {
>>>            loglog(RC_LOG_SERIOUS, "packet rejected: should have been 
>>> encrypted");
>>>            SEND_NOTIFICATION(INVALID_FLAGS);
>>>            return;
>>>        }
>>> It gets conditionally executed when if (md->hdr.isa_flags & 
>>> ISAKMP_FLAG_ENCRYPTION) reveals false.
>>> SMF_INPUT_ENCRYPTED is a macro inside the same source file which is 
>>> set to:
>>> #define SMF_INPUT_ENCRYPTED     LELEM(OAKLEY_AUTH_ROOF + 2)
>>>
>>> OAKLEY_AUTH_ROOF is defined as:
>>> #define OAKLEY_AUTH_ROOF           8  /*roof on auth values THAT WE 
>>> SUPPORT */
>>> ./include/ietf_constants.h
>>>
>>> Can you justify a bit more on the pertinence or not of the above 
>>> loglog(RC_LOG_SERIOUS,...) that Elison faces ????
>>
>> SMF stands for State Machine Flags. Those are predicates that must be
>> met to be a valid packet for a certain state in the state machine.
>>
>> When we initiate or respond to a connection, an "instance" is created
>> for that connection with a state object (see struct state). The state
>> machines defines the valid states. For each state, following the RFCs,
>> certain conditions must be met. These are encoded with the SMF_* flags.
>> When processing an incoming packet, a state change transition may
>> happen. These are encoded in the STF_XXXX messages, such as:
>>
>> STF_OK: state changed successfully
>> STF_FAIL: state change not successful. Usually this triggers sending a
>> packet with an error condition, such as NO_PROPOSAL_CHOSEN.
>> STF_INLINE: an internal state change (not based on RFC). Usually refers
>> to helper processes that we wait on.
>> STF_FATAL: we should never have reached this point. There is an error in
>> our code - launch assertion failure, dump core, and restart daemon.
>> STF_IGNORE: we are remaining in the same state, awaiting a new event.
>>
>> pluto is event based. State changes happen as a result of an event. This
>> could be receiving a packet, a timer based event, or our select() call
>> receiving an event (eg crypto helper ready, whack command on socket)
>>
>> The terms I and R in MAIN_I1 or AGGR_R2 stands for the mode (main mode,
>> aggressive mode, quick mode, etc) followed by the I for initiator states
>> and R for responder states, followed by the packet number. Functions
>> related to the state have names that signify what comes in, and what
>> goes out, so aggr_inI2_outR2() is called only when the state is in
>> Aggressive mode R1, and we are waiting to receive the second packet from
>> the initiator, upon which we will send out the second packet as
>> responder and move into the Aggr R2 state (which if you would look at
>> the state table, would be expecting a Quick Mode I1 packet)
>>
>> md is the message digest, the stream of bytes from the incoming packet.
>> It contains the IKE (ISAKMP) header of the incoming packet. The IKE 
>> header
>> of the incoming packet contains a flag stating whether or not the packet
>> is encrypted. So for each state in the state machine, we compare the
>> received "encryption flag" (md->hdr.isa_flags & ISAKMP_FLAG_ENCRYPTION)
>> with the expected state machine "encryption flag" (SMF_INPUT_ENCRYPTED)
>>
>> The ROOF and LELEM are constructs designed by Hugh Redelmeier to ease
>> the checking of certain flags and switch cases. You normally iterate
>> until you hit the ROOF. If you hit the ROOF, it means what that what
>> you were looking for was not found. ROOF is like "maximum". I find the
>> construct of LELEM complicated, it is deeply depending on MACRO's. I
>> should have an explanation by Hugh somewhere in old email that I can try
>> to find for you at a later date. So I cannot tell you right now how the
>> construct of LELEM works with a ROOF + value, but I am fairly confident
>> that the code is correct. Perhaps Hugh can elaborate further.
>>
>> As stated in my answers on the list, I am pretty sure the "encrypted"
>> versus "unencrypted" messages are due because of a disagreement between
>> the parameters of the connection. Because this is Aggressive Mode, and
>> exchanging parameters and Diffie-Hellman happen concurrently (unlike in
>> Main Mode where DH is completed before parameters are exchanged, but it
>> takes double the number of packets exchanged, so has double the
>> latency in establishing the connection)
>>
>> One could argue a new state in the state machine could be made where we
>> can go and receive an unencrypted message, and parse the notification
>> payload. This state would not allow to move into Aggr R2.
>>
>> But we are remaining in the same state because we could still receive a
>> properly encrypted message. An unencrypted message could be send by an
>> attacker to mislead us, so we cannot make any state machine changes 
>> based
>> on such an unsecured packet that could have been spoofed. So we log it,
>> and remain waiting for a proper packet that complies with the RFCs as
>> implemented in our state machine. This is likely signaled by the
>> function returning STF_IGNORE (I did not look it up)
>>
>> Paul
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20130122/cde359c0/attachment-0001.html>