Re: [abfab] Summary of proposed changes to eat applicability.document

[Leif Johansson <[e-mail]>]

On 03/11/2013 08:12 PM, Alper Yegin wrote:
> Here you go:
So this replaces all of 2.1 (just to be clear) ?
> 2.1 Retransmission
> In EAP, the authenticator is responsible for retransmission. By default
> EAP assumes that the lower layer (the application in this context) is
> unreliable. The authenticator can send a packet whenever its
> retransmission timer triggers. In this mode, applications need to be
> able to receive and process 
> EAP messages at any time during the authentication conversation.
> 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.
> When retransmission is exclusively handled by the client-side EAP
> lower-layer, 
> an EAP message that gets silently discarded by the EAP method may
> stall the 
> EAP lower-layer state machine.  In such a case, applications MUST
> handle discarded 
> EAP messages. The specific way in which discarded messages will be handled
> depend on the characteristics of the application. Solution options
> include, 
> but are not limited to, failing the authentication at the application
> level, 
> and requesting an EAP retransmit and waiting for additional EAP input.
> Both of 
> these options require the EAP methods to notify the EAP and/or EAP
> lower-layer 
> when an EAP message is discarded.  
> Specifications of how EAP is used for application authentication MUST
> document how retransmission are handled. If the retransmissions are
> exclusively 
> handled by the client-side EAP lower-layer, then the specifications
> MUST also 
> document how message discards are handled.
>
> Alper
>
>
>
>
>
> On Mar 9, 2013, at 5:45 PM, Leif Johansson wrote:
>
>>
>>
>> 9 mar 2013 kl. 09:09 skrev Alper Yegin <[e-mail]
>> <mailto:[e-mail]>>:
>>
>>> 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.
>>>
>>> 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
>>>  
>>>
>>
>> Why don't you propose text!
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>      Cheers Leif
>>>>
>>>>
>>>
>>> _______________________________________________
>>> abfab mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/abfab
>
>
>
> _______________________________________________
> abfab mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/abfab