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] I-D Action: draft-ietf-emu-rfc7170bis-10.txt
The diff is perhaps more interesting: https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-rfc7170bis-09&url2=draft-ietf-emu-rfc7170bis-10&difftype=--html * clarify terminology on inner / outer TLVs as per Eliot's suggestion * add paragraphs on resumption and provisioning as per recent discussion on the list. I believe that this addresses all concerns. > On Aug 3, 2023, at 2:30 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the EAP Method Update (EMU) > WG of the IETF. > > Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1 > Author : Alan DeKok > Filename: draft-ietf-emu-rfc7170bis-10.txt > Pages : 104 > Date: 2023-08-03 > > Abstract: > This document defines the Tunnel Extensible Authentication Protocol > (TEAP) version 1. TEAP is a tunnel-based EAP method that enables > secure communication between a peer and a server by using the > Transport Layer Security (TLS) protocol to establish a mutually > authenticated tunnel. Within the tunnel, TLV objects are used to > convey authentication-related data between the EAP peer and the EAP > server. This document obsoletes RFC 7170. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-10.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-rfc7170bis-10 > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] I-D Action: draft-ietf-emu-rfc7170bis-10.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the EAP Method Update (EMU) WG of the IETF. Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1 Author : Alan DeKok Filename: draft-ietf-emu-rfc7170bis-10.txt Pages : 104 Date: 2023-08-03 Abstract: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-10.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-rfc7170bis-10 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] [IANA #1277499] expert review for draft-ietf-emu-aka-pfs (eapsimaka-numbers)
Dear Vesa Lehtovirta (cc: emu WG), We would like to follow-up on this expert review request. As the designated expert for the Attribute Types (Skippable Attributes 128-255) registry, can you review the proposed registrations in draft-ietf-emu-aka-pfs-11 for us? Please see https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/ The due date is August 10th, 2023. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/eapsimaka-numbers/ With thanks, David Dong IANA Services Sr. Specialist On Thu Jul 27 20:23:13 2023, david.dong wrote: > Dear Vesa Lehtovirta (cc: emu WG), > > As the designated expert for the Attribute Types (Skippable Attributes > 128-255) registry, can you review the proposed registration in draft- > ietf-emu-aka-pfs for us? Please see > > https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/ > > The due date is August 10th, 2023. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/eapsimaka-numbers/ > > With thanks, > > David Dong > IANA Services Specialist ___ 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 C
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
