On Tue, 1 Aug 2023 at 01:00, Eliot Lear <l...@lear.ch> 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
