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
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-09.txt
On Aug 1, 2023, at 5:08 AM, Eliot Lear wrote: > This just reverses the order of two paragraphs and visually separates outer / > inner definitions. We could in theory do the same with phase 1/phase 2, but > I think this is good enough. That looks good, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-09.txt
On 01.08.23 04:02, Alan DeKok wrote:
On Jul 31, 2023, at 6:00 PM, Eliot Lear wrote:
We're not quite done. The following text needs to be removed, an additional
example added:
If there is no Phase 2 data, then the EAP
server MUST reject the session. There is no reason to have TEAP
devolve to EAP-TLS.
The intent was clarified in the next paragraph:
Note that the Phase 2 data could simply be a Result TLV with value
Success, along with a Crypto-Binding TLV and Intermediate-Result TLV.
This Phase 2 data serves as a protected success indication as
discussed in {{RFC9190}} Section 2.1.1
i.e. TEAP with outer client certificate and no Phase 2 crypto-binding seems
wrong.
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.
Sure.
Perhaps the text could just remove the last sentence about devolving to
EAP-TLS.
Yes, I think that would do nicely, thanks, along with the diagram
demonstrating it (I think I sent that along to you). Also, I would
suggest a small editorial change to help call out the really important
concept of outer versus inner, as follows:
OLD:
TEAP packets may include TLVs both inside and outside the TLS tunnel.
The term "Outer TLVs" is used to refer to optional TLVs outside the
TLS tunnel, which are only allowed in the first two messages in the
TEAP protocol. That is the first EAP-server-to-peer message and
first peer-to-EAP-server message. If the message is fragmented, the
whole set of messages is counted as one message. The term "Inner
TLVs" is used to refer to TLVs sent within the TLS tunnel. In TEAP
Phase 1, Outer TLVs are used to help establish the TLS tunnel, but no
Inner TLVs are used. In Phase 2 of the TEAP conversation, TLS
records may encapsulate zero or more Inner TLVs, but no Outer TLVs.
Methods for encapsulating EAP within carrier protocols are already
defined. For example, IEEE 802.1X [IEEE.802-1X.2013] may be used to
transport EAP between the peer and the authenticator; RADIUS
[RFC3579] or Diameter [RFC4072] may be used to transport EAP between
the authenticator and the EAP server.
NEW
Methods for encapsulating EAP within carrier protocols are already
defined. For example, IEEE 802.1X [IEEE.802-1X.2013] may be used to
transport EAP between the peer and the authenticator; RADIUS
[RFC3579] or Diameter [RFC4072] may be used to transport EAP between
the authenticator and the EAP server.
2.3 Outer TLVs versus Inner TLVs
TEAP packets may include TLVs both inside and outside the TLS tunnel
defined as follows:
Outer TLV: this term is used to refer to optional TLVs outside the
TLS tunnel, which are only allowed in the first two
messages in the TEAP protocol. That is the first,
EAP-server-to-peer message and first peer-to-EAP-server
message. If the message is fragmented, the whole set
of messages is counted as one message.
Inner TLV: this term is used to refer to TLVs sent within the TLS
tunnel.
In TEAP Phase 1, Outer TLVs are used to help establish the TLS
tunnel, but no Inner TLVs are used. In Phase 2 of the TEAP
conversation, TLS records may encapsulate zero or more Inner TLVs,
but no Outer TLVs.
This just reverses the order of two paragraphs and visually separates
outer / inner definitions. We could in theory do the same with phase
1/phase 2, but I think this is good enough.
Thanks,
Eliot
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
