Subject: [abfab] Retransmission Text for EAP applicability

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Nov 2012 14:37:20 -0500

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
process EAP messages at any time during the authentication conversation.

Alternatively, EAP permits a lower layer to set the retransmission timer
to infinite. In this case, the lower layer is 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. 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 an EAP method discarding a message,
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 and waiting for
additional EAP input, possibly after an EAP retransmit.

Specifications of how EAP is used for application authentication SHOULD
document how retransmission and message discards are handled.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 15 Nov 2012 10:03:38 -0800

Some small edits that you might want to consider.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Wednesday, November 14, 2012 11:37 AM
> To: [email-masked]
> Subject: [abfab] Retransmission Text for EAP applicability
> 
> 
EAP
> assumes that the lower layer (the application in this context) is
unreliable.
s/lower layer/lower layer transport/
> The authenticator can send a packet whenever its retransmission timer
s/The authenticator can send/To deal with this, the authenticator resends/
> triggers. In this mode, applications need to process EAP messages at any
time
s/need to process/need to be able to receive and process/
> during the authentication conversation.
> 
to
> infinite. In this case, the lower layer is responsible for reliable
delivery of EAP
s/In this case/When this happens/
s/layer is/layer becomes/
> messages. Applications that use a lock-step or client-driven
authentication
> protocol might benefit from this approach.
> 
> response. If the erroneous input was generated by an attacker, legitimate
> input can sometimes be received after the erroneous input. Applications
> MUST handle an EAP method discarding a message, 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 and waiting for additional EAP input, possibly after
an
s/level/level, requesting an EAP retransmit/
> EAP retransmit.
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Nov 2012 04:58:26 +0900

Sam,

The provided text looks good, except that the text is generally 
applicable to any EAP lower-layer inclucing applications.   Said that my 
suggestion is to replace "application" with "lower-layer".

Thanks,
Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Nov 2012 17:15:31 -0500

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> Sam, The provided text looks good, except that the text
    Yoshihiro> is generally applicable to any EAP lower-layer inclucing
    Yoshihiro> applications.  Said that my suggestion is to replace
    Yoshihiro> "application" with "lower-layer".

I'm really pleased when I hear that you're happy with this direction. I
 tried hard  to capture the points you made and I'm glad
 we're quite  close.

I actually think this advice is rather application specific.
I'd say the same thing for a network access lower layer but my emphasis
would be different.
Also, I think giving general lower layer advice in this document is
inappropriate.

For those reasons, I'd be happier if we did not make that substitution.
I support all of Jim's proposed edits.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Nov 2012 08:43:29 +0900

Sam and all,

> I actually think this advice is rather application specific.

Why do you think so?

> Also, I think giving general lower layer advice in this document is

I can understand this is a scope issue, but general readers of this 
document would view the text in the same way as I did, because I believe 
it is a technical fact regardless of the scope of the document.  I would 
like to hear from you and others whether my point is valid, and if my 
point is valid what the best way to capture my point would be.

Regards,
Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Nov 2012 19:13:48 -0500

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

In something more general I would de-emphasize the case where the lower
layer is reliable although still discuss it.
I would not talk about lock-step or client-driven authentication at all.

The examples I use  and the emphasis would also be slightly different
for the discard case.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 15 Nov 2012 17:05:03 -0800

I think that the scope issue itself is an overwhelming argument not to
replace application with lower-layer.  Personally, I would have to think
long and hard about given exactly the same advice to an arbitrary
lower-layer protocol as oppose to given the advice to anyone who is writing
an application protocol that is designed to work with the ABFAB (GSS-EAP)
specific authentication profile.

In the ABFAB case we are explicitly stating that these are requirements we
are dumping on the application protocol and not keeping for the GSS-EAP
lower-level protocol.  Changing the term from application to lower-level
would change the focus of the advice from what an application needs to do to
a problem that we now need to figure out how to solve in ABFAB which we
really do not want to do.

Jim

> Of Yoshihiro Ohba
> Sent: Thursday, November 15, 2012 3:43 PM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: [abfab] Retransmission Text for EAP applicability
> 
> Sam and all,
> 
> > I'd say the same thing for a network access lower layer but my
> > emphasis would be different.
document
> would view the text in the same way as I did, because I believe it is a
> technical fact regardless of the scope of the document.  I would like to
hear
> from you and others whether my point is valid, and if my point is valid
what
> the best way to capture my point would be.
> 
> Regards,
> Yoshihiro Ohba
> 
> 
> >

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Nov 2012 23:46:09 +0200

> s/lower layer/lower layer transport/

"EAP lower layer" is a term defined in RFC 3748. I believe the text intends to refer to that. So, we better stick with the precise term.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Nov 2012 23:56:12 +0200

