Subject: [abfab] EAP Applicability: retransmissions

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 09:28:02 -0400

Hi.  Over in PCP we've been attempting to apply EAP to the application
authentication problem.  My personal opinion is that GSS-EAP brings more
complexity than PCP needs. Three solutions are being considered: two
PANA-based solutions and one solution tuned for PCP.

A few issues have come up where the requirements of EAP  are unclear at
least to some participants.

It seems to me like the EAP applicability update would be a great place
to cover these issues.

The first is retransmission.

As specified in RFC 3748, EAP handles retransmissions, and the EAP
authenticator is responsible for the retransmission.

However, the EAP RFC allows a lower layer to set the retransmission
timeout to infinite.

In terms of an applicability statement, I believe that  applications
MUST choose one of the following options:

1) Have authenticator-initiated retransmissions at the EAP layer.

2) Set the timeout to infinite and require retransmissions at a lower
layer that is application specific.

For example, since GSS-API provides reliability, we chose option 2 in
draft-ietf-abfab-gss-eap. This is particularly true because GSS-API
doesn't support the idea of unsolicited messages from server to client.
The applicability statement should point out that if applications choose
option 1 they need to be able to transmit messages from server to client
at any time during the authentication phase.

If the WG agrees with this proposal I'll propose specific text.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 19 Oct 2012 16:00:04 +0200

> least to some participants.

Draft draft-ietf-abfab-eapapplicability updates only the EAP
applicability statement (i.e. section 1.3 of RFC3748).

I have the impression that the clarifications regarding retransmission
which you describe below are certainly related to RFC3748, but are not
something that should be mentioned in section 1.3, i.e. the
applicability statement.

> It seems to me like the EAP applicability update would be a great place

If my suspicion in the paragraph above is true, the *applicability
update* seems like the wrong place IMHO. An update to (or if the issue
is seen as small enough: an erratum pertinent to) RFC3748 as a whole
would be a more logical approach.

Also, we have earlier been discussing the scope of
draft-ietf-abfab-eapapplicability - whether it should cover all
present-day uses of EAP, or just abfab-related uses. Back then we
concluded that its scope should be narrowed down to just abfab.

Since your issue is occuring in pcp, not abfab, that agreed course of
action would mean that the issue is out of scope for
draft-ietf-abfab-eapapplicability, even if it should indeed relate to
section 1.3 of RFC3748.

> at any time during the authentication phase.

Is there a second one?

Greetings,

Stefan

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

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 10:06:44 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    >> Hi.  Over in PCP we've been attempting to apply EAP to the
    >> application authentication problem.  My personal opinion is that
    >> GSS-EAP brings more complexity than PCP needs. Three solutions
    >> are being considered: two PANA-based solutions and one solution
    >> tuned for PCP.
    >> 
    >> A few issues have come up where the requirements of EAP are
    >> unclear at least to some participants.

    Stefan> Draft draft-ietf-abfab-eapapplicability updates only the EAP
    Stefan> applicability statement (i.e. section 1.3 of RFC3748).

    Stefan> I have the impression that the clarifications regarding
    Stefan> retransmission which you describe below are certainly
    Stefan> related to RFC3748, but are not something that should be
    Stefan> mentioned in section 1.3, i.e. the applicability statement.

Actually, RFC 3748 is quite clear  about this already.

My belief is that your draft should cover the sorts of issues that
applicability statements generally cover... What issues should an
applied-to thing consider when applying the applied thing.
What issues should you consider when evaluating whether the applied
thing is appropriate to apply.

I'm not proposing changing EAp.

Also, my understanding is that the scope of your document is uses of EAP
within ABFAB's scope.
That is, uses of EAp within the scope of application authentication.
What's going on with PCP is very much within that scope.

So would you be willing to reread my messages in that revised context
and give me your thoughts there?

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 20 Oct 2012 03:23:49 +0900

RFC 3748 also says:

" When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as 
within [PIC]), the authenticator retransmission timer SHOULD be set to 
an infinite value, so that retransmissions do not occur at the EAP layer. "

This allows double-layer retransmissions in some cases.  For example, 
EAP peer may be temporally busy and may have to discard received 
requests.   In such a case, EAP-layer retransmissions on top of reliable 
lower layer can be useful.

EAP retransmissions can be useful in some cases even with GSS-API, and I 
am wondering why GSS-EAP  mandates option 2 (I am sorry for noticing 
this late).

