Hi Alan,Having given this a bit of thought, I think we are chasing our tails, and no text is required. Let's look at two cases: expired credentials, and credentials that have not yet expired.
Expired Credentials Handling an expired credential occurs in one of several ways in enterprises: 1. Don't bother doing anything at the network level and sort it at the application level (e.g., just allow access) 2. Don't bother doing anything at the network level *for now* and sort it on re-connect (this is a good case simply deleting the ticket, for example), and then into a sandbox. 3. CoA into a sandbox 4. Radius disconnect, and then into a sandbox. 5. Radius disconnect and then make use of request action(Result=Failure,...)Most IoT can't handle 2-4 (what does it mean to put a device without a display into a sandbox?!), and may not even be able to handle 5!
My experience is that most enterprises use (1) while SPs don't normally rotate credentials at all, *although that may change*. There are *definitely* exceptions. In any case, we can take the first use case off the table since it's not our problem. (2) doesn't require anything new on-the-wire. (3) and (4) require implementation of either CoA or Disconnect and are independent of EAP. 5 is new, but it's a pretty hard fail that *might* be appropriate so long as it really is recoverable.**
Now we get to the point where the credential has been renewed, and that was what we were discussing. Once the credential has been renewed, cases 2-4 need to be dealt with. 3 and 4 require a tie in to some sort of application infrastructure and would require either a CoA or a Disconnect, and it's not happening at the EAP layer. 5 doesn't require a CoA or a disconnect, since EAP is not yet complete.
Not yet expired credentialsThis now leaves the case where a renewal is taking place *prior* to credential expiration. The *only* issue here is really whether there is any case that, based on renewal alone, an access policy change would ever take place *during* an ongoing communication. My suggestion would be to recommend against such an action in the RFC, but if it is required, if we're in an EAP exchange then authorization will follow and there is no need for a CoA/Disconnect, since radius authorization information will follow.
What am I missing? Eliot On 03.08.23 16:07, Alan DeKok wrote:
On Aug 3, 2023, at 4:10 AM, Eliot Lear<l...@lear.ch> wrote:I think it's good to consider what's going on on both sides here. At the beginning, both the identity and the role of the device in a network may be unknown, and so a certain access is given. After bootstrapping has occurred (however that happens), then both the role of the device and the identity is established. If the role of the device changes, then a COA seems appropriate where possible, or otherwise a Radius Disconnect.My one concern is that not all systems may support RADIUS CoA or Disconnect. The original spec (3576) is only 20 years old.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.Since no one does provisioning yet, we have time to fix this. But yes, there must be an intermediate success. If we do require that provisioning finishes with EAP Failure, Section 3.4.4 already suggests that a peer may received a Result TLV with Success from the server, and reply with a Request-Action indicating Success or Failure. The server can then ignore that, or reply with more negotiation. Perhaps we could state that upon finishing of provisioning, the peer replies with Request-Action TLV, Status Failure, Action 3 Provisioning finished, and no TLVs. The server can then reply with EAP Failure. 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. But that may not be necessary, see below.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 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. I suppose that for provisioning, the provisioning step happens *before* the final EAP Success or EAP Failure. That means any authorization rules can be applied based on the _provisioned_ credentials, and not on the _connecting_ credentials. I suppose that's OK, and would address all of my concerns about changing authorization. It may be best to just explain that requirement, and not add anything else new to the document.Let's also consider the crypto here. The session key that was derived from a full authentication is still valid for resumption so long as one trusts the keying material to not have been observed/obtained. That is independent of the cert/user password update taking place. What I'm getting at is that house keeping operations are MOSTLY independent of authorization decisions (excluding expired credentials).OK. 9190 also discusses issues around resumption and authorization changes. See the bottom of Section 5.7:If any authorization, accounting, or policy decisions were made with information that has changed between the initial full handshake and resumption, and if change may lead to a different decision, such decisions MUST be reevaluated. It is RECOMMENDED that authorization, accounting, and policy decisions are reevaluated based on the information given in the resumption.This presumably also applies to accounts being disabled, passwords changed, etc.Coming back to your wording: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,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.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. I'll see if I can put some wording around "authorize based on _provisioned_ credentials, and not _connecting_ credentials" Alan DeKok.
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
