Subject: [eap] Ordered delivery of EAP messages

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 6 Mar 2007 00:49:25 -0800

RFC 3748, section 3.1 says

   [6] Ordering guarantees.  EAP does not require the Identifier to be
       monotonically increasing, and so is reliant on lower layer
       ordering guarantees for correct operation.  EAP was originally
       defined to run on PPP, and [RFC1661] Section 1 has an ordering
       requirement:

           "The Point-to-Point Protocol is designed for simple links
           which transport packets between two peers.  These links
           provide full-duplex simultaneous bi-directional operation,
           and are assumed to deliver packets in order."

       Lower layer transports for EAP MUST preserve ordering between a
       source and destination at a given priority level (the ordering
       guarantee provided by [IEEE-802]).

       Reordering, if it occurs, will typically result in an EAP
       authentication failure, causing EAP authentication to be re-run.
       In an environment in which reordering is likely, it is therefore
       expected that EAP authentication failures will be common.  It is
       RECOMMENDED that EAP only be run over lower layers that provide
       ordering guarantees; running EAP over raw IP or UDP transport is
       NOT RECOMMENDED.  Encapsulation of EAP within RADIUS [RFC3579]
       satisfies ordering requirements, since RADIUS is a "lockstep"
       protocol that delivers packets in order.

My question is, since EAP is also a lockstep protocol, under what
conditions could EAP messages be delivered out of order, regardless of
lower layer behavior WRT in-order delivery?
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: <[email-masked]>
Date: Tue, 6 Mar 2007 11:46:03 +0200

Glen Zorn wrote:

> conditions could EAP messages be delivered out of order, regardless
> of lower layer behavior WRT in-order delivery?

This was discussed as part of issue 188 a very long time ago :)
Back then (October 2003), I wrote:

  Lower layer ordering guarantees are needed because the Identifier
  field is not required to be ordered. If messages can be reordered,
  the peer can't necessarily distinguish a new EAP Request from a
  reordered retransmission of an old request.

  See http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-02.txt, 
  Appendix A for a concrete example. 

Best regards,
Pasi

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Mar 2007 05:27:19 -0800

The primary situation is one where the RTO maintained by the authenticator 
is under-estimated, and an
EAP-Request has been retransmitted.

In this situation, an EAP-Response could arrive in response to a previous 
EAP-Request (e.g. a false retransmission occurred).   The authenticator will 
move on, choosing a new Identifier for the next EAP-Request.  This leaves 
two EAP-Requests in flight, and they could conceivably cross paths.

If the new EAP-Request arrives before the retransmitted one, when the 
retransmitted EAP-Request finally arrives, it will be taken as a new 
EAP-Request, which could disrupt the authentication in progress.

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 6 Mar 2007 06:21:39 -0800

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on Tuesday, March 06, 2007 5:27 AM:

> The primary situation is one where the RTO maintained by the
> authenticator is under-estimated, and an EAP-Request has been
> retransmitted.  
> 
> move on, choosing a new Identifier for the next EAP-Request.  This
> leaves two EAP-Requests in flight, and they could conceivably cross
> paths.  
> 

I've recently been reminded that I can be a bit too terse at times; it appears that this is one of those times.  I blame MO ;-).  Anyway, part of RFC 3748 that I quoted says 

       Encapsulation of EAP within RADIUS [RFC3579]
       satisfies ordering requirements, since RADIUS is a "lockstep"
       protocol that delivers packets in order.

There are a couple of problems with this statement that I think are pertinent to the question at hand.  First, RADIUS is a "lockstep" protocol in almost (if not exactly) the same way that EAP is: the semantics of the Identifier field in the header of RADIUS messages are identical to that of the EAP version (RFC 2865 only says that the Identifier must change on new requests, not how it must change -- in particular, monotonicity is not assured) and requests are retransmitted.  The other problem is that neither RADIUS nor the underlying UDP transport guarantees in-order delivery of packets.  So, I would claim that this sentence is completely false and, given that, the rest of the preceding argument vis-à-vis the ordered delivery of EAP packets is rendered of theoretical interest at best since there is a certain amount of empirical evidence that both RADIUS and EAPoRADIUS work, despite all.

>> This was discussed as part of issue 188 a very long time ago :) Back
>> then (October 2003), I wrote: 
>> 
>>   See
>>   http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-02.txt,

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Mar 2007 06:34:43 -0800

Glen Zorn said:

"There are a couple of problems with this statement that I think are 
pertinent to the question at hand.  First, RADIUS is a "lockstep" protocol 
in almost (if not exactly) the same way that EAP is: the semantics of the 
Identifier field in the header of RADIUS messages are identical to that of 
the EAP version (RFC 2865 only says that the Identifier must change on new 
requests, not how it must change -- in particular, monotonicity is not 
assured) and requests are retransmitted.  The other problem is that neither 
RADIUS nor the underlying UDP transport guarantees in-order delivery of 
packets.  So, I would claim that this sentence is completely false."

I think you are correct.  If the RADIUS retransmission timer were 
under-estimated, RADIUS can deliver EAP messages out of order.  That is, the 
  NAS could retransmit an Access-Request, and then could receive an 
Access-Challenge in response to an earlier Access-Request.  The NAS would 
then send a new Access-Request, which could cross paths with the 
retransmitted one.