Having said that I don't think we need to add text on this matter.

Thanks,
Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 14:28:46 -0400

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

    Yoshihiro> RFC 3748 also says: " When run over a reliable lower
    Yoshihiro> layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the
    Yoshihiro> authenticator retransmission timer SHOULD be set to an
    Yoshihiro> infinite value, so that retransmissions do not occur at
    Yoshihiro> the EAP layer. "

    Yoshihiro> This allows double-layer retransmissions in some cases.
    Yoshihiro> For example, EAP peer may be temporally busy and may have
    Yoshihiro> to discard received requests.  In such a case, EAP-layer
    Yoshihiro> retransmissions on top of reliable lower layer can be
    Yoshihiro> useful.

But would not actually happen if you set  the timer to infinite.

    Yoshihiro> EAP retransmissions can be useful in some cases even with
    Yoshihiro> GSS-API, and I am wondering why GSS-EAP mandates option 2
    Yoshihiro> (I am sorry for noticing this late).

Because GSS-API requires each round trip be started by the initiator and
receive at most one response from the acceptor.  I.E. until the
initiator sends another message, the acceptor cannot send anything.

    Yoshihiro> Having said that I don't think we need to add text on
    Yoshihiro> this matter.

I actually think text on this point is quite important.  It's easy to
read RFC 3748 and assume that things need to be server-initiated in EAP.
I think it's important to point out to people considering using EAP for
their applications that if they take responsibility for retransmissions
that the EAP messages can be client-driven.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 20 Oct 2012 04:26:26 +0900

Sam,

> initiator sends another message, the acceptor cannot send anything.

I am rather seeing an issue here.  What happens if an initiator has to 
discard a received EAP request
for some reasons, e.g., lack of processing resource, the request is 
invalid due to message modification attack, etc.?   How the request is 
retransmitted?

> that the EAP messages can be client-driven.

I think client-driven retransmission needs to be carefully designed.  I 
am interested in
seeing an answer for my question above.

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 15:56:19 -0400

First I'm really excited that you're walking through this.  By trying to
explain this I've found some problems in how I'm thinking about the
problem and have clarified my position significantly.  To me, that's
valuable.  Also, in my mind the fact that the issue is complex enough
that I've revised my understanding multiple times suggests there really
is something here worth writing down once we reach clarity.

    >> 
    >> Because GSS-API requires each round trip be started by the
    >> initiator and receive at most one response from the acceptor.
    >> I.E. until the initiator sends another message, the acceptor
    >> cannot send anything.

    Yoshihiro> I am rather seeing an issue here.  What happens if an
    Yoshihiro> initiator has to discard a received EAP request for some
    Yoshihiro> reasons, e.g., lack of processing resource, the request
    Yoshihiro> is invalid due to message modification attack, etc.?  How
    Yoshihiro> the request is retransmitted?

Hi.
First, in writing this I've realized that I am incorrect when I describe
GSS-EAP as client-driven retransmit.

GSS-EAP is application-layer retransmit.

So, GSS expects the application to provide reliable transport to it.
Normally applications do this by running over TCP.  In TCP, if a node
discards a packet without acknowledging it, then it is retransmitted at
the TCP layer.
It's an error to discard a packet after acknowledging.

If you're writing a sockets app, and you're using GSS-EAP inside TCP,
then you shouldn't read from the socket if you're too busy.

If your application runs over something like UDP, then yes designing
retransmits  is difficult.

Clearly  if you're providing generic retransmit capability, then  the
end sending a message needs to retransmit it.
The question is how that retransmit is triggered.

If you want the client to control the flow then here's roughly what I'd
expect.

1) Client sends message.

2) If server has responded to that message already it retransmits its
cached response. Server does not have  a retransmit timer; it only
responds when triggered by client. It does need to maintain a message in
a buffer to retransmit.

3) If the server has not responded to the message before, it does
respond and caches its response so it can be retransmitted.

4) Client has a retransmit timer if it doesn't receive a response to its
message before the timer fires, it retransmits.

Obviously exponential back-off etc applies.

Also, note that you should never do this just for EAP. If you want
retransmits for EAP, then use EAp's mechanisms for that.
The point I want to capture for the applicability statement is that  if
your application already has a reliable layer over which it wants to run
lock-step authentication, RFC 3748 permits you to turn off EAP
retransmits. Once you do that the server will not send unsolicited
messages in an ongoing EAP conversation.
Because a lot of applications do have reliable layers over which they
run lock-step authentication protocols without provision for unsolicited
server messages, we should document that this does work.