> discarded EAP messages. Whenever some EAP methods receive  erroneous

Discarding may be done at the EAP layer or the EAP method layer. I think we need to cover for both.

> depend on the characteristics of the application.

Now, saying "MUST handle" and then leaving the way it's handled out-of scope does not make sense.

> Options include
> failing the authentication at the application level

This is problematic. If the EAP method has discarded the message, now you need this be conveyed down the stack to the EAP lower-layer. This does not happen today. And enforcing that requires changing existing EAP methods, creating additional requirement on future methods.  

> and waiting for

Who is retransmitting here? The EAP peer? If so, we need to clarify that. And also described how the EAP peer decides to retransmit, and what it really retransmits (the previous EAP response?).

Is this text meant to cover how the EAP conversation can be made reliable with client-driven retransmissions? I see the implications of it, but not clear and complete description of it.

Alper

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Nov 2012 17:07:14 -0500

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

I'm not convinced it's appropriate for an EAP layer to discard when the

I'd like to see citations to discussion of discards hapeening at the EAP
layer.

This seems like a really bad idea in cases  where the timeout is
infinite.
After we've reviewed any citations members can come up with I think
we'll be in a better position to discuss whether there are any cases
where it's appropriate for an EAP layer to discard in an application
context.
My inclination is that is not a good idea.

We disagree on this point.

    >> Options include failing the authentication at the application
    >> level

    Alper> This is problematic. If the EAP method has discarded the
    Alper> message, now you need this be conveyed down the stack to the
    Alper> EAP lower-layer. This does not happen today. And enforcing
    Alper> that requires changing existing EAP methods, creating
    Alper> additional requirement on future methods.

As  I stated in the meeting, I claim that this does happen today with a
number of common implementations.
As an example, any EAP implementation designed to be used in an AAA
server will make it quite apparent when a discard happens.
On the peer side, you're right that you could design an EAP layer that
did not make this clear.
However from what I've looked at this is not an issue.

--Sam

---

From: Alper Yegin <[email-masked]>
Date: Sat, 17 Nov 2012 01:57:53 +0200

Sam,

If you search for the keyword "discard" in RFC 3748, you see lots of instances. That's for "EAP layer discarding."

As for "EAP method discarding", Yoshi had already sent two examples on the mailing list: EAP-IKEv2, EAP-GPSK.

> This seems like a really bad idea in cases  where the timeout is

Like I explained before, this is not an issue "when EAP timeout is infinity, NAS performs rexmits".
It's an issue "when EAP timeout is infinity, client performs rexmits". 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 18 Nov 2012 08:35:27 +0900

Sam,

(2012/11/16 9:13), Sam Hartman wrote:
> In something more general I would de-emphasize the case where the 
> lower layer is reliable although still discuss it. I would not talk 
> about lock-step or client-driven authentication at all. The examples I 
> use and the emphasis would also be slightly different for the discard 
> case. 

I don't understand the logic behind what should be emphasized or 
de-emphasized here because the guidelines you proposed is logically 
applicable to any lower-layer.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 18 Nov 2012 08:49:28 +0900

(2012/11/16 10:05), Jim Schaad wrote:
> lower-level protocol.

What is the exact definition of "GSS-EAP lower-level protocol"?  How is 
it different from an application?

Yoshihiro Ohba

> Changing the term from application to lower-level

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Nov 2012 20:15:44 -0800

> From: Alper Yegin [mailto:[email-masked]]
> Sent: Friday, November 16, 2012 1:46 PM
> To: Jim Schaad
> Cc: 'Sam Hartman'; [email-masked]
> "EAP lower layer" is a term defined in RFC 3748. I believe the text
intends to
> refer to that. So, we better stick with the precise term.
> 

I would like having transport in there as it tells me more what is going on.
However I can live without it.

By your argument should the term "lower layer" always be changed to "EAP
lower layer"

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Nov 2012 20:37:11 -0800

> Of Alper Yegin
> Sent: Friday, November 16, 2012 1:56 PM
> To: Sam Hartman
> Cc: [email-masked]
> > 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
> > Alternatively, EAP permits a lower layer to set the retransmission
> > timer to infinite. In this case, the lower layer is responsible for
> > reliable delivery of EAP messages. Applications that use a lock-step
> > or client-driven authentication protocol might benefit from this
approach.
> Discarding may be done at the EAP layer or the EAP method layer. I think
we
> need to cover for both.

It is true that the EAP upper lay can discard messages as well, however I am
not sure that the text is going to be clearer by stating so.    However I
think the following change should address your concern

s/Whenever/For example, whenever/

