Alan DeKok <al...@deployingradius.com> wrote:
> I'll note that the peer can always simply stop doing EAP once it's
> fully provisioned. i.e. it doesn't need to get an EAP Failure or EAP
> Success from the server. However, such behavior is unfriendly to the
> server. It leaves the server with a blocked EAP session that has to be
> eventually timed out.
"simply" --- well, that's really exactly what SHOULD happen.
The use of EAP_Failure on the part of the EAP Server is almost a formality.
It probably needs to occur for the benefit of the Authenticator: it might
have have state that can get flushed. Really, the supplicant should ALREADY
be gone.
In RFC8995, we defined two telemetry results, such that if the provisioning
*failed* that one continued with the onboarding connection in order to report
stuff.
BUT, that if it worked, that one was supposed to reconnect with the new
identity and report success. (This is less important than detailed failure)
>> Under the hood, housekeeping operations that update credentials are
>> just updating entries in one or more tables that index to the same
>> device as before, and so absent a change in role of the device, one
I'm unclear if you are talking about renewal of an LDevID, or the first
creation of the LDevID. I agree that renewal could be done without any
forced break of the connection, and probably one wants to do exactly that.
>> shouldn't expect much in the way of a change of authorization policy.
>> There's one BIG exception: expired credentials. Here again, this is
>> server-side policy that might involve sandboxing the device, setting
>> the result to EAP Failure in a request action TLV, opening a trouble
>> ticket, firing an employee, or some such.
> For me, that's just "failure to authenticate". It's already handled
> reasonably well. And since EAP failure is returned, no change of
> authorization is necessary. The user is simply not allowed network
> access.
Agreed.
> I would strongly prefer to avoid requiring RADIUS CoA / Disconnect.
> They're good to have, but not always possible. If the Access-Request
> packets are sent across a TLS tunnel through a NAT gateway, it is
> impossible to send CoA to the NAS.
Point.
> I'll see if I can put some wording around "authorize based on
> _provisioned_ credentials, and not _connecting_ credentials"
> Alan DeKok.
> _______________________________________________ Emu mailing list
> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