The question of server-initiated reauth is a separate issue that can
also generate unsolicited server traffic. I think it's important to
handle that issue separately.  I can think of application protocols in
which supporting server-initiated re-auth would be relatively easy but
for which requiring EAP-layer retransmits would be a deal breaker.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 21 Oct 2012 18:58:32 +0900

There are two separate issues here.

First, Regardless whether lower-layer provides reliabilty or not, I 
believe EAP-layer retransmissions
can improve robustness against DoS attack by sending malformed EAP 
requests, which otherwise can stall the EAP conversation. EAP-layer 
retransmission is not needed if the lower-layer provides secure reliable 
transport of EAP, such as IKEv2.  I am not an expert of GSS-API, but it 
would have been better if EAP-layer retrasnmissions were allowed in GSS-EAP.

Second, Regarding peer-initiated lower-layer retransmission, it is 
characterized by authenticator lower-layer to retransmit an EAP request 
based on an external event of receiving a peer-initiated duplicate 
request, instead of use of an internal timer event. This means that if 
the peer lower-layer receives a lower-layer response carrying an EAP 
request (so the corresponding lower-layer request is no longer 
outstanding) and the EAP request is discarded by EAP peer layer for some 
reason, then the peer lower-layer will not retransmit the lower-layer 
request to serve as the external event for the authenticator lower-layer 
to retransmit the EAP request. As a result, if my understanding is 
correct, the EAP conversation will stall unless there is some additional 
mechanism that can keep the EAP conversation going.  The issue is more 
significant for insecure lower-layers where attackers can inject 
malformed EAP requests.  The issue is less significant for secure 
lower-layers such as IKEv2.  I agree that this issue is complex.  Note 
that PANA does not have this issue because it is based on 
authenticator-initiated lower layer retransmission.

Hope this helps,
Yoshihiro Ohba

(2012/10/20 4:56), Sam Hartman wrote:
>>>>>> "Yoshihiro" == Yoshihiro Ohba<[email-masked]>  writes:
>      >>

---

From: Leif Johansson <[email-masked]>
Date: Sun, 21 Oct 2012 14:38:54 +0200

> It seems to me like the EAP applicability update would be a great
> place to cover these issues.

Didn't we have the discussion on general vs specific eap applicability
stmt for abfab already and decided we couldn't figure out a way to make
sure a general applicability stmt would get enough review? Isn't this
re-opening this issue?

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2012 08:54:55 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    >> place to cover these issues.

    Leif> Didn't we have the discussion on general vs specific eap
    Leif> applicability stmt for abfab already and decided we couldn't
    Leif> figure out a way to make sure a general applicability stmt
    Leif> would get enough review? Isn't this re-opening this issue?

Yes,  we had that discussion.
I actually think all the issues I'm bringing up  would be kind of tricky
to cover in a general applicability statement.
It's precisely because they are scoped to using EAP for application
authentication--which is  ABFAB's scope--that I think we can address
them.
Remember ABFAB's scope is not GSS-EAP;  we're scoped to using EAP
authentication and AAA for application federation.
GSS-EAP is the only method  currently on our charter to do that.
However, the applicability statement needs to be broad enough to cover
the ABFAB scope, and I'm fairly sure ABFAB-specific is where we got in
the EAP applicability scoping discussion.

Am I misremembering that discussion?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Oct 2012 07:02:53 -0400

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

    Yoshihiro> There are two separate issues here.  First, Regardless
    Yoshihiro> whether lower-layer provides reliabilty or not, I believe
    Yoshihiro> EAP-layer retransmissions can improve robustness against
    Yoshihiro> DoS attack by sending malformed EAP requests, which
    Yoshihiro> otherwise can stall the EAP conversation. EAP-layer
    Yoshihiro> retransmission is not needed if the lower-layer provides
    Yoshihiro> secure reliable transport of EAP, such as IKEv2.  I am
    Yoshihiro> not an expert of GSS-API, but it would have been better
    Yoshihiro> if EAP-layer retrasnmissions were allowed in GSS-EAP.

We both agree that a reliable lower layer needs to be sufficient to deal
 with network problems.

