On Thu, 3 Aug 2023 at 11:10, Eliot Lear <l...@lear.ch> wrote: > I don't think EAP Failure should ever really be contemplated during a > housekeeping operation *unless* an intermediate-success is first > generated, because otherwise we can bet that at least some clients will > take that as a signal that the house keeping operation failed, and they'll > loop retrying. > I would also expect retry and loops when EAP Failure is received. EAP-FAST's recommendation (RFC 5422, section 3.5) of denying access with Server-Unauthenticated Provisioning Mode is taken into account, for example, in wpa_supplicant which has code and comment explaining that EAP Failure is expected and it's not an error.
Because this is not recommended in RFC 7170 TEAP, a success-but-failure could be communicated by signalling it within phase2 so that the peer knows that an EAP Failure for outer EAP is expected. That would be more new functionality that delays the finishing of this draft. That's also the reason why I wrote earlier that maybe in a future (not this RFC update) revision. As was noted earlier, a lot can be handled already with server policy and flexible configuration for different peer and provisioning requirements. > My suggestion would be something along the lines of the following: > > Under normal circumstances, house keeping operations should complete and > the EAP connection SHOULD successfully complete. If a change of > authorization is required for some reason, the server SHOULD make use of a > Radius COA, and not involve the peer so as to not impose excess operations > on the peer (or itself). In exceptional circumstances, a Radius-Disconnect > MAY be used as a signal to a client directly after such operations to > disconnect and authenticate with the new updated credentials. > An option for disconnect could be sending a short Session-Timeout + Termination-Action=RADIUS-Request with Access-Accept. This doesn't depend on working reverse RADIUS path and it can be more reliable than handling dynauth request. I know at least one current device that doesn't work correctly if RADIUS server sends it a dynauth message right after the RADIUS server has received Accounting-Request/Start from the device. It seems like the device must get the new session clearly going before it's able to process a dynauth message correctly. In a typical dynauth case this isn't likely a problem, but receiving a dynauth request a couple of milliseconds after sending Accounting-Request/Start didn't work well. In both cases (CoA message or Session-Timeout + reauth) the device will gain network access for a short while. Is this a problem when the device is malicious? Can a belt-and-suspenders method be to return a 'deny all' packet filter with Access-Request until the CoA or disconnect takes action? -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
