FYI: the latest update of wolfSSL (February 16, 2021) now claims to implement RFC 5705: Keying Material Exporters for TLS. See: https://github.com/wolfSSL/wolfssl/blob/ef916df1b1f9f9678fe7787e3b864a4b015fe569/README.md#wolfssl-release-470-february-16-2021
The TLS 1.3 exporter here: https://github.com/wolfSSL/wolfssl/blob/94a23c1d4891b750110c6b806181628bffe782cf/src/tls13.c#L763 allows context, but the exporter function defined separately for EAP-TLS does not allow context: https://github.com/wolfSSL/wolfssl/blob/f0ce6ada0fcf99a15b85ddac951e46376df96e4d/src/tls.c#L632. Anyhow, my initial concern that some popular TLS libraries don't support context may not be valid as implementations are updated. I'll check wolfssl more soon. The reason for moving the Type-Code to the label was also based on Ben and Martin's comments. Ben's IESG review for example notes: 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. --Mohit On 2/28/21 12:58 PM, Alan DeKok wrote: On Feb 27, 2021, at 7:10 PM, Joseph Salowey <j...@salowey.net><mailto:j...@salowey.net> wrote: The current draft test specifies the following for key derivation: Type-Code = 0x0D MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK_"+Type-Code, "",64) EMSK = TLS-Exporter("EXPORTER_EAP_TLS_EMSK_"+Type-Code, "",64) Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id_"+Type-Code, "",64) Session-Id = Type-Code || Method-Id A zero-length context (indicated by "") is used in the TLS exporter interface. The EAP-TLS Type-Code of '0D' (in hexadecimal) is appended to the label strings. Other TLS based EAP methods can use exporters in a similar fashion by replacing the EAP-TLS Type-Code with their own Type-Code (encoded as a hexadecimal string). Unless I'm greatly mistaken, the WG already has a draft which updates other TLS-based EAP types. Text about other EAP types does not belong in a document which updates EAP-TLS. If this document should not give advice about TLS internals, then it should not give advice about other TLS methods. The text referring to other EAP types should be removed. The main alternative proposals are to 1) include identity information in the context and 2) include the type code in the context instead of the label. 1) has not received support from the working group 2) is a viable alternative, but it really isn't in the spirit of the context. RFC 8446 Section 7.5 is entirely silent on the subject of what context is for. It refers instead to RFC 5705, which has this to say in Section 4: 3. Binding to Application Contexts In addition to using an exporter to obtain keying material, an application using the keying material has to securely establish the upper-layer context where the keying material will be used. The details of this context depend on the application, but it could include things such as algorithms and parameters that will be used with the keys, identifier(s) for the endpoint(s) who will use the keys, identifier(s) for the session(s) where the keys will be used, and the lifetime(s) for the context and/or keys. The EAP type code is well within the definition of "algorithms and parameters that will be used with the keys". RFC 5705 continues to describe the context as: o Information about the upper-layer context can be included in the optional data after the exporter label (see Section 4). And Section 4 says: The context value allows the application using the exporter to mix its own data with the TLS PRF for the exporter output. One example of where this might be useful is an authentication setting where the client credentials are valid for more than one identity; the context value could then be used to mix the expected identity into the keying material, thus preventing substitution attacks. Using an identity in the context might be useful, except that it is very difficult to define which identity is used. Certificates have multiple fields which could be used, not all fields are required, and many fields can have multiple values. From a practical point of view, it is nearly impossible to include identity information in the context in an inter-operable manner. It doesn't seem to make sense to leave the context blank, and instead shoe-horn more data into the label field. We have the context, nothing else can go there, using the EAP type-code follows RFC 5705, so why not use it? The proposed resolution is to use the type-code in the label as defined above and in draft-14. Please comment on this thread if you disagree. Mixing the type-code in the label is more complex to implement than simply using it in the context. As such, I prefer to use it in the context. Such use falls well within the examples given in RFC 5705. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu