Subject: [eap] RE: Issue XXX: Potential deadlock

From: [email-masked] ([email-masked])
Date: Tue, 13 May 2003 10:44:17 +0300

Lauri Tarkkala wrote:

> Assume we have two PPP peers (A and B) negotating LCP, and both
> desire to authenticate each other with EAP. A authenticates B
> with EAP and B authenticates A with EAP.
>=20
> Now assume that both EAP Success messages are "lost" after the
> authentication rounds are completed, and since both parties
> now have an EAP authentication pending, they will not
> start negotiating a NCP (e.g. IPCP) for the link. The
> system is effectively in deadlock.

I think this situation is not any different from the one-way
case. 2284bis already mentions that Success and Failure packets
are not acknowledged, and thus timeouts are possible if the link
has high error rate.

Consider a single EAP conversation where the Success packet is
lost. This results in a timeout for the peer. If the peer is
happy with the overall situation (e.g. it would enable the link
if it received a Success packet), it may enable the link anyway
(initiate NCP in case of PPP).

In case of two simultaneous EAP conversations, the PPP
connection will succeed if both parties follow this
behavior. Also, the party that has longer timeout may consider=20
a NCP packet as "lower layer success indication", and process=20
it appropriately (if we allow lower layer success indications,=20
as I proposed in my previous message).

(The EAP implementations are not in a true deadlock, because
on both parties, one of the EAP conversations has already
ended, and the conversation instance that is "dangling" is=20
not waiting for anything from the other "dangling" instance).

Best regards,
Pasi

---

From: [email-masked] (Jari Arkko)
Date: Tue, 13 May 2003 10:49:05 +0300

> are not acknowledged, and thus timeouts are possible if the link
...
> ended, and the conversation instance that is "dangling" is 

Yes, I think that is right.

Lauri Tarkkala wrote:

> Note that the lack of an explicit ACK of success means that 
> it is difficult in this case to distinguish between
> "sequential authentication" where several methods are
> applied after each other and a dropped EAP-Success.

That's right, but we've discouraged the use of sequences.
So I don't think this is an issue.

--Jari

---

From: [email-masked] (Lauri Tarkkala)
Date: Tue, 13 May 2003 10:43:47 +0300

> are not acknowledged, and thus timeouts are possible if the link

Ok. We have a different opinion under what circumstances the
protocol run should succeed. Please note that PPP (LCP, NCP, CHAP, etc)
can easily succeed in conditions where a couple of packets are lost,
even in the absence of "lower layer indications".

The case is not that different from the one-way case, as you
suggest. I used the term "dead-lock" quite loosely, as you pointed
out. The system will recover with a timeout, and terminate
the link and possible re-try authentication, but this is
essentially a reset and re-run of the protocol (with
some additional headache for the user).

> behavior. Also, the party that has longer timeout may consider 

Indeed. Assuming both implementations are good and have been
written by people who have at least some understanding of
concurrent systems. You'd be surprised at the quality of EAP/PPP
implementations in wide use today.

Please remember, that an EAP implementation written according
to the "improved" specs, must interoperate with the implementations
written according to the "classic" specs, and in this case, the
sane behaviour is to consider the "send of the last response"
by the authenticatee to the EAP authenticator to be the
"lower layer indication".

> a NCP packet as "lower layer success indication", and process 
> it appropriately (if we allow lower layer success indications, 

"Lower layer success indications" are what currently any decent
EAP/PPP implementation uses to determine authentication success,
what this "success indication" is, may then differ. What
this does however, is build a dependency into the EAP protocol
that "reliable half-duplex lower layer success indications"
should be used in some cases. i

This is a behaviour I'd like to live without, but I can accept as
"historical baggage". Anyways, their use must be specified, like
Assuming that the WG now feels that lower layer indications should
be considered here, I propose the following changes:

Add to section 3.1

[6] If EAP is used authenticate the peers communicating over a lower
    layer that does not provide reliable transport then because of
    the unreliable EAP-Success/EAP-Failure messages:

    - If the lower layer provides an indication mechanism that the
      authenticator has accepted the authenticatee then this SHOULD
      be used to complement the EAP-Success message, and the
      authenticatee MUST consider this indication as equivalent to an
      EAP-Success message. Note that both peers might be authenticating
      each other with EAP.

    - If the lower layer does not provide a sufficiently reliable
      indication mechanism, then the authenticatee should consider
      a suitable timeout (e.g. 2*RTT of link) after the last sent
      EAP message to be equivalent to an EAP-Success and rely on
      other used protocols for indications of link failure.

Add to section 3.4

 If an unreliable transmission medium is used, s.t. delivery of the
 EAP-Success packet is not guaranteed under reasonable assumptions
 of link quality AND link layer mechanisms exist for indicating
 that the authenticator has decided that protocol can proceed past
 the authentication phase THEN these mechanisms MUST be used 
 to signal that authentication has succeeded. See point [6] in 
 Section 3.1.

Note that this does not define the lower-layer mechanism to be used,
in case it is ambiguous and the term "lower-layer" is even a bit
mis-leading. E.g. in the case of PPP/EAP there is really no "lower-layer
mechanism", but a willingess to initiate or respond to NCP negotiations
is considered an "indication of authentication success". The term 
"lower layer indication" is a bit mis-leading, but the above changes
fit best into the -02 draft.

This will mean that if future EAP/PPP implementations are written to wait
for "link layer indication" before proceeding, then they may in some
link conditions fail to interopate. I can certainly live with this.

Lauri

-- 
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/