Note that if an Event-Timestamp attribute were to be included in the RADIUS 
Access-Request, then the Identifier would change on the retransmitted 
Access-Request.  The NAS would then be able to determine that a False 
Retransmission (FRTO) had occurred.  But from the point of view of the 
RADIUS server, I don't think it matters, since it won't be checking that the 
Event-Timestamp attribute is monotonically increasing.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 6 Mar 2007 20:09:39 +0200

The problem scenario requires EAP-layer retransmission, correct?
Authentication server does not perform such retransmission. So, I don't see
equivalence between the two legs of the EAP transport.

Alper

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2007 4:35 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [eap] Ordered delivery of EAP messages
> 
> Glen Zorn said:
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Mar 2007 10:24:41 -0800

RADIUS could conceivably reorder packets even where there is no EAP 
retransmission.

This would seem to be most likely in trans-continental roaming scenarios 
where the RTTs could be quite large, and the RADIUS RTO is set low (e.g. a 
second or less) without backoff.

Trans-continential roaming test have shown very high failure rates for EAP 
conversations with lots of roundtrips, so I wouldn't be surprised if this 
issue was showing up in real networks.

One way to make this less likely would be for the NAS to detect FRTO via 
Event-Timestamp & Identifier change, and then wait until sending a new 
Access-Request, to allow the retransmitted Access-Request to drain from the 
network.

Alper said:

---

From: Peter Deacon <[email-masked]>
Date: Tue, 6 Mar 2007 11:30:12 -0800 (Pacific Standard Time)

> RADIUS could conceivably reorder packets even where there is no EAP

Assuming that per session there can only be one outstanding request for an 
EAP conversation since the conversation depends on acks from its peer to 
continue.

Then if new messages and retries are sent out in any order on the wire 
they would either be detected by either side as duplicates or processed 
and handled accordingly regardless of order of receipt.

take care,
Peter

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Mar 2007 12:50:09 -0800

>EAP conversation >since the conversation depends on acks from its peer to 
>continue.

ACK/NAK protocols can have more than one packet in flight, if you take false 
retransmissions into account.

>Then if new messages and retries are sent out in any order on the wire they 
>would either be detected by either side as duplicates or processed and 
>handled accordingly regardless of order of receipt.

Both EAP and RADIUS do not detect duplicates arriving out of order; they 
depend on the underlying lower layer to provide in-order delivery so as to 
enable duplicate detection.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 7 Mar 2007 01:24:52 +0200

> enable duplicate detection.

RFC 2865 says:

      The RADIUS server can detect a duplicate request if
      it has the same client source IP address and source UDP port and
      Identifier within a short span of time.

This, to me, implies duplicate detection on the server side does not rely on
orderly delivery. Keeping the history for "a short span of time" allows
duplicate detection irrespective of the order the requests come in.

As for the responses... Assuming the RADIUS client transmitted a request
twice (first one timed out), if it receives one of the responses, would it
still accept the second (duplicate) response if it arrives as well? Wouldn't
the RADIUS client just drop the second response because there is no
outstanding request to match anymore?

Alper

---

From: Peter Deacon <[email-masked]>
Date: Tue, 6 Mar 2007 13:31:46 -0800 (Pacific Standard Time)

> enable duplicate detection.

A RADIUS server can detect a packet it has already responded to and 
respond if it wishes with a stored response.

A false retranmission by a NAS is detectable by the RADIUS server.

The difference between request and packet is significant in this context.

What I'm saying is in any given RADIUS+EAP exchange there is head-of-line 
condition that prevents two or more unacknowledge requests or responses 
that are *not detectable* by the RADIUS server.  At any given instant one 
or more duplicates may already be known to the RADIUS server and buzzing 
around the wires however only exactly zero or one new requests can be 
outstanding (not known to the RADIUS server)

take care,
Peter

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 6 Mar 2007 15:44:49 -0800

Alper Yegin <mailto:[email-masked]> allegedly scribbled on

> The problem scenario requires EAP-layer retransmission, correct?

Yes, I suppose so.

> Authentication server does not perform such retransmission. 

>From the Abstract to RFC 3748 "EAP provides its own support for
duplicate elimination and retransmission..."; the Authenticator is
responsible for all retransmission.

> So, I
> don't see equivalence between the two legs of the EAP transport. 

You are imagining that there are always 2 legs, which is not true; the
quoted portion of RFC 3748 does not state that assumption, either.  But
actually, you are right: it appears that RADIUS would generally be in
far greater peril of the risk then EAP, especially in a proxied network.

>> pertinent to the question at hand.  First, RADIUS is a "lockstep"
>> protocol in almost (if not exactly) the same way that EAP is: the
>> semantics of the Identifier field in the header of RADIUS messages
>> are identical to that of the EAP version (RFC 2865 only says that the
>> Identifier must change on new requests, not how it must change -- in
>> particular, monotonicity is not
>> assured) and requests are retransmitted.  The other problem is that
>> neither RADIUS nor the underlying UDP transport guarantees in-order
>> delivery of packets.  So, I would claim that this sentence is
>> completely false." 
>> 
>> under-estimated, RADIUS can deliver EAP messages out of order.  That
>>   is, the NAS could retransmit an Access-Request, and then could
>> receive an Access-Challenge in response to an earlier
>> Access-Request.  The NAS would then send a new Access-Request, which
>> could cross paths with the retransmitted one. 
>> 
>> Note that if an Event-Timestamp attribute were to be included in the
>> RADIUS Access-Request, then the Identifier would change on the
>> retransmitted Access-Request.  The NAS would then be able to
>> determine that a False Retransmission (FRTO) had occurred.  But from
>> the point of view of the RADIUS server, I don't think it matters,
>> since it won't be checking that the Event-Timestamp attribute is
>> monotonically increasing. 
>> 
>>

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 6 Mar 2007 21:13:59 -0500

