On Dec 16, 2020, at 5:36 PM, Benjamin Kaduk via Datatracker <nore...@ietf.org> wrote: > To start with the easy one: currently the way in which the structure of > the Commitment Message is described makes reference to many fields of > TLS Record Layer structures in order to specify what is fundamentally a > message on the TLS Application Data stream. This is a layering > violation; I don't see any reason to say more than what was suggested in > https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ :
I will wave a magic wand of "implementation issues". :( There appears to be few ways to *explicitly* signal that negotiation has completed. i.e. ways which are both implemented in SSL libraries, and available to EAP-TLS implementations. We implemented multiple ways in FreeRADIUS (0 octet of application data and other methods). I'll have to double-check the list archive. But my recollection is that the "0x00" of application data was the least ugly alternative. > Next, the whole reason for the existence of a Commitment Message seems > under-justified -- the only mention I could find in the document is that > it serves "to decrease the uncertainty for the EAP-TLS peer". What harm > would be caused by a lack of certainty in this area? Why does waiting > for an EAP-Success or EAP-Failure not provide a similar level of > certainty? The EAP-Success and EAP-Failure messages are *not* protected. i.e. they are 4-bytes of data which can be spoofed rather trivially. In contrast, the 0 byte is an application-layer signal that EAP-TLS has succeeded. > The commitment message as specified seems to itself be a layering > violation. The TLS protocol itself consists of a few sub-protocols, > e.g., the handshake protocol, record protocol, and alert protocol. The > operation of the handshake protocol is supposed to be completely > independent of the application-data record protocol (except to the > extent that the handshake protocol supplies the keys used for > cryptographic protection of application data records). In particular, > there should not be any interaction between the handshake state machine > and the application data. If there is to be a commitment made about the > operation of the TLS handshake protocol, that more properly belongs in > the handshake layer itself, or perhaps the alert layer if it relates to > the overall operation of the TLS connection. It seems inappropriate and > unsustainable to expect that an application-data message would affect > the operation of the handshake layer. IMHO, it doesn't affect the TLS-layer handshakes. It's a signal specific to EAP-TLS, which is an application using TLS. > The use of application data for the commitment message also may have > unfortunate interactions with other TLS-using EAP methods, which is very > briefly mentioned as a possibility but not explored at all: I have a draft on precisely this issue. We have implemented TLS 1.3 for TTLS and PEAP (hostap && FreeRADIUS). Where they send application data, there is no need for a commitment message. The EAP method sends it's own application data. Where the methods don't send application data (i.e. session resumption), they have the same problem as EAP-TLS, and require a similar solution. In general, a number of your comments here conflate EAP-TLS with other TLS-based EAP methods. This document specifies a standard for EAP-TLS. It doesn't apply to other methods. There are similar issues for other methods, but those methods require method-specific solutions. > Section 2.3 > > The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context > is rather unusual; per RFC 8446 this value is intended to be a > "per-association context value provided by the application using the > exporter" per RFC 5705 -- this value is not a per-association value but > rather a global one. The existing TLS-based EAP methods have consistently used exporters which are global. I'm not even sure what would be used for per-association value. This is EAP, there is generally no underlying transport method (or data) which is consistently available to the EAP layer. i.e. Can you suggest a per-association value which would *work* for EAP? Across RADIUS, Diameter, PANA, ... > Section 5.5 > > It seems like there may be some scope for improvements on the RFC 5216 > behavior here. For example, what if we used the EAP Type field as the > TLS Exporter 'context' argument, instead of the literal 0x0D? The EAP-Type field is 0x0D for EAP-TLS. This value is hard-coded for EAP-TLS. For other EAP types, the use of the field is clarified here; https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 i.e. this document specifies EAP-TLS, and does *not* affect other TLS-based EAP methods. Those are defined elsewhere. > That > seems like it would prevent the modification from successfully causing a > different TLS-based EAP method to be used, by using a different > key-derivation formula, exactly as postulated by RFC 5126. I think there's a misunderstanding here. This document specifies EAP-TLS. It doesn't specify how other TLS-based EAP methods use TLS 1.3. The discussion in the WG, and implementations guided this approach. This document species EAP-TLS. The above referenced document "patches" this one in order to specify the use of TLS 1.3 with other TLS-based EAP methods. > If any authorization, accounting, or policy decisions were made with > information that have 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. [...] > > I'm not sure I understand how these two sentences fit together. Is it > trying to say that "if there could be a different decision, you > definitly have to re-check, and we recommend just always re-checking > since that's timpler"? Pretty much, yes. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