As I understand it, we're exploring the case where retransmissions would
deal with an attacker.
So, I think what you're saying is that if an implementation performs a
retransmit when it gets a malicious packet, it can be more robust.

We're presumably talking about an attacker that can insert packets but
not modify them or suppress them.
An attacker who can modify or suppress packets can fairly clearly DOS
the EAP conversation.
If nothing else, they can simply make sure the packet is always
corrupted.

For this to be valuable there need to be EAP methods that are robust
under EAP-layer retransmission but not other higher-layer
retransmission. 
It's not good enough for EAP layer retransmissions to help with some
packets in a method if it doesn't help with others. If there's some
packet an attacker can easily send that will break the conversation, the method
is not robust under EAP layer transmission.
For example it wouldn't be particularly valuable if EAP layer
retransmission protects against garbled packets but not packets with
unknown critical options added, because an attacker could easily add an
unknown critical option.

I then started to consider the existing EAP methods.
I am not able to think of an EAP method that is robust under EAP layer
retransmission. I think you can fairly consistently break an EAP
conversation by inserting packets.
The most obvious thing to try is an EAP failure packet, then an EAP
NACK.
I also quickly considered methods like GPSK and TLS-based methods, and
am fairly sure those are not robust either.
So, would you be willing to pick an EAP method that is robust and go
through a fairly detailed argument about how insertion DOS attacks are
avoided?

    Yoshihiro> Second, Regarding peer-initiated lower-layer
    Yoshihiro> retransmission, it is characterized by authenticator
    Yoshihiro> lower-layer to retransmit an EAP request based on an
    Yoshihiro> external event of receiving a peer-initiated duplicate
    Yoshihiro> request, instead of use of an internal timer event. This
    Yoshihiro> means that if the peer lower-layer receives a lower-layer
    Yoshihiro> response carrying an EAP request (so the corresponding
    Yoshihiro> lower-layer request is no longer outstanding) and the EAP
    Yoshihiro> request is discarded by EAP peer layer for some reason,
    Yoshihiro> then the peer lower-layer will not retransmit the
    Yoshihiro> lower-layer request to serve as the external event for
    Yoshihiro> the authenticator lower-layer to retransmit the EAP
    Yoshihiro> request. As a result, if my understanding is correct, the
    Yoshihiro> EAP conversation will stall unless there is some
    Yoshihiro> additional mechanism that can keep the EAP conversation
    Yoshihiro> going.  The issue is more significant for insecure
    Yoshihiro> lower-layers where attackers can inject malformed EAP
    Yoshihiro> requests.  The issue is less significant for secure
    Yoshihiro> lower-layers such as IKEv2.  I agree that this issue is
    Yoshihiro> complex.  Note that PANA does not have this issue because
    Yoshihiro> it is based on authenticator-initiated lower layer
    Yoshihiro> retransmission.

It's absolutely true that if a peer  discards an EAP request in such a
scheme, the conversation stalls.
If you're introducing that into an application, that would decrease
robustness.
There are a lot of TCP applications though where it is a violation of a
protocol to discard a message. LDAP clients do not just get to ignore a
SASL challenge or any other non-authentication protocol message.
If an IMAP client ignores the capability response (happens before
authentication), things will stall.
If your application already depends on people not discarding responses,
depending on that for authentication is fine.

I think more or less all of our security layers are vulnerable to DOS
attacks from people inserting or modifying their negotiations.
The only thing I can think of that clearly does not have this
vulnerability is statically keyed TCP-AO or IPSec.
I'm fairly sure very little of anything we standardize gives the
robustness you're looking for.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 24 Oct 2012 21:37:16 +0900

Sam,

EAP-IKEv2 supports silent discarsion.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 24 Oct 2012 22:15:54 +0900

Sam,

 > am fairly sure those are not robust either.

I also checked EAP-GPSK and it supports silent discarsion.

Yoshihiro Ohba

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 25 Oct 2012 20:09:50 -0700

I have been looking at TEAP and am worried about silent discarding of
packets.

Since in the ABFAB environment, it is assumed that the transport is
reliable, there is a possibility that a difference of opinion about what
constitutes a good packet between the server and the client could cause a
dead-lock situation in the protocol.