Unless I am missing something most of the converstaion so far has been
related to efficiency.  That is, if the transport layer provides inorder
delivery the EAP works well.

I think we need to answer this question first:

Does EAP require to have inorder delivery to work correctly.  By work
correctly I mean that it does not falsely authenticate someone.

Can someone show how EAP falsely authenticate someone if packets arrive
in arbitrary order.

If this cant be shown the inorder delivery is not a MUST but a nice to
have feature of the transport layer and the statement in the RFC should
be changed from a MUST to a SHOULD.

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 6:45 PM
To: Alper Yegin; Bernard Aboba; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [eap] Ordered delivery of EAP messages

Yes, I suppose so.

>> receive an Access-Challenge in response to an earlier Access-Request.

>> The NAS would then send a new Access-Request, which could cross paths

>> with the retransmitted one.
>>

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 6 Mar 2007 21:21:15 -0500

As a follow on to my previous email message

If an EAP method designer designed their method assuming the in order
delivery of packets then this would be a bad thing I think.

A hacker could then exploit this assumption by re-order the packets.
Surely EAP methods are not susceptible to this type of attack. Right?  

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 9:14 PM
To: Glen Zorn (gwz); Alper Yegin; Bernard Aboba; [email-masked];
[email-masked]

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]]
Sent: Tuesday, March 06, 2007 6:45 PM
To: Alper Yegin; Bernard Aboba; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [eap] Ordered delivery of EAP messages

Yes, I suppose so.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Mar 2007 20:42:43 -0800

Avi Lior said:

"If an EAP method designer designed their method assuming the in order
delivery of packets then this would be a bad thing I think.

A hacker could then exploit this assumption by re-order the packets.
Surely EAP methods are not susceptible to this type of attack. Right?"

Certainly, it is a good thing for an EAP method to protect itself against 
replay.  Using the mechanism provided in RFC 3579, an EAP method could 
discard replayed packets and ask the NAS to send another one.

On the other hand, there are EAP methods that are not protected against 
replay (e.g. Identity, Notification, etc.).  There are also situations in 
which EAP packets can be fragmented, and if reassembled in the wrong order, 
this could cause failure of the MIC which can be a terminal error (e.g. in 
TLS-based methods).

So overall, I don't think that the majority of EAP methods deployed today 
are capable of handling arbitrary reordering.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Mar 2007 20:54:36 -0800

>duplicate detection irrespective of the order the requests come in.

That advice seems sensible; if implemented, I think it would address the 
FRTO scenarios we have been discussing, wouldn't it?  Given client backoff, 
it seems highly unlikely that an Access-Request would be reordered outside 
of a "short span of time" (e.g. say, 1 minute).

>outstanding request to match anymore?

Yes, I think that the RADIUS client will drop a duplicate response.  The 
problem occurs more on the RADIUS server side, where the server could 
potentially send an Access-Reject if it wasn't doing duplicate detection as 
referred to above, and as a result the EAP method got mixed up.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Mar 2007 21:09:50 -0800

>I've recently been reminded that I can be a bit too terse at times; it 
>appears that this is one of >those times.  I blame MO ;-).  Anyway, part of 
>RFC 3748 that I quoted says
>
>There are a couple of problems with this statement that I think are 
>pertinent to the question at >hand...

Given the discussion, it would appear to me that RADIUS does provide for 
ordering and non-duplicate delivery of EAP packets, although the "lockstep" 
aspect is not as important as the following statement from RFC 2865, Section 
3:

"The RADIUS server can detect a duplicate request if it has the same client 
source IP address and source UDP port and Identifier within a short span of 
time."

Therefore, assuming that the replay window is large enough in proportion to 
the RTT, and the NAS RTO estimate is in the ballpark and being backed off, 
then it seems like the problem is covered.

Or am I missing something?

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 6 Mar 2007 21:32:13 -0800

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on
Tuesday, March 06, 2007 9:10 PM:

>> I've recently been reminded that I can be a bit too terse at times;
>> it appears that this is one of >those times.  I blame MO ;-). 
>> Anyway, part of RFC 3748 that I quoted says
>> 
> Given the discussion, it would appear to me that RADIUS does provide
> for ordering and non-duplicate delivery of EAP packets, 

Ordered delivery & duplicate rejection aren't the same thing.  

> although the
> "lockstep"  
> aspect is not as important as the following statement from RFC 2865,
> Section 3:
> 
> "The RADIUS server can detect a duplicate request if it has the same
> client source IP address and source UDP port and Identifier within a
> short span of time."  
> 
> Therefore, assuming that the replay window is large enough in
> proportion to the RTT, and the NAS RTO estimate is in the ballpark
> and being backed off, then it seems like the problem is covered.  
> 

Suppose that the conditions you specify are met for the EAP peer and
authenticator, as well.  Does that solve the problem?
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 6 Mar 2007 22:16:54 -0800

Alper Yegin <> allegedly scribbled on Tuesday, March 06, 2007 3:25 PM:

>> Both EAP and RADIUS do not detect duplicates arriving out of order;
>> they depend on the underlying lower layer to provide in-order
>> delivery so as to enable duplicate detection.
> 
> RFC 2865 says:
> 
> This, to me, implies duplicate detection on the server side does not
> rely on orderly delivery. Keeping the history for "a short span of
> time" allows duplicate detection irrespective of the order the
> requests come in.   

Agree.

> 
> As for the responses... Assuming the RADIUS client transmitted a
> request twice (first one timed out), if it receives one of the
> responses, would it still accept the second (duplicate) response if
> it arrives as well? Wouldn't the RADIUS client just drop the second
> response because there is no outstanding request to match anymore?  

Seems reasonable.  So why wouldn't this reasoning apply to EAP as well?

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 07 Mar 2007 00:04:02 -0800

>Ordered delivery & duplicate rejection aren't the same thing.

In general, that's true.  But if you have an ACK/NAK protocol that only 
allows a single packet in flight other than retransmissions, doesn't 
effective duplicate rejection imply ordered delivery?

>authenticator, as well.  Does that solve the problem?

If EAP were to implement duplicate rejection within a short time window, yes 
that would solve the problem.  We discussed this during the development of 
RFC 3748, partly out of the desire to reconcile EAP with IEEE 802.1X-2001 
which utilized a monotonically increasing Identifier field.  During that 
discussion we found that there were EAP implementations (such as the Solaris 
version, as I recall) that did not implement a duplicate rejection window.  
That is how the ordering guarantee found its way into RFC 3748, so as to 
guarantee that those implementations would work.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 7 Mar 2007 13:38:30 +0200

> Seems reasonable.  So why wouldn't this reasoning apply to EAP as well?

With the appropriate normative text in the RFC covering both end points this
could be used. But we don't have such text in RFC 3748.

Alper

> Sent: Wednesday, March 07, 2007 8:17 AM
> To: Alper Yegin; Bernard Aboba; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [eap] Ordered delivery of EAP messages
>

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 7 Mar 2007 11:40:39 -0500

Bernard,

You said: 

"So overall, I don't think that the majority of EAP methods deployed
today are capable of handling arbitrary reordering."

Okay, but what is the result when this occurs, would this result in an
Unauthenticateable user to be Authenticated?

If NOT, then EAP Methods do not require in order delivery by the
underlying transport(s) to give results that are secure.

In order delivery is desirable for optimal performance -- an
Authenticateble user getting authenticated without having to retry the
method.

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 11:43 PM
To: Avi Lior; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [eap] Ordered delivery of EAP messages

Avi Lior said:

Certainly, it is a good thing for an EAP method to protect itself
against replay.  Using the mechanism provided in RFC 3579, an EAP method
could discard replayed packets and ask the NAS to send another one.

On the other hand, there are EAP methods that are not protected against
replay (e.g. Identity, Notification, etc.).  There are also situations
in which EAP packets can be fragmented, and if reassembled in the wrong
order, this could cause failure of the MIC which can be a terminal error
(e.g. in TLS-based methods).

So overall, I don't think that the majority of EAP methods deployed
today are capable of handling arbitrary reordering.

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 7 Mar 2007 11:53:40 -0500

I think this is an interesting discussion on RADIUS but we seem to have
diverted from the original question posed.

RFC 3748, section 3.1 says:

[6] Ordering guarantees.  EAP does not require the Identifier to be 
       monotonically increasing, and so is reliant on lower layer 
       ordering guarantees for correct operation. 

I don't think that the "MUST" above is true! 

A little further down it says:

"It is RECOMMENDED that EAP only be run over lower layers that provide 
ordering guarantees; "

Isn't that a requirement contradiction of the previous statement, or am
I missing something?

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 11:55 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [eap] Ordered delivery of EAP messages

>time" allows duplicate detection irrespective of the order the requests

>come in.

That advice seems sensible; if implemented, I think it would address the
FRTO scenarios we have been discussing, wouldn't it?  Given client
backoff, it seems highly unlikely that an Access-Request would be
reordered outside of a "short span of time" (e.g. say, 1 minute).

>responses, would it still accept the second (duplicate) response if it
arrives as well?
>Wouldn't

Yes, I think that the RADIUS client will drop a duplicate response.  The
problem occurs more on the RADIUS server side, where the server could
potentially send an Access-Reject if it wasn't doing duplicate detection
as referred to above, and as a result the EAP method got mixed up.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 07 Mar 2007 14:42:30 -0500

> Authenticateble user getting authenticated without having to retry the

Orderly delivery is required for authenticable user to be
authenticated.  Without orderly delivery, authentication for
authenticable user can fail even if (i) EAP and lower layer are doing
their jobs correctly as specified in their specifications, (ii) valid
credentials are being used and (iii) there is no attacking.  From
operational perspective, this is something that should not happen, IMO.

Yoshihiro Ohba

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 7 Mar 2007 15:41:31 -0500

Hi Yoshi

Very good so an authenticatble user will not be authenticated.
Understood.

But you didn't answer the first part -- which is the key part.  If you
had unordered delivery of packets, could an unAuthenticatble user be
authenticated? 

If the answer to this question is NO, then EAP does not require in order
delivery of packets and RFC 3748 has an error.

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 2:43 PM
To: Avi Lior
Cc: Bernard Aboba; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [eap] Ordered delivery of EAP messages

> method.

