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

From: Alper Yegin <[email-masked]>
Date: Sat, 9 Mar 2013 16:09:27 +0200

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

>      Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Sat, 09 Mar 2013 09:41:26 -0500

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    Alper> Hi Leif, This "MUST" cannot be implemented. It's not clear
    Alper> what an implementor "must" be doing to comply.

I've read the text and I agree with Leif; I believe it is fine as-in.
I believe it's entirely reasonable to require applications to deal with
an issue and to leave them several options how to do so.

Yes, a particular application will probably only pick one of these
options.

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Sat, 9 Mar 2013 10:45:30 -0500

> (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).

Why don't you propose text!

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>      Cheers Leif
>> 
>> 
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Alper Yegin <[email-masked]>
Date: Mon, 11 Mar 2013 21:12:52 +0200

Here you go:

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.

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 11 Mar 2013 21:26:37 +0200

One more issue…

  Uses of EAP for Application-Layer Access

   Ongoing work in the IETF (abfab working group) specifies the use of
   EAP over GSSAPI for generic application layer access.  In the past,
   using EAP in this context has met resistance due to the lack of
   channel bindings [RFC6677].  Without channel bindings, a peer cannot
   verify if an authenticator is authorized to provide an advertised
   service.  >>> In most network access use cases all access servers that
   are served by a particular EAP server are providing the same or very
   similar types of service.  The peer does not need to differentiate
   between different access network services supported by the same EAP
   server. <<<

The statement conveyed by those last two sentences are not accurate. The services provided across different access networks can vary a lot. The simplest example is WiFi roaming. You could be using the same subscription across the globe, but each time you may be accessing the Internet via a distinct WiFi operator.  

Now, the authors may feel reluctant to mandate channel binding on the network access authentication case as well. But at least, they shouldn't include a statement like the one above, which claims channel binding is not necessary for the network access case.

Alper

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 Mar 2013 20:35:42 +0100

> Here you go:
So this replaces all of 2.1 (just to be clear) ?
>> 9 mar 2013 kl. 09:09 skrev Alper Yegin <[email-masked]
>> <mailto:[email-masked]>>:
>>
>>> Hi Leif,
>>>
>>>
>>>>
>>>>
>>>>>
>>>> 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.
>>>>
>>>
>>> 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.
>>> 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.
>>>
>>> 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
>>>  
>>>
>>
>>> [email-masked] <mailto:[email-masked]>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Mar 2013 07:51:31 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    Alper> One more issue Uses of EAP for Application-Layer Access

    Alper> The statement conveyed by those last two sentences are not
    Alper> accurate. The services provided across different access
    Alper> networks can vary a lot. The simplest example is WiFi
    Alper> roaming. You could be using the same subscription across the
    Alper> globe, but each time you may be accessing the Internet via a
    Alper> distinct WiFi operator.

I agree.  I propose we drop those sentences; RFc 6677 already goes into
detail about channel binding and network access.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 12 Mar 2013 14:04:49 +0200

Yes.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 Mar 2013 14:06:29 +0100

> Yes.

So at this point I want to hear from others in the WG about this
proposed change.

>>>>> 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.
>>>>> 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.
>>>>>
>>>>> OK, maybe we don't care about the analysis of the solutions, but
>>>>> we do care about defining what the problem is.
>>>>>
>>>>> matter. This is a "requirement on EAP lower layer (which is based
>>>>> on strictly client-driven rexmits)" matter, IMHO. 
>>>>>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 12 Mar 2013 14:24:34 +0000

On Mar 9, 2013, at 6:09 AM, Alper Yegin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Leif,

[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.

Alper

     Cheers Leif

_______________________________________________
abfab mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Mar 2013 14:06:05 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    Alper> When retransmission is exclusively handled by the client-side
    Alper> EAP lower-layer, an EAP message that gets silently discarded
    Alper> by the EAP method may stall the EAP lower-layer state
    Alper> machine.  In such a case, applications MUST handle discarded
    Alper> EAP messages. 

Hi.
I prefer the existing text  to this new text.

    > input. Applications MUST handle discarded EAP messages,

I like the existing text for several reasons.  First, like Joe I think
this is not just a client controlled EAP lower layer retransmit issue.
I believe you can get stalls both in server and client.  Second, I
believe that even if it is true, the way the existing text is written
will be easier for application developers to understand than the new
text.
I  also like the explanation of how the discards come up because it
helps application developers understand the issue.

I don't see problems with the existing text so I am against adopting
this change.

    Alper> input. Both of these options require the EAP methods to
    Alper> notify the EAP and/or EAP lower-layer when an EAP message is
    Alper> discarded.

This is true, but the state machine in section 4.1 of RFC 4137 provides
this interface.  While that's not normative text, it seems fairly clear
that if you think about how to implement EAP you're going to need the no
response variable described in RFC 4137.

    Alper> Specifications of how EAP is used for application
    Alper> authentication MUST document how retransmission are
    Alper> handled. If the retransmissions are exclusively handled by
    Alper> the client-side EAP lower-layer, then the specifications MUST
    Alper> also document how message discards are handled.

I'm happier with that being a SHOULD than a MUST.
Also my comments about how the discard issue are described here apply as
well.

In conclusion, I do not support these changes and prefer the existing
text.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 16 Mar 2013 16:55:49 +0100

> document how message discards are handled.

This proposed change was discussed in Orlando and there was no
consensus in the WG to make this change.

Joe will submit a new version of the eap applicability statement
with the changed we did have consensus on based on the list
discussions and the WG meeting.

        Cheers Leif