For TEAP, it says that you silently discard if the flags are wrong, but if
the server and the client disagree if the EAP length field should be present
then the server will discard and the client will wait forever for a
response.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yoshihiro Ohba
> Sent: Wednesday, October 24, 2012 5:37 AM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: [abfab] EAP Applicability: retransmissions
> 
> Sam,
> 
> > As I understand it, we're exploring the case where retransmissions
> > would deal with an attacker.
> > packet an attacker can easily send that will break the conversation,
> > the method is not robust under EAP layer transmission.
> > unknown critical options added, because an attacker could easily add
> > an unknown critical option.
> >
> > There are a lot of TCP applications though where it is a violation of
> > a protocol to discard a message. LDAP clients do not just get to
> > ignore a SASL challenge or any other non-authentication protocol
message.
> > If your application already depends on people not discarding
> > responses, depending on that for authentication is fine.
> >

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 Oct 2012 00:53:47 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I have been looking at TEAP and am worried about silent
    Jim> discarding of packets.

    Jim> Since in the ABFAB environment, it is assumed that the
    Jim> transport is reliable, there is a possibility that a difference
    Jim> of opinion about what constitutes a good packet between the
    Jim> server and the client could cause a dead-lock situation in the
    Jim> protocol.

Silent discard seems kind of inconsistent with a lower layer with
infinite timeout, don't you think?

Actually fixing that seems out of scope for just an applicability update
and is something we should discuss in EMU.
we can definitely discuss the TEAP specific version there.
For the applicability statement it seems like we should note this.

I've reviewed eap-ikev2, and it does seemed that it could be part of a
solution to provide DOS robustness.  A lot of other things about the EAP
implementation, lower layer, security association protocol, etc all need
to be true for you to actually get that benefit.

I think this discussion has been quite useful and I'll try to work on
text to propose for the applicability statement focusing on how this all
impacts applications.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 29 Oct 2012 03:36:43 +0000

This discussion points out behavior that can result in some problems so I think we need to cover this somewhere either in the applicability statement or in EAP-GSS.  We need to consider it in TEAP, but the issue is broader than TEAP.  

Joe

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Oct 2012 13:24:18 +0200

> It's an error to discard a packet after acknowledging.

The important thing is, who is acknowledging the receipt and who is discarding packet.
It's perfectly fine when the EAP lower layer (who provides reliable delivery) is acknowledging the receipt, but then the EAP layer or the EAP method (i.e., the higher layers) is discarding the packet.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Oct 2012 14:02:02 +0200

Sam,

Correction to your statement above:

We are talking about the necessity of EAP-layer or EAP lower-layer server-side re-transmission being necessary.
You are proposing getting by with client-side re-transmissions.

> conversation by inserting packets.

Nope. A random EAP payload to your EAP-o-PCP method that is sent from the server side can totally stall your solution.
EAP layer or the EAP method layer on the client will discard that message.
But since your EAP-o-PCP on the client side thinks it happily got a response to its earlier request, it'll sit there by itself. The discarded message won't generate a response from the EAP layer or EAP method layer on the client, so nothing will tell the EAP-o-PCP to send its next request.  

This situation does not happen to server-driven rexmits, as the server would rexmit the request if it does not receive a response. A random packet injected cannot stall the flow.

> The most obvious thing to try is an EAP failure packet, then an EAP

From 3748:

   A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request
   after an initial non-Nak Response has been sent.  Since spoofed EAP
   Request packets may be sent by an attacker, an authenticator
   receiving an unexpected Nak SHOULD discard it and log the event.

...

   Success and Failure packets MUST NOT be sent by an EAP authenticator
   if the specification of the given method does not explicitly permit
   the method to finish at that point.  A peer EAP implementation
   receiving a Success or Failure packet where sending one is not
   explicitly permitted MUST silently discard it. 

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Oct 2012 14:07:03 +0200

> infinite timeout, don't you think?

What's being discussed is "EAP layer timeout being infinite, EAP lower-layer server-side timeout being finite".
In that case, silent discarding is not a problem.

Alper

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Oct 2012 08:46:58 -0400

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

>     We both agree that a reliable lower layer needs to be
> sufficient to deal with network problems.

>     As I understand it, we're exploring the case where
> retransmissions would deal with an attacker.  So, I think
> what you're saying is that if an implementation performs a

>     We're presumably talking about an attacker that can
> insert packets but not modify them or suppress them.  An
> attacker who can modify or suppress packets can fairly
> clearly DOS the EAP conversation.  If nothing else, they can
> simply make sure the packet is always corrupted.

>     For this to be valuable there need to be EAP methods that
> are robust under EAP-layer retransmission but not other
> higher-layer retransmission.