Orderly delivery is required for authenticable user to be authenticated.
Without orderly delivery, authentication for authenticable user can fail
even if (i) EAP and lower layer are doing their jobs correctly as
specified in their specifications, (ii) valid credentials are being used
and (iii) there is no attacking.  From operational perspective, this is
something that should not happen, IMO.

Yoshihiro Ohba

> against replay.  Using the mechanism provided in RFC 3579, an EAP 
> method could discard replayed packets and ask the NAS to send another
one.
> 
> On the other hand, there are EAP methods that are not protected 
> against replay (e.g. Identity, Notification, etc.).  There are also 
> situations in which EAP packets can be fragmented, and if reassembled 
> in the wrong order, this could cause failure of the MIC which can be a

> terminal error (e.g. in TLS-based methods).
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 07 Mar 2007 16:05:06 -0500

Hi Avi,

> had unordered delivery of packets, could an unAuthenticatble user be

I have been thinking about this, and so far I have not found an
example case of unauthenticatble user be authenticated when
misordering happens.  The answer is "I don't know."

> delivery of packets and RFC 3748 has an error.

I am not sure what makes you conclude like this.  I don't want my
authentication attempt to fail just because IP packets are arriving
out of order.

Yoshihiro Ohba

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 7 Mar 2007 16:35:19 -0500

Okay Yoshi fair enough.  But that is the most important question to
answer.

Because if the answer is YES.  Then it means that despite the best
effort of EAP method designers, a man in the middle could simply
re-order packets and get authenticated.  If true, this has got to be the
weak point of EAP.  I don't think its true or I hope that its not true.
The IETF will have egg on its face.

So the other part of my question on another thread is the issue with the
contradiction in 3748

RFC 3748, section 3.1 says: [6] Ordering guarantees.  

Isn't that a requirement contradiction of the previous statement, or am
I missing something? Do you have any opinions on this?

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 4:05 PM
To: Avi Lior
Cc: Yoshihiro Ohba; Bernard Aboba; [email-masked]; [email-masked];

Hi Avi,

> had unordered delivery of packets, could an unAuthenticatble user be 

I have been thinking about this, and so far I have not found an example
case of unauthenticatble user be authenticated when misordering happens.
The answer is "I don't know."

> 
> If the answer to this question is NO, then EAP does not require in 
> order delivery of packets and RFC 3748 has an error.

I am not sure what makes you conclude like this.  I don't want my
authentication attempt to fail just because IP packets are arriving out
of order.

Yoshihiro Ohba

> Orderly delivery is required for authenticable user to be
authenticated.
> Without orderly delivery, authentication for authenticable user can 
> fail even if (i) EAP and lower layer are doing their jobs correctly as

> specified in their specifications, (ii) valid credentials are being 
> used and (iii) there is no attacking.  From operational perspective, 
> this is something that should not happen, IMO.
> 
> Yoshihiro Ohba
> 
> 
> > 
> > 
> > situations in which EAP packets can be fragmented, and if 
> > reassembled in the wrong order, this could cause failure of the MIC 
> > which can be a
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 07 Mar 2007 19:14:37 -0500

I agree that there is some ambiguity, but I'd rather think that the
RECOMMENDED part should be a MUST from operational perspective, not
the other way around.

Yoshihiro Ohba

On Wed, Mar 07, 2007 at 11:53:40AM -0500, Avi Lior wrote:
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 
>

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Wed, 7 Mar 2007 18:01:26 -0800

Alper Yegin <mailto:[email-masked]> allegedly scribbled on
Wednesday, March 07, 2007 3:39 AM:

> With the appropriate normative text in the RFC covering both end
> points this could be used. But we don't have such text in RFC 3748. 

OK, so what is the real purpose of the Identifier in EAP?  I would have
thought that this would be one:

   [5] Possible duplication.  Where the lower layer is reliable, it will
       provide the EAP layer with a non-duplicated stream of packets.
       However,  while it is desirable that lower layers provide for
       non-duplication, this is not a requirement.  The Identifier field
       provides both the peer and authenticator with the ability to
       detect duplicates.

But I'm hearing that this is N/A because somebody didn't bother to
implement it...

>>>       it has the same client source IP address and source UDP port
>>>       and Identifier within a short span of time.
>>>

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Wed, 7 Mar 2007 19:08:31 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Wednesday, March 07, 2007 1:05 PM:
...
>> But you didn't answer the first part -- which is the key part.  If
>> you had unordered delivery of packets, could an unAuthenticatble
>> user be authenticated?
> 

Just to be clear, we're talking about EAP packets here, not IP packets.

>> authenticable user can fail even if (i) EAP and lower layer are
>> doing their jobs correctly as specified in their specifications,
>> (ii) valid credentials are being used and (iii) there is no
>> attacking.  From operational perspective, this is something that
>> should not happen, IMO. 
>> 
>> Yoshihiro Ohba
>> 
>> 
>>> 
>>>

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Wed, 7 Mar 2007 19:22:20 -0800

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on
Wednesday, March 07, 2007 12:04 AM:

> In general, that's true.  But if you have an ACK/NAK protocol that
> only allows a single packet in flight other than retransmissions,
> doesn't effective duplicate rejection imply ordered delivery? 

