> -----Original Message----- > From: Sam Hartman [mailto:[email protected]] > Sent: Tuesday, October 30, 2012 3:03 AM > To: Jim Schaad > Cc: 'Alan DeKok'; 'Alper Yegin'; [email protected] > Subject: Re: [abfab] EAP Applicability: retransmissions > > >>>>> "Jim" == Jim Schaad <[email protected]> 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.
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 > > --Sam _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
