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:
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.
"Yoshihiro" == Yoshihiro Ohba<[email protected]> writes:
>>
>> 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> 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.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