> Sam,

    Alper> Correction to your statement above:

    Alper> We are talking about the necessity of EAP-layer or EAP
    Alper> lower-layer server-side re-transmission being necessary.  You
    Alper> are proposing getting by with client-side re-transmissions.

For the record, I believe my original statement accurately reflects my
meaning and your correction does not.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Oct 2012 09:02:49 -0400

As part of writing this reply I realized that I don't fully understand
how this works at the AAA layer.
Alan, what happens when a RADIUS server gets an access request and the
EAP layer doesn't produce an EAP message?
The NAS's RADIUS client is waiting for an answer; it will eventually
time out, but that's not going to help things so much.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 29 Oct 2012 15:29:54 +0100

> EAP layer doesn't produce an EAP message?

  I'm presuming that this is the EAP side on the RADIUS server.

  The answer is that the RADIUS server really *should* respond to the
Access-Request.  Without any EAP data, the only thing it can return is
Access-Reject.

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 29 Oct 2012 21:34:06 -0700

I have an added worry in that an additional "attacker" that I worry about is
a stupid or slightly incorrectly encoded client.  This means that part of
what I worry about is what happens if the client decides to drop an EAP
message for some unknown reason that may or may not be a correct thing for
it to do.

A RADIUS server will not cause a re-transmission on a timeout because it
only operates in a response mode.  That is the client is always the entity
that sends a request that RADIUS server responds to.  However the RADIUS
server will have cached the last message it sent out.

The acceptor (GSS-API RP) is not currently setup to deal with
re-transmission of EAP messages in either direction.

The initiator is the one which dropped the EAP message on the floor when it
received the GSS-API wrapper on the message.  It is not clear that it has
anything to send to the acceptor to trigger the RADIUS messages from the
acceptor to the RADIUS server.  It is not clear that the GSS-API acceptor
would send a new RADIUS message to the RADIUS server unless there is an EAP
component to the GSS-API message sent from the initiator to the acceptor.

Jim

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Monday, October 29, 2012 7:30 AM
To: Sam Hartman
Cc: Alper Yegin; Jim Schaad; [email-masked]
Subject: Re: [abfab] EAP Applicability: retransmissions

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 30 Oct 2012 06:03:07 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I have an added worry in that an additional "attacker" that I
    Jim> worry about is a stupid or slightly incorrectly encoded client.
    Jim> This means that part of what I worry about is what happens if
    Jim> the client decides to drop an EAP message for some unknown
    Jim> reason that may or may not be a correct thing for it to do.

I actually  think this is not specific to GSS.
Even if the authenticator retransmits, it will retransmit the same
request.
Assuming  the peer's behavior is deterministic, such a peer will fail
with any lower layer.

--Sam

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 30 Oct 2012 10:27:38 -0700

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2012 3:03 AM
> To: Jim Schaad
> Cc: 'Alan DeKok'; 'Alper Yegin'; [email-masked]
request.
> Assuming  the peer's behavior is deterministic, such a peer will fail with
any
> lower layer.

It is true that any peer will fail, however it is also true that the server
in this case will do good things if it can originate messages as it knows
when and how to shut down the session and not send an EAP failure message to
the client.  If one has a lock step transport then there is no current good
way on how to shut down the session and send a failure message back towards
the client.   This is a general issue for RADIUS, but is not a problem in
many other transports. 

Jim

---

From: Sam Hartman <[email-masked]>
Date: Tue, 30 Oct 2012 13:51:29 -0400

In gss-eap, I'd expect an implementation that gets an access reject to
send an error token and shut down that way.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 30 Oct 2012 11:02:37 -0700

I agree that an access reject from RADIUS is the correct way to shut down.
Who sends it and when?

> Sent: Tuesday, October 30, 2012 10:51 AM
> To: Jim Schaad
send
> an error token and shut down that way.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 30 Oct 2012 15:36:41 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I agree that an access reject from RADIUS is the correct way to
    Jim> shut down.  Who sends it and when?

Alan implied that when  the eap stack fails to produce an answer the
RADIUS server doesn't have anything else to do.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 30 Oct 2012 14:43:23 -0700

> Sent: Tuesday, October 30, 2012 12:37 PM
> To: Jim Schaad
RADIUS
> server doesn't have anything else to do.

I think he was talking about the RADIUS server not having any EAP data to
send back to the client.  And that in that case the server SHOULD send a
reject message back.

