Re: [Emu] More TEAP issues
On Dec 16, 2022, at 6:42 AM, Owen Friel (ofriel) wrote: > > There are a few useful TLVs defined in > https://datatracker.ietf.org/doc/html/draft-lear-eap-teap-brski-06 > > CSR Attributes as Eliot has mentioned, as well as e.g. Retry-After TLV which > could be useful if the TEAP server has to communicate with a backend CA to > get a PKCS#10 CSR signed. While these are useful, I think we need to take care with extending the document. If updates are just defining new TLVs, that seems OK. Anything past that will push out the publication date, which is problematic. > There is also a cert issuance use case that > https://www.rfc-editor.org/rfc/rfc7170#section-3.8.2 does not account for. > The section recommends using tls-unique channel binding in the PKCS#10 CSR so > that server can verify that the client holds the private key associated with > the public key in the CSR. This assumes that the public/private keypair were > used in the outer tunnel TLS handshake. This makes sense if a client is using > an LDevID to establish the TEAP tunnel, and wants to reenroll to get a new > LDevID that has the same keypair e.g. the cert is about to expire. > > It does not account for the bootstrapping use case where a client has a > manufacturing time installed IDevID and needs a deployment-specific LDevID > for network access. It establishes the outer tunnel using the keys in its > IDevID, but is sending a PKCS#10 CSR with different keys. Therefore the > proposed tls-unique binding will fail. Maybe addressing this (and the various > TLVs proposed in draft-lear-eap-teap-brski) is too much to bite off in > rfc7170bis and we need to revisit and address in draft-lear-eap-teap-brski. If we can make the TLVs generic, that may be possible. i.e. define a new TLV, but without going into details about use-cases. That way multiple use-cases can leverage the TLV. i.e. if the TLV is specific to brski bootstrapping, it shouldn't go into the 7170-bis document. If they're generic "contains CSR stuff...", then could be useful to add them, and note that detailed use-cases come later. But my inclination is to just patch 7170 based on implementation experience, and change nothing else. That way it can go out the door quickly, and be used in shipping products. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] More TEAP issues
There are a few useful TLVs defined in https://datatracker.ietf.org/doc/html/draft-lear-eap-teap-brski-06 CSR Attributes as Eliot has mentioned, as well as e.g. Retry-After TLV which could be useful if the TEAP server has to communicate with a backend CA to get a PKCS#10 CSR signed. There is also a cert issuance use case that https://www.rfc-editor.org/rfc/rfc7170#section-3.8.2 does not account for. The section recommends using tls-unique channel binding in the PKCS#10 CSR so that server can verify that the client holds the private key associated with the public key in the CSR. This assumes that the public/private keypair were used in the outer tunnel TLS handshake. This makes sense if a client is using an LDevID to establish the TEAP tunnel, and wants to reenroll to get a new LDevID that has the same keypair e.g. the cert is about to expire. It does not account for the bootstrapping use case where a client has a manufacturing time installed IDevID and needs a deployment-specific LDevID for network access. It establishes the outer tunnel using the keys in its IDevID, but is sending a PKCS#10 CSR with different keys. Therefore the proposed tls-unique binding will fail. Maybe addressing this (and the various TLVs proposed in draft-lear-eap-teap-brski) is too much to bite off in rfc7170bis and we need to revisit and address in draft-lear-eap-teap-brski. -Original Message- From: Emu On Behalf Of Eliot Lear Sent: Wednesday 30 November 2022 06:24 To: Joseph Salowey ; Alan DeKok Cc: EMU WG Subject: Re: [Emu] More TEAP issues I'd support a revision as well. See below: On 30.11.22 02:14, Joseph Salowey wrote: > [Joe] speaking as a participant, I'd be happy to assist with a > revision. I think it is needed. Most of the current errata are > tracked here - https://github.com/emu-wg/teap-errata/pulls. I think > the target would be to obsolete 7170 with a revision that just fixes > the errata and makes any needed clarifications. We can also work on > posting the Errata, but the revised document would be more effective > at getting these issues fixed. I'd also like to take some time to consider what additional TLVs may be required. Right now there is an incongruence between TEAP and other protocols that sign certs in that there is no CSR attributes TLV. There may be several others to consider. Eliot ___ 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
Re: [Emu] More TEAP issues
On Wed, Nov 30, 2022 at 03:01:08PM +, Alexander Clouter wrote: > On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote: > > Based on interoperability testing, it looks like implementations > > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170: > EAP-FAST almost does not document this until you look at a latter RFC > covering the provisioning component: > > https://www.rfc-editor.org/rfc/rfc5422#section-3.2.3 And that section has a history of its own.. If you take a look at the latest draft (-10), that language is not there, i.e., it got added quite late in the process and the related discussions were not exactly considering this positively. If I remember correctly, this mismatch with how EAP-MSCHAPv2 was defined was seen as something that should not really have been done and the EAP-FAST-MSCHAPv2 was named such to be distinguished from EAP-MSCHAPv2 and also as a reminder not to use this variant for anything else than EAP-FAST (which had already been deployed with it). Nevertheless, here we are 15 years later hitting this exact same thing with TEAP having been deployed with the design that was not supposed to be repeated.. > Really easy to miss for an implementer, especially as when you start > implementing FAST (or TEAP) you begin with authentication and think you can > ignore the PAC component at first. While I started working on TEAP implementation by copying FAST implementation to be the starting point, one of my first steps was to try to remove all the hacks needed to get EAP-FAST interoperable since I was familiar with the history.. But yes, it would be next to impossible to implement either EAP-FAST or EAP-TEAP based on just the RFCs and get to something that interoperates with anything already deployed. > The other biggy is that it is easy to miss that for each EAP method in a > sequence, you need to include an EAP Identity response along with the > Identity-Type TLV to the peer. And that will hopefully not include another instance of Crypto-Binding for the EAP-Identity exchange. This is related to one of my errata comments on EAP method vs. EAP authentication method (the latter needs crypto binding; the former probably does not, but RFC 7170 is not clear). > > 3) declare 7170 irretrievably broken, and write 7170bis which > > documents how TEAP version 1 operates in practice. > > This is my preference too. While this might not result in the cleanest protocol design, I'd agree that this is likely the best approach from the view point of getting something useful out there and into wider use. Regarding a separate comment about new TLVs (and new functionality in general, I'd guess), I have no significant issues including that in a new RFC, but I do hope that the initial focus would be in addressing the existing areas and already identified issues to get to a point where there is a clearly identifiable Internet-Draft describing how one can successfully implement EAP-TEAP in a manner that interoperates with deployed implementations. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] More TEAP issues
Hello, On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote: > Based on interoperability testing, it looks like implementations > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170: > > http://lists.infradead.org/pipermail/hostap/2022-July/040639.html > > http://lists.infradead.org/pipermail/hostap/2022-November/041060.html EAP-FAST almost does not document this until you look at a latter RFC covering the provisioning component: https://www.rfc-editor.org/rfc/rfc5422#section-3.2.3 Really easy to miss for an implementer, especially as when you start implementing FAST (or TEAP) you begin with authentication and think you can ignore the PAC component at first. I suspect Microsoft and Cisco just cut'n'pasted from their FAST implementation and used it whilst implementing TEAP and never looked back. It worked as they may have both done this. The other biggy is that it is easy to miss that for each EAP method in a sequence, you need to include an EAP Identity response along with the Identity-Type TLV to the peer. Windows 10/11 wonderfully from their UI configure (as labelled) 'first' and 'second' method, but after completing the first if the server does not ask for the identity of the second, Windows will return a zero length identity and then refuse to go any further; well I was unable to persuade it. Once you figure this out, it sort of makes sense (thinking of how a peer may have chosen to implement its state machine and that as a server you may want to proxy a given method) but EAP sequences themselves are not really well defined. EAP (https://www.rfc-editor.org/rfc/rfc3748#section-2.1) only covers that outside a tunnel this is not supported. FAST (https://www.rfc-editor.org/rfc/rfc4851#section-3.3.1) and TEAP (https://www.rfc-editor.org/rfc/rfc7170.html#section-3.3.1) states why they are allowed to use sequences and only because of Intermediate-Result/Crypto-Binding TLVs. I have not yet found anything that provides guidance on how to actually do an EAP sequence. FAST (https://www.rfc-editor.org/rfc/rfc4851#appendix-A.6) does not state you need to send a EAP Identity at the start of each method other than for the first one. I do not know if this is accurate as we never implemented for FreeRADIUS sequences for FAST. TEAP (https://www.rfc-editor.org/rfc/rfc7170.html#appendix-C.6) also does not, but I know from the FreeRADIUS implementation it was needed to get sequences to work. It took this implementer quite a while to realise that each EAP method in a sequence stands alone to the others and needs to be initiated with an EAP-Identity response. > 3) declare 7170 irretrievably broken, and write 7170bis which > documents how TEAP version 1 operates in practice. This is my preference too. Whilst this is all in my head, having just done the FreeRADIUS/hostapd/Win10/Win11 interop work, I willing to kick off process by updating the existing RFC. Fortunately during my work I also submitted fixes to Wireshark so since 4.0 you get TEAP decoding and inner EAP-TLS decryption so this allows us to share PCAPs of this in the wild. Hopefully with that people here can use it to fix up my notes to remove any further ambiguity if that sounds useful to others? Thanks Alex ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] More TEAP issues
On Nov 30, 2022, at 1:24 AM, Eliot Lear wrote: > I'd also like to take some time to consider what additional TLVs may be > required. Right now there is an incongruence between TEAP and other > protocols that sign certs in that there is no CSR attributes TLV. There may > be several others to consider. While I'm wary of extending the scope of a "fix errata" -bis document, "making it work" is also a high priority. So, yes. Adding more TLVs is fine. Current implementations don't use them, but they could be updated without affecting interoperability. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] More TEAP issues
I'd support a revision as well. See below: On 30.11.22 02:14, Joseph Salowey wrote: [Joe] speaking as a participant, I'd be happy to assist with a revision. I think it is needed. Most of the current errata are tracked here - https://github.com/emu-wg/teap-errata/pulls. I think the target would be to obsolete 7170 with a revision that just fixes the errata and makes any needed clarifications. We can also work on posting the Errata, but the revised document would be more effective at getting these issues fixed. I'd also like to take some time to consider what additional TLVs may be required. Right now there is an incongruence between TEAP and other protocols that sign certs in that there is no CSR attributes TLV. There may be several others to consider. Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] More TEAP issues
On Tue, Nov 29, 2022 at 2:35 PM Alan DeKok wrote: > Based on interoperability testing, it looks like implementations > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170: > > http://lists.infradead.org/pipermail/hostap/2022-July/040639.html > > http://lists.infradead.org/pipermail/hostap/2022-November/041060.html > > I think this issue is larger than an errata. We now have shipping code > (Windows 10, Windows 11, and Cisco ISE at least) which don't follow RFC > 7170. But which do interoperate with each other. > > Hostap / wpa_supplicant follows 7170, but doesn't interoperate with > Windows. > > FreeRADIUS is currently being updated to support TEAP. For reasons of > interoperability, we'd probably choose to follow Windows. > > The question is what to do next? > > I would suggest that at this point, shipping code is more important than > theoretical specifications. The implementors have shipped interoparable > versions, and shipped millions of devices with a particular implementation. > > So our choices are: > > 1) declare the implementations broken, and update 7170 with minor tweaks > for what "should" happen. New implementations will do ??? and current > implementations will do ??? > > 2) declare 7170 irretrievably broken, and write 7170bis which defines TEAP > version 2. That document can define TEAP behavior as ??? > > 3) declare 7170 irretrievably broken, and write 7170bis which documents > how TEAP version 1 operates in practice. > > My preference would be (3). I'd also prefer to get agreement in EMU > that this is the way forward, so we can ship FreeRADIUS with a "correct" > implementation. I would very much prefer to not add to the mess by > shipping code which fails to follow RFC 7170 and which also fails to follow > existing implementations. > > If the WG agrees, I'd be OK acting as editor for RFC 7170bis. The goal > would be to change as little as possible of the text. Just fix the errata, > and add a note saying "ignore 7170, as it's wrong". 99% of the text is OK, > and can be left as-is. > > [Joe] speaking as a participant, I'd be happy to assist with a revision. I think it is needed. Most of the current errata are tracked here - https://github.com/emu-wg/teap-errata/pulls. I think the target would be to obsolete 7170 with a revision that just fixes the errata and makes any needed clarifications. We can also work on posting the Errata, but the revised document would be more effective at getting these issues fixed. > This issue is getting timely, as there is now strong customer demand for > TEAP in Q1 / Q2 2023. So it would be good to get consensus before going > down any particular path. > > Alan DeKok. > > ___ > 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] More TEAP issues
Based on interoperability testing, it looks like implementations followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170: http://lists.infradead.org/pipermail/hostap/2022-July/040639.html http://lists.infradead.org/pipermail/hostap/2022-November/041060.html I think this issue is larger than an errata. We now have shipping code (Windows 10, Windows 11, and Cisco ISE at least) which don't follow RFC 7170. But which do interoperate with each other. Hostap / wpa_supplicant follows 7170, but doesn't interoperate with Windows. FreeRADIUS is currently being updated to support TEAP. For reasons of interoperability, we'd probably choose to follow Windows. The question is what to do next? I would suggest that at this point, shipping code is more important than theoretical specifications. The implementors have shipped interoparable versions, and shipped millions of devices with a particular implementation. So our choices are: 1) declare the implementations broken, and update 7170 with minor tweaks for what "should" happen. New implementations will do ??? and current implementations will do ??? 2) declare 7170 irretrievably broken, and write 7170bis which defines TEAP version 2. That document can define TEAP behavior as ??? 3) declare 7170 irretrievably broken, and write 7170bis which documents how TEAP version 1 operates in practice. My preference would be (3). I'd also prefer to get agreement in EMU that this is the way forward, so we can ship FreeRADIUS with a "correct" implementation. I would very much prefer to not add to the mess by shipping code which fails to follow RFC 7170 and which also fails to follow existing implementations. If the WG agrees, I'd be OK acting as editor for RFC 7170bis. The goal would be to change as little as possible of the text. Just fix the errata, and add a note saying "ignore 7170, as it's wrong". 99% of the text is OK, and can be left as-is. This issue is getting timely, as there is now strong customer demand for TEAP in Q1 / Q2 2023. So it would be good to get consensus before going down any particular path. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