Perhaps.  Unfortunately, RADIUS does not require duplicate detection.
This is what RFC 2865 says about duplicate detection: "The RADIUS server
can detect a duplicate request if it has the same client source IP
address and source UDP port and Identifier within a short span of time."
That's it.  I don't see the word "MUST" (or even "SHOULD") in that
sentence.  In fact, RFC 3748 is actually a bit stronger on the topic
(Section 4.1): "The peer is responsible for detecting and handling
duplicate Request messages before processing them in any way, including
passing them on to an outside party.  The authenticator is also
responsible for discarding Response messages with a non-matching
Identifier value before acting on them in any way, including passing
them on to the backend authentication server for verification." 

...

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Wed, 7 Mar 2007 19:26:55 -0800

Alan DeKok <mailto:[email-masked]> allegedly scribbled on
Wednesday, March 07, 2007 5:45 AM:

> Alper Yegin wrote:
>   Yes.  All well-behaved RADIUS servers do this.  RADIUS servers that
> *don't* do this can led to believe that a user has logged in twice,
> when the second attempt was just a duplicate. 
> 
>> it arrives as well? 
>   What do you mean "accept"?  The client has already had a response
> to the first transmission.  The only safe thing to do here is to
> silently discard the response to the re-transmitted request. 
> Ideally, this case SHOULD be separated from the case of unsolicited
> or spoofed "replies" by the client also caching requests for a period
> of time.     
> 
>> Wouldn't
>   That is the safest thing to do, yes.

All of these things make total sense but AFAICT none are actually
mandated by RFC 2865. 

>   Alan DeKok.

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 7 Mar 2007 23:10:13 -0500

Yoshi

Please see inline.... 

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 2:43 PM
To: Avi Lior
Cc: Bernard Aboba; [email-masked]; [email-masked];

[Avi] Correct.

[Avi] I agree.  Yes and RFC 3748 addresses that already and makes a
recommendation that the transport layer should provide inorder delivery.
But it is an entirely different matter to require in order delivery.
The point again and again is that in order delivery by the transport
layer is NOT required for Correct Secure operation of EAP.  EAP Method
need to take care of that aspect themselves they should not delegate
that responsibility to the transport layer.

Yoshihiro Ohba

one.

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 7 Mar 2007 23:11:35 -0500

I don't agree that the RECOMMENDED part should be a MUST. 

You have to prove that this property is required for Correct Secure
Operation.  

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 7:15 PM
To: Avi Lior
Cc: Bernard Aboba; [email-masked]; [email-masked];
[email-masked]

I agree that there is some ambiguity, but I'd rather think that the
RECOMMENDED part should be a MUST from operational perspective, not the
other way around.

Yoshihiro Ohba

On Wed, Mar 07, 2007 at 11:53:40AM -0500, Avi Lior wrote:
> I think this is an interesting discussion on RADIUS but we seem to 
> have diverted from the original question posed.
> 

> ordering guarantees; "
> 
> Isn't that a requirement contradiction of the previous statement, or 
> am I missing something?
> 
> 
> 
and
> >requests
> That advice seems sensible; if implemented, I think it would address 
> the FRTO scenarios we have been discussing, wouldn't it?  Given client

> >it
> Yes, I think that the RADIUS client will drop a duplicate response.  
> The problem occurs more on the RADIUS server side, where the server 
> could potentially send an Access-Reject if it wasn't doing duplicate 
> detection as referred to above, and as a result the EAP method got
mixed up.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 7 Mar 2007 20:39:24 -0800 (Pacific Standard Time)

> You have to prove that this property is required for Correct Secure

Sec 1.3 says:

    EAP is a lock-step protocol which only supports a single packet in
    flight.  As a result, EAP cannot efficiently transport bulk data,
    unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960].

    While EAP provides support for retransmission, it assumes ordering
    guarantees provided by the lower layer, so out of order reception is
    not supported.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 8 Mar 2007 00:20:17 -0500

> You have to prove that this property is required for Correct Secure

This is what I don't understand.  Correctness and security are two
separate things.

I can show you a typical example, TLS.  TLS requires reliable
transport for its correct operation.  Without use of reliable
transport, TLS session will be immediately shutdown when a packet is
lost, but it is still secure.  This does not mean that TLS requires
reliable transport for its secure operation.

Note that DTLS does not require reliable transport, because it
modifies TLS to correcly work over unreliable transport.

For the same reason, if we want to remove the orderly delivery
requirement from EAP, we would need to modify EAP to correctly work
with non-orderly delivery.

Yoshihiro Ohba

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Wed, 7 Mar 2007 22:15:24 -0800

> with non-orderly delivery.  

My basic argument is that EAP _does_ work over a transport that doesn't
guarantee in-order delivery (the example being RADIUS) except in a deep,
dark, cobweb-filled corner case.  The arguments have been that
"well-behaved" RADIUS implementations exhibit what amounts to in-order
delivery despite the fact that it is not required by the RFCs but badly
behaved EAP implementations will fail in a contrived, pathological case.
I am saying that a badly-behaved RADIUS implementation would fail in
that same pathological case and the converse.

>> [email-masked] Subject: Re: [eap] Ordered delivery of EAP messages
>> 
>>>        source and destination at a given priority level (the
>>>        ordering guarantee provided by [IEEE-802]).
>>> 
>>> Isn't that a requirement contradiction of the previous statement,
>>> or am I missing something? 
>>> 
>>> 
>>> 
>>>> This, to me, implies duplicate detection on the server side does
>>>> not rely on orderly delivery. Keeping the history for "a short span
>>>> of time" allows duplicate detection irrespective of the order the
>>>> requests
>>> 
>>>> come in.
>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 08 Mar 2007 08:24:33 -0500

