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
