Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
Ok, we might be having an Agree-O-thon... On 04.08.23 11:49, Alan DeKok wrote: Access policies are applied after provisioning has been done. So they are entirely irrelevant until the server replies with an EAP Success. Yes. So COAs and Disconnects aren't necessary at that point. Once the server replies with an EAP Success, access policies should be applied based on the provisioned (i.e. new) credentials. This addresses all of the concerns which were raised over the last few days. Yupper. i.e. there is no "change" of authorization when a user is provisioned. Yup. They're running EAP, and don't have network access. Yup. Since they have no current authorization, it can't be changed. Yup. Instead, they either get EAP Failure or Success. So the only real question is which identity is used as the basis for access policies. And that's simple, too: the new one. Yep. Eliot 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
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
On Aug 4, 2023, at 3:47 AM, Eliot Lear wrote: > 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. I put some additional text in the draft I published yesterday. It describes what to do in various corner cases, and should hopefully help here. > Expired Credentials I think this just falls back to provisioning. If the credentials are expired and not renewed, the user doesn't get access. If the credentials are renewed, they get access. > Not yet expired credentials The updated draft has some text here. It's largely the same as expired credentials, but with one special case. If the credentials are renewed before they expire, then the peer should keep a copy of the old credentials until it can verify that the new credentials work. Otherwise, it all falls back to the previous case of provisioning. > This 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? Access policies are applied after provisioning has been done. So they are entirely irrelevant until the server replies with an EAP Success. Once the server replies with an EAP Success, access policies should be applied based on the provisioned (i.e. new) credentials. This addresses all of the concerns which were raised over the last few days. i.e. there is no "change" of authorization when a user is provisioned. They're running EAP, and don't have network access. Since they have no current authorization, it can't be changed. Instead, they either get EAP Failure or Success. So the only real question is which identity is used as the basis for access policies. And that's simple, too: the new one. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
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 credentials This 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 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
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
On Thu, 3 Aug 2023 at 11:10, Eliot Lear 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
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
Alan DeKok 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. 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
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
On Aug 3, 2023, at 4:10 AM, Eliot Lear 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
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
Hi Alan 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. 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. 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. 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). 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. Regards, Eliot 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
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
On Aug 2, 2023, at 1:49 PM, Eliot Lear 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
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
On Wed, 2 Aug 2023, at 18:49, Eliot Lear wrote: > 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. I could imagine a realtime video streaming device that during a reprovisioning process, the RADIUS server would send an EAP-Failure to force a full authentication resulting in the authenticator starting to drop hard traffic until it is told otherwise. For this reason I do not think forcing a full authentication in such a manner is going to be desirable. > 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. I agree. Policy already has to handle "do not allow chaining session resumptions indefinitely" and the recommendation is to redo at least part of the authorisation step again to catch things like account expiry/disabled, time of day restrictions and what not. For user credential backed EAP methods, if a user's password is changed existing sessions should be forced to re-authenticate if not forcibly disconnected. Of course this event may be because the password has been leaked but the 'what' to do is policy not protocol. Cheers ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
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. 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. Eliot On 02.08.23 02:59, Alan DeKok wrote: On Aug 1, 2023, at 7:08 PM, Heikki Vatiainen wrote: Using the above as an example case: When a client renews a certificate, should the server mark the current TLS session as non-resumable? With EAP-TLS, the server never knows immediately, because renewal is not in-band, when a certificate is renewed, therefore this is not an issue for EAP-TLS. Here we know that a renewal is in process and can take immediate action. While it's possible that the certificate renewal is for non-TEAP use, it shouldn't harm if the next authentication is full authentication. These are all good points I wish I had thought of earlier. i.e. any provisioning step should really be limited to provisioning. The user should immediately drop the connection, and then reconnect using the provisioned credentials. This means that any authorization phase always operates the same way, on full credentials. And there is no mixing of provisioning + "real" authorization. The simplest way to do this may be to require that any provisioning phase result in EAP Failure. The inner tunnel can return the credentials, crypto-binding TLV, and a Result TLV which indicates success. But the final outer EAP packet should be EAP Failure. I'm unsure if this is a substantive change to the document at this phase. Given that no one has implemented PKCS provisioning yet, it may be acceptable to make this change. In general, here are some implementation related thoughts: First, when housekeeping services are run in phase 2, should the current TLS session be made non-resumable? Yes. If Phase 2 is provisioning, OR if the users credentials are expired / renewed in Phase 2, the current TLS session must be non-resumable. The draft uses password and PIN change as examples of "housekeeping" and I'd say certificate renewal and peer's use of Trusted-Server-Root TLV are also "housekeeping" functions. Most, if not all, of these housekeeping services update or affect peer's credentials and for this reason, it may be desired to force full authentication the next time the peer authenticates again. More exactly: all currently cached TLS sessions with the peer may need to be considered as non-acceptable for resumption. Yes. Second, in many cases there's some type of authorisation that follows successful authentication. For example, VLAN assignment may be returned with RADIUS Access-Accept that carries the EAP-Success. Maybe the draft should give implementation guidance on being careful to ensure that authorisation happens in controlled fashion? I would say that authorization only follows full authentication. It cannot follow a provisioning step. To put this differently, EAP-Success doesn't happen in vacuum but grants access to something. If housekeeping gets differently authorised access, then the server must be careful to handle correctly those clients that try something that a well-behaved client does not do. For example, if peer authorisation happens differently when housekeeping is done, the server should be careful to decline TLS resumption or otherwise the client may get a shortcut to the housekeeping network. That is: resumption ok => Crypto-Binding TLS + Intermediate-Result TLV + Result TLV all saying success => access to housekeeping network without housekeeping. That's hard to manage. It may be easier to just mandate that servers reply with EAP Failure after a provisioning step. Another example: If the client does TLS resumption and then proceeds to housekeeping, the server must be careful to ensure that authentication information cached from the last full authentication is still fresh enough for the housekeeping purposes. Yes. Third, EAP-FAST Dynamic Provisioning RFC 5422 suggests denying after Server-Unauthenticated Provisioning Mode. https://datatracker.ietf.org/doc/html/rfc5422#section-3.5 Would this type of functionality useful for some housekeeping cases? I've
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
Alan DeKok wrote: > The simplest way to do this may be to require that any provisioning > phase result in EAP Failure. The inner tunnel can return the > credentials, crypto-binding TLV, and a Result TLV which indicates > success. But the final outer EAP packet should be EAP Failure. > I'm unsure if this is a substantive change to the document at this > phase. Given that no one has implemented PKCS provisioning yet, it may > be acceptable to make this change. This seems reasonable to me. -- Michael Richardson. 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
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
On Aug 1, 2023, at 7:08 PM, Heikki Vatiainen wrote: > Using the above as an example case: When a client renews a certificate, > should the server mark the current TLS session as non-resumable? With > EAP-TLS, the server never knows immediately, because renewal is not in-band, > when a certificate is renewed, therefore this is not an issue for EAP-TLS. > Here we know that a renewal is in process and can take immediate action. > While it's possible that the certificate renewal is for non-TEAP use, it > shouldn't harm if the next authentication is full authentication. These are all good points I wish I had thought of earlier. i.e. any provisioning step should really be limited to provisioning. The user should immediately drop the connection, and then reconnect using the provisioned credentials. This means that any authorization phase always operates the same way, on full credentials. And there is no mixing of provisioning + "real" authorization. The simplest way to do this may be to require that any provisioning phase result in EAP Failure. The inner tunnel can return the credentials, crypto-binding TLV, and a Result TLV which indicates success. But the final outer EAP packet should be EAP Failure. I'm unsure if this is a substantive change to the document at this phase. Given that no one has implemented PKCS provisioning yet, it may be acceptable to make this change. > In general, here are some implementation related thoughts: > > First, when housekeeping services are run in phase 2, should the current TLS > session be made non-resumable? Yes. If Phase 2 is provisioning, OR if the users credentials are expired / renewed in Phase 2, the current TLS session must be non-resumable. > The draft uses password and PIN change as examples of "housekeeping" and I'd > say certificate renewal and peer's use of Trusted-Server-Root TLV are also > "housekeeping" functions. Most, if not all, of these housekeeping services > update or affect peer's credentials and for this reason, it may be desired to > force full authentication the next time the peer authenticates again. More > exactly: all currently cached TLS sessions with the peer may need to be > considered as non-acceptable for resumption. Yes. > Second, in many cases there's some type of authorisation that follows > successful authentication. For example, VLAN assignment may be returned with > RADIUS Access-Accept that carries the EAP-Success. Maybe the draft should > give implementation guidance on being careful to ensure that authorisation > happens in controlled fashion? I would say that authorization only follows full authentication. It cannot follow a provisioning step. > To put this differently, EAP-Success doesn't happen in vacuum but grants > access to something. If housekeeping gets differently authorised access, then > the server must be careful to handle correctly those clients that try > something that a well-behaved client does not do. > > For example, if peer authorisation happens differently when housekeeping is > done, the server should be careful to decline TLS resumption or otherwise the > client may get a shortcut to the housekeeping network. That is: resumption ok > => Crypto-Binding TLS + Intermediate-Result TLV + Result TLV all saying > success => access to housekeeping network without housekeeping. That's hard to manage. It may be easier to just mandate that servers reply with EAP Failure after a provisioning step. > Another example: If the client does TLS resumption and then proceeds to > housekeeping, the server must be careful to ensure that authentication > information cached from the last full authentication is still fresh enough > for the housekeeping purposes. Yes. > Third, EAP-FAST Dynamic Provisioning RFC 5422 suggests denying after > Server-Unauthenticated Provisioning Mode. > https://datatracker.ietf.org/doc/html/rfc5422#section-3.5 > Would this type of functionality useful for some housekeeping cases? I've > seen that, for example, wpa_supplicant as EAP-FAST client supports this. If > TEAP is used in some cases for housekeeping-only functions, a way to ensure > that this doesn't always result with client getting network access too, might > be useful. Maybe for a future revision? Since no one actually does provisioning now, it's worth fixing now. > To summarise: Using an authentication protocol for provisioning appears to > create interesting scenarios to consider. I hope the above points are found > useful. More are likely found when working on implementing the provisioning > parts, which we haven't done yet. We can only write down what we know now. :( Given timing and implementation status, I believe it's worth publishing the document quickly. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
On Tue, 1 Aug 2023 at 01:00, Eliot Lear wrote: > IoT devices need a way to authenticate as TEAP is EAP-TLS under nominal > conditions. When a certificate is about to expire, then the expectation is > that either the client will issue a PKCS#10 request *or* the server will > issue a request action TLV with PKCS#10, so that the client knows the > server wants it to renew. > Forking this thread a bit. The above TEAP's EAP-TLS -like functionality relates to the comments I had during the last week's meeting. Now that I've had time to think about them more, I'd like to add some clarifications. Using the above as an example case: When a client renews a certificate, should the server mark the current TLS session as non-resumable? With EAP-TLS, the server never knows immediately, because renewal is not in-band, when a certificate is renewed, therefore this is not an issue for EAP-TLS. Here we know that a renewal is in process and can take immediate action. While it's possible that the certificate renewal is for non-TEAP use, it shouldn't harm if the next authentication is full authentication. In general, here are some implementation related thoughts: First, when housekeeping services are run in phase 2, should the current TLS session be made non-resumable? The draft uses password and PIN change as examples of "housekeeping" and I'd say certificate renewal and peer's use of Trusted-Server-Root TLV are also "housekeeping" functions. Most, if not all, of these housekeeping services update or affect peer's credentials and for this reason, it may be desired to force full authentication the next time the peer authenticates again. More exactly: all currently cached TLS sessions with the peer may need to be considered as non-acceptable for resumption. Second, in many cases there's some type of authorisation that follows successful authentication. For example, VLAN assignment may be returned with RADIUS Access-Accept that carries the EAP-Success. Maybe the draft should give implementation guidance on being careful to ensure that authorisation happens in controlled fashion? To put this differently, EAP-Success doesn't happen in vacuum but grants access to something. If housekeeping gets differently authorised access, then the server must be careful to handle correctly those clients that try something that a well-behaved client does not do. For example, if peer authorisation happens differently when housekeeping is done, the server should be careful to decline TLS resumption or otherwise the client may get a shortcut to the housekeeping network. That is: resumption ok => Crypto-Binding TLS + Intermediate-Result TLV + Result TLV all saying success => access to housekeeping network without housekeeping. Another example: If the client does TLS resumption and then proceeds to housekeeping, the server must be careful to ensure that authentication information cached from the last full authentication is still fresh enough for the housekeeping purposes. Third, EAP-FAST Dynamic Provisioning RFC 5422 suggests denying after Server-Unauthenticated Provisioning Mode. https://datatracker.ietf.org/doc/html/rfc5422#section-3.5 Would this type of functionality useful for some housekeeping cases? I've seen that, for example, wpa_supplicant as EAP-FAST client supports this. If TEAP is used in some cases for housekeeping-only functions, a way to ensure that this doesn't always result with client getting network access too, might be useful. Maybe for a future revision? To summarise: Using an authentication protocol for provisioning appears to create interesting scenarios to consider. I hope the above points are found useful. More are likely found when working on implementing the provisioning parts, which we haven't done yet. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