Glen,

> that same pathological case and the converse.

Which case do you mean by "badly-behaved EAP implementations"?

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 8 Mar 2007 23:41:06 +0200

EAP gets confused if it ever receives packets out of order.

Given that EAP is a lock-step protocol, any one of the three remedies is
sufficient to ensure packets never get out of order:

1-  EAP lower layer ensures ordering
2a- EAP lower layer eliminates duplicates
2b- EAP eliminates duplicates

Having more than one of the remedies is not necessary.

Correct?
 
RADIUS does not talk about 1, does not properly mandate 2a.

EAP mandates 2a. It talks about 2b, but falls short of using normative
language (no MUSTs or SHOULDs).

If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile, can we
assume all of the current RADIUS implementations are already supporting 2a,
so that in the absence of 1 and 2b EAP works well?

If we decide to go with 2b, we need to fix EAP spec. Meanwhile, can we
assume all of the current EAP implementations are already supporting 2b, so
that in the absence of 1 and 2a EAP works well?

If we decide to go with 1, we need to fix RADIUS spec. Meanwhile, can we
assume all of the current RADIUS implementations are already supporting 1,
so that in the absence of 2a and 2b EAP works well?

...

We have at least two on-going designs that are gated on this decision. One
in WiMAX Forum, and another PANA. 

Alper

> Sent: Thursday, March 08, 2007 4:01 AM

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 08 Mar 2007 14:46:34 -0800

Alper Yegin said:

"EAP gets confused if it ever receives packets out of order.

Correct?"

[BA] Yes.

"RADIUS does not talk about 1, does not properly mandate 2a...
If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile, can we
assume all of the current RADIUS implementations are already supporting 2a,
so that in the absence of 1 and 2b EAP works well?"

[BA] Yes, I think we can assume this. Alan's proposed language will mandate 
2a.

Glen Zorn said:

"The arguments have been that 'well-behaved' RADIUS implementations
exhibit what amounts to in-order delivery despite the fact that
it is not required by the RFCs..."

[BA] As Alan DeKok noted, most currently shipping RADIUS products
are well-behaved.  As a result, he has proposed text to make
this a MUST.  That should cover the issue.

"My basic argument is that EAP _does_ work over a transport that doesn't
guarantee in-order delivery (the example being RADIUS) except in a deep,
dark, cobweb-filled corner case."

[BA] Wasn't the conclusion that RADIUS without duplicate detection
could reorder EAP packets, causing authentication failures?

Yoshi Ohba said:

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Thu, 8 Mar 2007 18:27:17 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Thursday, March 08, 2007 5:25 AM:

>> My basic argument is that EAP _does_ work over a transport that
>> doesn't guarantee in-order delivery (the example being RADIUS) except
>> in a deep, dark, cobweb-filled corner case.  The arguments have been
>> that "well-behaved" RADIUS implementations exhibit what amounts to
>> in-order delivery despite the fact that it is not required by the
>> RFCs 
>> but badly behaved EAP implementations will fail in a contrived,
>> pathological case. I am saying that a badly-behaved RADIUS
>> implementation would fail in 

I expect that any implementation that would fall prey to Pasi's
pathological example would be badly behaved.

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Thu, 8 Mar 2007 20:28:43 -0800

> EAP gets confused if it ever receives packets out of order.

So does RADIUS, unless it takes the same steps as recommended in RFC3748
for EAP.

> 
> Given that EAP is a lock-step protocol, any one of the three remedies
> is sufficient to ensure packets never get out of order: 
> 

Yes.

> EAP mandates 2a. It talks about 2b, but falls short of using
> normative language (no MUSTs or SHOULDs). 
> 
> 
> If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile,
> can we assume all of the current RADIUS implementations are already
> supporting 2a, so that in the absence of 1 and 2b EAP works well? 

No, not all.
 
> 
> If we decide to go with 2b, we need to fix EAP spec. Meanwhile, can
> we assume all of the current EAP implementations are already
> supporting 2b, so that in the absence of 1 and 2a EAP works well? 

Again, not all; however in both cases the implementations that don't can
reasonably be considered to be broken, I think.
 
> 
> If we decide to go with 1, we need to fix RADIUS spec. Meanwhile, can
> we assume all of the current RADIUS implementations are already
> supporting 1, so that in the absence of 2a and 2b EAP works well? 

If we go with either 1 or 2b for EAP, then it still doesn't fix the
problem because the transport under RADIUS doesn't guarantee ordered
delivery, either.
 
> 
> 
> ...
> 
> We have at least two on-going designs that are gated on this
> decision. One in WiMAX Forum, and another PANA. 
> 
> 
> Alper
> 
> 
> 
>> OK, so what is the real purpose of the Identifier in EAP?  I would
>> have thought that this would be one:
>> 
>>    [5] Possible duplication.  Where the lower layer is reliable, it
>>        will provide the EAP layer with a non-duplicated stream of
>>        packets. However,  while it is desirable that lower layers
>>        provide for non-duplication, this is not a requirement.  The
>>        Identifier field provides both the peer and authenticator
>> with the ability to        detect duplicates. 
>> 
>>>>>> Both EAP and RADIUS do not detect duplicates arriving out of
>>>>>> order; they depend on the underlying lower layer to provide
>>>>>> in-order delivery so as to enable duplicate detection.
>>>>> 
>>>>> RFC 2865 says:
>>>>> 
>>>>> not rely on orderly delivery. Keeping the history for "a short
>>>>> span of time" allows duplicate detection irrespective of the order
>>>>> the requests come in.
>>>> 
>>>> Agree.
>>>> 
>>>>> 
>>>>> responses, would it still accept the second (duplicate) response
>>>>> if it arrives as well? Wouldn't the RADIUS client just drop the
>>>>> second response because there is no outstanding request to match
>>>>> anymore? 
>>>>