> > legitimate input can sometimes be received after the erroneous input.
> > Applications MUST handle an EAP method discarding a message, although
> > the specific way in which discarded messages will be handled depend on
> > the characteristics of the application.
> 

I think this makes perfect sense.  We have just said that how it is going to
happen - in fact what the correct response to happen - is going to be based
on the specific application we are discussing.  This means that we can't say
what it should do.

Some applications will assume transmission error and send the fact that the
EAP packet was not processed.  (I kind of expect TEAP to do this behavior).

Some applications will treat it as an Access-Fail and kill the whole
process.

We cannot dictate what the correct behavior should be.

> This is problematic. If the EAP method has discarded the message, now you
> need this be conveyed down the stack to the EAP lower-layer. This does not
> happen today. And enforcing that requires changing existing EAP methods,
> creating additional requirement on future methods.

If I make a call to the EAP handler, it does not say that I got an
Access-Accept or an Access-Reject, and it does not return anything for me to
send back continuing the conversation.   This sounds like a pretty good clue
the packet was dropped on the floor given the lock-step behavior of EAP
itself.

I don't see any need to change either current EAP behavior or future
behavior.  

> Who is retransmitting here? The EAP peer? If so, we need to clarify that.
And
> also described how the EAP peer decides to retransmit, and what it really
> retransmits (the previous EAP response?).
> 

That is going to be application specific behavior.  In part it is going to
depend on who dropped the message on the floor and who actually has the
ability to even try and do the resend.    Without knowing your application
data flow, I cannot answer this question.

> 
> Is this text meant to cover how the EAP conversation can be made reliable
> with client-driven retransmissions? I see the implications of it, but not
clear
> and complete description of it.

No.  That may be one of the things that an application may define, but it is
not required in any way.

> 
> Alper
> 
> 
> 
> > Specifications of how EAP is used for application authentication
> > SHOULD document how retransmission and message discards are handled.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Nov 2012 20:43:56 -0800

> Sent: Friday, November 16, 2012 3:58 PM
> To: Sam Hartman
> Cc: [email-masked]
> If you search for the keyword "discard" in RFC 3748, you see lots of
instances.
> That's for "EAP layer discarding."
> 
> Like I explained before, this is not an issue "when EAP timeout is
infinity, NAS
> performs rexmits".

The NAS can only do a retransmit if it is involved in an async protocol.  If
it is in a sync protocol then the token needs to be passed  back to the NAS
in order for it to do the retransmit.  If this does not happen then you will
be in a dead-lock situation.

Jim

> > I'd like to see citations to discussion of discards hapeening at the
> > EAP layer.
> >
> >>> Options include failing the authentication at the application level
> >
> > As  I stated in the meeting, I claim that this does happen today with
> > a number of common implementations.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Nov 2012 20:48:31 -0800

I would be against this replacement.

The application and the lower-layer may not be the same thing for a number
of reasons.  Looking specifically at the GSS-EAP case, the lower layer
consists of both RADIUS and GSS-API.  Neither of these is really the
application layer.  If EAP is directly built into the application, then yes
the application and the lower layer are going to be the same.  If there is
some type of wrapper that is going on in the middle, such as using GSS-API,
then they are no longer the same.  The application becomes one layer lower
than the lower-layer.

If you look at RADIUS, RADIUS is the lower-layer independent of transport
that RADIUS is operating on top of.  It does not mapper if you are doing
RADIUS over UDP, DTLS or TLS/IP, RADIUS is the lower-layer.  At some point
you say everything below this point is below the lower-layer.

Jim

> Sent: Thursday, November 15, 2012 11:58 AM
> To: [email-masked]
approach.
> > the characteristics of the application. Options include failing the
> > authentication at the application level and waiting for additional EAP
> > input, possibly after an EAP retransmit.
> >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 20 Nov 2012 14:33:10 +0900

Jim,

In the context of EAP, GSS-EAP solely cannot be considered as EAP 
lower-layer because GSS-EAP itself does not provide in-order delivery of 
EAP messages.  GSS-EAP requires applications to provide in-order 
delivery.  Therefore, GSS-EAP applications must be considered as part of 
EAP lower layer.

Yoshihiro Ohba

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Nov 2012 22:25:16 -0800

It is more correct to say that GSS-API gets its reliability by pushing some
of it down a layer, but that is no different that RADIUS saying it can have
reliable transport if it requires TLS/IP as its underlying transport.  

Also the requirements that GSS-API imposes during the authentication phase
are different than those during the normal application processing.  For
GSS-EAP it is a lock-step delivery during authentication.  That is much
stricter than just saying it is in-order delivery.

However this does not change my opinion that application protocol that is
using GSS-API is not part of the EAP lower-level.  The requirements that
GSS-API makes are independent of the use of EAP.