I am looking at the case of the EAP client not having any data to send.  The
RADIUS server will not have an opportunity to send a reject message, but it
will still have some state data for a while (as will the EAP server). 

Also the GSS-EAP acceptor will have state data that it keeps around because
the session has not been shut down from either the RADIUS side or the
initiator side.

This means that  there are three entities waiting for something to happen
and nothing going on.  Some of this could be fixed if the initiator closes
the session in the case that it ignores the EAP packet on the grounds that
there is a reliable transport and it knows that it is dead locked.  This
could force a shutdown of state back to the IdP from the acceptor, although
I am not sure at this point what RADIUS message it would send back to spin
down state.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 31 Oct 2012 07:37:42 +0900

> RADIUS server doesn't have anything else to do.

This is not always the case.  See the following text in Section 2.2 of 
RFC 3579:

"
    A RADIUS server determining that a non-fatal error has occurred MAY
    send an Access-Challenge to the NAS including EAP-Message
    attribute(s) as well as an Error-Cause attribute [RFC3576] with value
    202 (decimal), "Invalid EAP Packet (Ignored)".  The Access-Challenge
    SHOULD encapsulate within EAP-Message attribute(s) the most recently
    sent EAP-Request packet (including the same Identifier value). On
    receiving such an Access-Challenge, a NAS implementing previous
    versions of this specification will decapsulate the EAP-Request and
    send it to the peer, which will retransmit the EAP-Response.

    A NAS compliant with this specification, on receiving an
    Access-Challenge with an Error-Cause attribute of value 202 (decimal)
    SHOULD discard the EAP-Response packet most recently transmitted to
    the RADIUS server and check whether additional EAP-Response packets
    have been received matching the current Identifier value.  If so, a
    new EAP-Response packet, if available, MUST be sent to the RADIUS
    server within an Access-Request, and the EAP-Message attribute(s)
    included within the Access-Challenge are silently discarded.  If no
    EAP-Response packet is available, then the EAP-Request encapsulated
    within the Access-Challenge is sent to the peer, and the
    retransmission timer is reset.
"

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 31 Oct 2012 11:24:57 +0200

> the session in the case that it ignores the EAP packet

Well, the EAP packet may be ignored at the EAP layer or at the EAP authentication method layer. 
The EAP lower layer does not know when such a thing happens. 

Alper

> on the grounds that

---

From: Sam Hartman <[email-masked]>
Date: Wed, 31 Oct 2012 07:57:10 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I think he was talking about the RADIUS server not having any
    Jim> EAP data to send back to the client.  And that in that case the
    Jim> server SHOULD send a reject message back.

    Jim> I am looking at the case of the EAP client not having any data
    Jim> to send.  The RADIUS server will not have an opportunity to
    Jim> send a reject message, but it will still have some state data
    Jim> for a while (as will the EAP server).

OK.
I'm sorry, I should not have tried to respond to mail while paying
attention to a session in a conference.

What happens here on the initiator is that the initiator needs to return
some status other than GSS_S_CONTINUE_NEEDED.
GSS_S_COMPLETE is kind of implausible, so GSS_ERROR will be true for
that status.
The initiator then should call gss_delete_sec_context. At this point, the initiator is done and has cleaned up state.

Alper claims that the initiator will not know that the EAP layers have
failed to produce output and are done processing the packet.  I cannot
think of a plausible EAP implementation strategy with this
characteristic, so I suspect Alper is not correct for likely EAP
implementations.  Anything that lets you examine the RFC 4137 state will
allow you to determine what's going on. Certainly anything that you can use for implementing
GSS-EAP has the property that you'll know when it's done with a packet.
The existing GSS C bindings are sufficiently synchronous that you'll
need that property.

After experimenting with other strategies, we've generally come to the
conclusion that applications rather than GSS mechanisms need to be
responsible for signaling initiator failure.
In some protocols you do this with a TCP close.
In some protocols such as IMAP, there's a SASL abort that you signal.

I think  that the GSS mechanism could return an error token at this
point; a quick reading of RFC 2743 2.2.1 is unclear.
However, I'd recommend against changing gss-eap to permit this. 
I think returning an output token with an error status will confuse a
lot of applications.

I do think it would be desirable to add text to draft-ietf-abfab-arch
noting that applications SHOULD have a way to signal authentication
aborts.

--Sam