---

From: Jouni Malinen <[email-masked]>
Date: Fri, 9 Mar 2007 07:42:28 -0800

> [BA] Yes, I think we can assume this. Alan's proposed language will mandate 

I hit this issue in testing couple of years ago when EAP-SIM tests
were failing if NAS re-transmitted the Access-Request quickly. In other
words, the RADIUS server was not doing duplicate detection.. Since then,
this particular implementation has added support for duplicate
detection, but I believe it can be disabled in configuration and there
has been discussion on some deployments doing that in order to avoid
issues with large number of requests (more than 256 per the duplicate
window of couple of seconds, i.e., more than the number of unique
Identifiers..).

-- 
Jouni Malinen                                            PGP id EFC895FA
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 10 Mar 2007 02:37:11 -0800

> reliable transport for its secure operation.

TLS requires reliable transport for replay protection.  (I guess Bernard 
was trying to get at this in another context in this thread)

In other words, TLS does require reliable transport for a security 
guarantee.

> modifies TLS to correcly work over unreliable transport.

Right, one of the modifications is to carry an explicit sequence number.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 10 Mar 2007 21:10:11 -0500

> was trying to get at this in another context in this thread)

TLS requires reliable transport for implicit sequence number to work
for replay protection.  But this does not mean replay attack is
possible if TLS is run over unreliable transport.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 10 Mar 2007 21:08:42 -0800

Yoshihiro Ohba wrote:
> for replay protection.  

Right, that's what I was getting at.

> But this does not mean replay attack is

How is the sequence number maintained in that case?  Are you saying that 
we might use an explicit sequence number as in DTLS?  But, we are not 
discussing DTLS, are we?

What am I missing?

thanks,
Lakshminath

PS: To Avi's question, I was thinking in case of PEAP and TTLS if the 
EAP layer cannot guarantee in-order reliable delivery, how else do the 
endpoints maintain sequence numbers?  If there is no other way, we can 
conclude that PEAP and TTLS require in-order reliable delivery for one 
of its security guarantees.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 11 Mar 2007 00:56:16 -0500

Let's forget about DTLS and focus on TLS.  I was arguing that
correctness and security are different things.

If TLS are used over unreliable transport, of course it is not
possible for TLS to maintain implicit sequence number.  Without
reliable transport implicit sequence number would not work if loss or
out-of-order delivery of TLS records happens and *even if there is no
attacker*.  That is why I think that reliable transport is needed for
TLS to make implicit sequence number work *correctly* so that it is
used for *security*.  Maybe we are talking about the same thing in
different ways.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 10 Mar 2007 22:06:12 -0800

> correctness and security are different things.

I understand this part.  But, I am not sure the example fits, but it 
doesn't matter.  I am glad to understand your position. :)  Thanks for 
explaining.

So, moving forward from here, let's consider a question along the lines 
Avi has been asking, (note: this may not exactly be the question he asked)

Do EAP methods require in-order delivery to support any of their 
security properties?

I think yes; for example, TTLS would need in-order delivery for
"Replay protection:        Yes"
in Section 9 of draft-funk-eap-ttls-v1-01.

Thoughts?

Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 11 Mar 2007 09:26:27 -0400

> in Section 9 of draft-funk-eap-ttls-v1-01.

We can ask ourselves a question similar to Avi's here: can attacker
succeed a replay attack on TTLS without in-order delivery?  I believe
the answer is no.  Instead, TTLS session would be terminated
immediately when a replayed TLS record is received.  Note that this
session termination due to an active attacker could happen even if
transport is reliable.

Yoshihiro Ohba

> >>>>TLS requires reliable transport for replay protection.  (I guess 
> >>>>Bernard was trying to get at this in another context in this thread)

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 11 Mar 2007 08:50:59 -0800

>window of couple of seconds, i.e., more than the number of unique

The Issues & Fixes document Section 2.1.2 talks about how a combination of 
the EAP Identifier, source IP address and State attribute can be used to 
enable each EAP session to have its own unique Identifier space.  If handled 
this way, there would not be a tradeoff between duplicate elimination and 
restrictions on the number of simultaneous sessions that can be handled.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 11 Mar 2007 09:26:27 -0400

Yoshihiro Ohba

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 11 Mar 2007 19:27:22 -0700

> session termination due to an active attacker could happen even if

Sure, if the question is whether the attacker can gain access because 
there is no replay protection at TLS-layer, the answer to my knowledge 
is a qualified no.  I don't know all the methods out there; I thought of 
some pretty weak methods, but at the end of the day most of them have 
some liveness built into them and where there isn't, for example in PAP, 
there are other problems.

What I can say is that an attack that might have been discovered as a 
replay by TLS may result in a blind DoS attack.  I can also construct 
examples where there may be delayed discovery of a DoS attack.  That 
indicates to me that we may be better of requiring/recommending the 
replay protection property of TLS.

Any other opinions?

thanks,
Lakshminath