Jim

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Monday, November 19, 2012 9:33 PM
> To: Jim Schaad
> Cc: [email-masked]
> In the context of EAP, GSS-EAP solely cannot be considered as EAP lower-
> layer because GSS-EAP itself does not provide in-order delivery of EAP
> messages.  GSS-EAP requires applications to provide in-order delivery.
> Therefore, GSS-EAP applications must be considered as part of EAP lower
> layer.
> 
> Yoshihiro Ohba
> 
> > The application and the lower-layer may not be the same thing for a
> > number of reasons.  Looking specifically at the GSS-EAP case, the
> > lower layer consists of both RADIUS and GSS-API.  Neither of these is
> > really the application layer.  If EAP is directly built into the
> > application, then yes the application and the lower layer are going to
> > be the same.  If there is some type of wrapper that is going on in the
> > middle, such as using GSS-API, then they are no longer the same.  The
> > application becomes one layer lower than the lower-layer.
> >
> > If you look at RADIUS, RADIUS is the lower-layer independent of
> > transport that RADIUS is operating on top of.  It does not mapper if
> > you are doing RADIUS over UDP, DTLS or TLS/IP, RADIUS is the
> > lower-layer.  At some point you say everything below this point is below
> the lower-layer.
> >
> > Jim
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Yoshihiro Ohba
> >>> its retransmission timer triggers. In this mode, applications need
> >>> to process EAP messages at any time during the authentication
> conversation.
> >>>
> >>> In addition to retransmission behavior applications need to deal
> >>> with discarded EAP messages. 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,
> >>> Applications MUST handle an EAP method discarding a message,
> >>> 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 and
> >>> waiting for additional EAP input, possibly after an EAP retransmit.
> >>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Nov 2012 08:24:30 +0900

> reliable transport if it requires TLS/IP as its underlying transport.

If GSS-API relies on reliability provided by its transport, then GSS-API 
combined with the trasnsport is considered as EAP lower layer to meet 
EAP lower layer requirements.

Strictly speaking, RADIUS is not considered as EAP lower layer just 
because EAP lower layer is defined as the laywer that is responsible for 
transmitting and receiving EAP frames *between the peer and 
authenticator* (see RFC  3748).

> stricter than just saying it is in-order delivery.

Being lock-step solely does not provide in-order delivery.  EAP is 
lock-step protocol but it does not provide in-order delivery, because it 
Identifier fieled is not a sequence number and may be reused during the 
same EAP conversation.  To provider in-order delivery, at least sequence 
number would be needed.  Does GSS EAP token carry a sequence number?   
This is an important question for you to answer.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Nov 2012 11:55:43 +0200

> By your argument should the term "lower layer" always be changed to "EAP

Yes, with a reference to RFC 3748.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Nov 2012 12:39:27 +0200

> on the specific application we are discussing.  This means that we can't say

Why would the application care what happens when an EAP-layer or EAP method-layer message is discarded?
If an EAP-layer message is discarded, it's for the EAP-layer to deal with that.
If an EAP method-layer message is discarded, it's for the EAP method layer to deal with that.

If you are designing a protocol that needs to deal with what happens at 1 or 2 layers above, then I'd say there's an issue with this design.
This is like saying, if HTTP discards a packet, then IP MUST handle this. 

> We cannot dictate what the correct behavior should be.

Because, that's not the business of this layer. Having a MUST w/o a clear normative text and this explanation is the indication of the problem. Don't you think?

> the packet was dropped on the floor given the lock-step behavior of EAP

Nope. Maybe the EAP method is awaiting an input from the user. The "EAP lower layer" cannot know what's going on at the EAP method layer.

> data flow, I cannot answer this question.

The options provided by the text is ambiguous. 

> No.  That may be one of the things that an application may define, but it is

I'd say if this text is meant to cover that possibility, then we need to make it very clear. Otherwise, the text is rather vague…

Alper

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Nov 2012 20:15:45 -0500

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

    Alper> Sam, If you search for the keyword "discard" in RFC 3748, you
    Alper> see lots of instances. That's for "EAP layer discarding."

BTW, thanks for this citation; it was useful. I had read most of the
text in question before and was in fact even aware of the behavior, but
for some reason didn't think of it as discarding.. I know, that makes no
sense at all: the spec calls it discarding.

I think Jim's proposed fix for this is good. I just wanted to thank you
for helping me solve my confusion.

--Sam

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 Nov 2012 09:44:14 +0200

> for helping me solve my confusion.

No problem.

But I don't understand how you think the text is good. Do you care to explain your views on the issues I raised below:

Begin forwarded message:

> From: Alper Yegin <[email-masked]>
> Date: November 22, 2012 12:39:27 PM GMT+02:00
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
>