On Jan 11, 2019, at 8:13 AM, John Mattsson <john.matts...@ericsson.com> wrote: > > The working group did never really discuss the context_value parameter. So > just to bring up the question: Is there any information from the EAP-Requests > and EAP-Responses that should (and could) be included in the context_value to > ensure that the EAP Peer and EAP Sever agree that they have gotten the same > information.
I'll note that the TLS-Exporter function is used after authentication succeeds, which makes a difference to what information can be used. If we use a context_value, we should choose one that has the most information, and therefore the most utility. > E.g. from these messages: > > EAP Peer EAP Server > > EAP-Request/ > <-------- Identity > EAP-Response/ > Identity (Anonymous NAI) --------> > EAP-Request/ > EAP-Type=EAP-TLS > <-------- (TLS Start) I would think that all of the public information (such as the data here) isn't suitable for use in the context_value. Even if it was suitable, what data would we use? If we use certificate privacy and exchange the client cert only in the inner tunnel (i.e. EAP-TLS inside of EAP-TLS). There is minimal data in the outer session that both peer and server can agree on. Well, there's an anonymous NAI, but that isn't good for much. > RFC 5216 does not include any such information in the key derivation, but as > the group has agreed to modify the key derivation mechanism for EAP-TLS 1.3, > it would be relatively easy to add context information is that is believed to > increase current or future security. If we believe the argument above, the only data suitable for use in context_value is data *both* parties know from the inner tunnel exchange. That generally means information related to client / server certificates. And I'm not sure what information from the certs would be used. We presume that the certs are already correct and validated. TLS ensures that the TLS-Exporter function depends on the TLS exchange, which depends on the certs. So using information from the certs seems pointless. And what additional information should be added to TLS-Exporter that would make it *better*? EAP-TLS doesn't provide for a way to peer and server to send additional data, unlike EAP-TTLS, so there isn't much that can be done here In the end, I think any information we could use is already being used to derive TLS-Exporter, and there's no real way to get additional information. And even if there was, it's not clear what information would make the TLS-Exporter "better". Or even what "better" means in this context. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
