On Mar 9, 2013, at 6:09 AM, Alper Yegin
<[email protected]<mailto:[email protected]>> wrote:
Hi Leif,
This "MUST" cannot be implemented. It's not clear what an implementor "must" be
doing to comply.
This is merely telling us "there's a problem, you MUST deal with it".
This reads more like recognition of an issue, rather than a solution.
I' going to weigh in (as an individual) on this point.
There is (imo) nothing inherently problematic about calling out a problem that
needs to be addressed in another specification, especially when writing an
applicability statement.
I read the text again, and let me recap it here:
> Alternatively, EAP permits a lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible for
> reliable delivery of EAP messages. Applications that use a lock-step or
> client-driven authentication protocol might benefit from this approach.
>
> In addition to retransmission behavior applications need to deal with
> discarded EAP messages. For example, whenever some EAP methods receive
> erroneous
> input, these methods discard the input rather than generating an error
> response. If the erroneous input was generated by an attacker,
> legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages,
> although the specific way in which discarded messages will be handled
> depend on the characteristics of the application. Options include
> failing the authentication at the application level, requesting an EAP
> retransmit and waiting for additional EAP input.
This text implies there is a problem, but it does not define what the problem
is.
Or under what circumstances that problem arises.
The issue is very specific to the case where the EAP lower layer is in charge
of rexmits, and the rexmits are solely client-side driven.
It does not apply to any other case.
And if the EAP stack (the combination of EAP method, EAP layer, and EAP lower
layer) does not handle this case in a special way, then the state machines may
stall.
[Joe] Its not clear to me that it is just one case. Either side could possibly
discard a message so it seems that you can have stalls with either client or
server side retransmission.
None of that can be understood from the above text at all.
Once the readers understand the issue, then they can proceed to "dealing with
it".
As for the suggested solutions, failing the authentication reduces the
resiliency of EAP solutions.
The other option requires an API between EAP method and EAP lower-layer.
OK, maybe we don't care about the analysis of the solutions, but we do care
about defining what the problem is.
And also, this issue is not really an "applicability statement" matter. This is
a "requirement on EAP lower layer (which is based on strictly client-driven
rexmits)" matter, IMHO.
(I understand some people might want to get done with this, but if we don't do
it properly I'm afraid it'd open more problems than it solves for people down
the road).
Alper
Cheers Leif
_______________________________________________
abfab mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
