On Aug 2, 2023, at 1:49 PM, Eliot Lear <l...@lear.ch> wrote: > I don't think this is a substantive change, because what Heikki is raising is > entirely a matter of server-side policy. I also am not sure it's the right > change. For one thing, if a server is willing to issue a new certificate, > that's likely a policy statement that everything is AOK. For another, this > ISN'T a change of identity, and so there is really no need to re-evaluate > other policy aspects.
The "change of identity" is the important bit, I think. How about this: If the identity changes, as with some provisioning flows. the server SHOULD cause the EAP peer to re-authenticate. This reauthentication can be done by returning an EAP Failure in order to cause the client to reconnect, or via a RADIUS Disconnect-Request packet after authentication, or change the authorization via a RADIUS CoA-Request, via other means. This reauthentication is done in order to ensure that the user or device is accessing the network not only with the correct credentials, Note: this means EAP-Failure is *not* a "provisioning failed" message! On the other hand, if a users credentials are re-provisioned, then the identity is unchanged, and there is no need to change the authorization of the current session. > Finally, in my opinion, it makes sense that during onboarding a device might > need to be classified into a policy group, but if that is to change, then a > COA seems more appropriate at the radius level, rather than forcing a > re-connect. > > Keep this in mind: end devices should be presumed to be pressed for > resources, and anything requiring additional unnecessary authentications > should be avoided in that case. > > But again, this is all server side policy. The only aspect for the client is > that it should know when to re-authenticate if the server requires it. Agreed. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
