eap Mailing List: TLS clarifications (Re: Ordered delivery of EAP messages)

[Lakshminath Dondeti (ldondeti]

Yoshihiro Ohba wrote:
> On Wed, Mar 07, 2007 at 11:11:35PM -0500, Avi Lior wrote:
> > 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.  
>
> 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.

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.

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

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

regards,
Lakshminath

> 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
>
> >  
> >
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba [at] tari.toshiba.com] 
> > Sent: Wednesday, March 07, 2007 7:15 PM
> > To: Avi Lior
> > Cc: Bernard Aboba; alper.yegin [at] yegin.org; radiusext [at] ops.ietf.org;
> > eap [at] frascone.com
> > Subject: Re: [eap] Ordered delivery of EAP messages
> >
> > 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.
> > >
> > > 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. 
> > >
> > > 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]). 
> > >
> > > 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:bernard_aboba [at] hotmail.com]
> > > Sent: Tuesday, March 06, 2007 11:55 PM
> > > To: alper.yegin [at] yegin.org
> > > Cc: radiusext [at] ops.ietf.org; eap [at] frascone.com
> > > Subject: Re: [eap] Ordered delivery of EAP messages
> > >
> > > > 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.
> > > 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).
> > >
> > > > 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?
> > > 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.
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, please visit:
> > > http://lists.frascone.com/mailman/listinfo/eap
> > >
> > > Arhives: http://lists.frascone.com/pipermail/eap
> > >
> > > --
> > > to unsubscribe send a message to radiusext-request [at] ops.ietf.org with 
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://psg.com/lists/radiusext/>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap