<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Paul,<br>
<br>
Can you give me with no hesitation which actual state corresponds
to<br>
OAKLEY_AUTH_ROOF + 2 ? From the lecture of Libreswan source code,
getting this certainty is not trivial.<br>
OAKLEY_AUTH_ROOF + 2 conditions this loglog'ed message:<br>
<br>
if (smc->flags & SMF_INPUT_ENCRYPTED)<br>
{<br>
loglog(RC_LOG_SERIOUS, "packet rejected: should have
been encrypted");<br>
SEND_NOTIFICATION(INVALID_FLAGS);<br>
return;<br>
}<br>
<br>
From ./include/ietf_constants.h<br>
/* extern enum_names oakley_auth_names; */<br>
<br>
#define OAKLEY_PRESHARED_KEY 1<br>
#define OAKLEY_DSS_SIG 2<br>
#define OAKLEY_RSA_SIG 3<br>
#define OAKLEY_RSA_ENC 4<br>
#define OAKLEY_RSA_ENC_REV 5<br>
#define OAKLEY_ELGAMAL_ENC 6<br>
#define OAKLEY_ELGAMAL_ENC_REV 7<br>
<br>
#define OAKLEY_AUTH_ROOF 8 /*roof on auth values THAT
WE SUPPORT */<br>
<br>
smc in the code extract above is nothing but:<br>
smc = md->smc;<br>
and as per your explanation on md, I quote you:<br>
"<br>
md is the message digest, the stream of bytes from the incoming
packet.
<br>
"<br>
<b>smc->flags should have been set by the Netscreen side.</b><br>
<br>
<b>CONCLUSION:</b><br>
<br>
If Libreswan/Openswan are indeed correct in the
SMF_INPUT_ENCRYPTED mask, this is another bug on the Netscreen
side.<br>
<br>
<b>NOTE:</b><br>
<br>
Provided Libreswan is proved to be buggy, Openswan 2.6.38
highlights the exact same code sequence.<br>
<pre class="moz-signature" cols="72">Philippe Vouters (Fontainebleau/France)
URL: <a class="moz-txt-link-freetext" href="http://vouters.dyndns.org/">http://vouters.dyndns.org/</a>
SIP: <a class="moz-txt-link-abbreviated" href="mailto:sip:Vouters@sip.linphone.org">sip:Vouters@sip.linphone.org</a></pre>
Le 22/01/2013 19:01, Philippe Vouters a écrit :<br>
</div>
<blockquote cite="mid:50FED405.40503@laposte.net" type="cite">Paul,
Elison
<br>
<br>
So far facts :
<br>
- Netscreen thinks it is time for phase 2 when Libreswan is still
in phase 1.
<br>
- From Elison's # ipsec auto --status command, Libreswan is
expecting Aggregate I2 which does not come.
<br>
- the loglog in the code block I pointed out is triggered.
<br>
- 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.
<br>
<br>
Questions:
<br>
- 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.
<br>
- Is the loglog'ed message fully justified ?
<br>
<br>
Further facts to be collected by Elison:
<br>
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.
<br>
<br>
Philippe Vouters (Fontainebleau/France)
<br>
URL: <a class="moz-txt-link-freetext" href="http://vouters.dyndns.org/">http://vouters.dyndns.org/</a>
<br>
SIP: <a class="moz-txt-link-abbreviated" href="mailto:sip:Vouters@sip.linphone.org">sip:Vouters@sip.linphone.org</a>
<br>
<br>
Le 22/01/2013 17:47, Paul Wouters a écrit :
<br>
<blockquote type="cite">On Tue, 22 Jan 2013, Philippe Vouters
wrote:
<br>
<br>
<blockquote type="cite">Part or all of Elison's problems is
caused by this in ./programs/pluto/ikev1.c:
<br>
{
<br>
/* packet was not encryped -- should it have been? */
<br>
<br>
if (smc->flags & SMF_INPUT_ENCRYPTED)
<br>
{
<br>
loglog(RC_LOG_SERIOUS, "packet rejected: should
have been encrypted");
<br>
SEND_NOTIFICATION(INVALID_FLAGS);
<br>
return;
<br>
}
<br>
It gets conditionally executed when if (md->hdr.isa_flags
& ISAKMP_FLAG_ENCRYPTION) reveals false.
<br>
SMF_INPUT_ENCRYPTED is a macro inside the same source file
which is set to:
<br>
#define SMF_INPUT_ENCRYPTED LELEM(OAKLEY_AUTH_ROOF + 2)
<br>
<br>
OAKLEY_AUTH_ROOF is defined as:
<br>
#define OAKLEY_AUTH_ROOF 8 /*roof on auth values
THAT WE SUPPORT */
<br>
./include/ietf_constants.h
<br>
<br>
Can you justify a bit more on the pertinence or not of the
above loglog(RC_LOG_SERIOUS,...) that Elison faces ????
<br>
</blockquote>
<br>
SMF stands for State Machine Flags. Those are predicates that
must be
<br>
met to be a valid packet for a certain state in the state
machine.
<br>
<br>
When we initiate or respond to a connection, an "instance" is
created
<br>
for that connection with a state object (see struct state). The
state
<br>
machines defines the valid states. For each state, following the
RFCs,
<br>
certain conditions must be met. These are encoded with the SMF_*
flags.
<br>
When processing an incoming packet, a state change transition
may
<br>
happen. These are encoded in the STF_XXXX messages, such as:
<br>
<br>
STF_OK: state changed successfully
<br>
STF_FAIL: state change not successful. Usually this triggers
sending a
<br>
packet with an error condition, such as NO_PROPOSAL_CHOSEN.
<br>
STF_INLINE: an internal state change (not based on RFC). Usually
refers
<br>
to helper processes that we wait on.
<br>
STF_FATAL: we should never have reached this point. There is an
error in
<br>
our code - launch assertion failure, dump core, and restart
daemon.
<br>
STF_IGNORE: we are remaining in the same state, awaiting a new
event.
<br>
<br>
pluto is event based. State changes happen as a result of an
event. This
<br>
could be receiving a packet, a timer based event, or our
select() call
<br>
receiving an event (eg crypto helper ready, whack command on
socket)
<br>
<br>
The terms I and R in MAIN_I1 or AGGR_R2 stands for the mode
(main mode,
<br>
aggressive mode, quick mode, etc) followed by the I for
initiator states
<br>
and R for responder states, followed by the packet number.
Functions
<br>
related to the state have names that signify what comes in, and
what
<br>
goes out, so aggr_inI2_outR2() is called only when the state is
in
<br>
Aggressive mode R1, and we are waiting to receive the second
packet from
<br>
the initiator, upon which we will send out the second packet as
<br>
responder and move into the Aggr R2 state (which if you would
look at
<br>
the state table, would be expecting a Quick Mode I1 packet)
<br>
<br>
md is the message digest, the stream of bytes from the incoming
packet.
<br>
It contains the IKE (ISAKMP) header of the incoming packet. The
IKE header
<br>
of the incoming packet contains a flag stating whether or not
the packet
<br>
is encrypted. So for each state in the state machine, we compare
the
<br>
received "encryption flag" (md->hdr.isa_flags &
ISAKMP_FLAG_ENCRYPTION)
<br>
with the expected state machine "encryption flag"
(SMF_INPUT_ENCRYPTED)
<br>
<br>
The ROOF and LELEM are constructs designed by Hugh Redelmeier to
ease
<br>
the checking of certain flags and switch cases. You normally
iterate
<br>
until you hit the ROOF. If you hit the ROOF, it means what that
what
<br>
you were looking for was not found. ROOF is like "maximum". I
find the
<br>
construct of LELEM complicated, it is deeply depending on
MACRO's. I
<br>
should have an explanation by Hugh somewhere in old email that I
can try
<br>
to find for you at a later date. So I cannot tell you right now
how the
<br>
construct of LELEM works with a ROOF + value, but I am fairly
confident
<br>
that the code is correct. Perhaps Hugh can elaborate further.
<br>
<br>
As stated in my answers on the list, I am pretty sure the
"encrypted"
<br>
versus "unencrypted" messages are due because of a disagreement
between
<br>
the parameters of the connection. Because this is Aggressive
Mode, and
<br>
exchanging parameters and Diffie-Hellman happen concurrently
(unlike in
<br>
Main Mode where DH is completed before parameters are exchanged,
but it
<br>
takes double the number of packets exchanged, so has double the
<br>
latency in establishing the connection)
<br>
<br>
One could argue a new state in the state machine could be made
where we
<br>
can go and receive an unencrypted message, and parse the
notification
<br>
payload. This state would not allow to move into Aggr R2.
<br>
<br>
But we are remaining in the same state because we could still
receive a
<br>
properly encrypted message. An unencrypted message could be send
by an
<br>
attacker to mislead us, so we cannot make any state machine
changes based
<br>
on such an unsecured packet that could have been spoofed. So we
log it,
<br>
and remain waiting for a proper packet that complies with the
RFCs as
<br>
implemented in our state machine. This is likely signaled by the
<br>
function returning STF_IGNORE (I did not look it up)
<br>
<br>
Paul
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>