On Mon, Feb 1, 2021 at 9:12 AM Benjamin Kaduk <ka...@mit.edu> wrote: > Hi Alan, > > I'll second the thanks for putting this together; I think it covers the > important open points. > > I did belatedly remember one more thing that is perhaps not critical, but > would also be good to get an answer for: > > On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote: > [...] > > > > DISCUSS: other than word-smithing the above points, are there serious > objections to the behaviour documented in -13? i.e. does the IETF want to > recommend that EAP-TLS alpha testing begins *now*, or should it wait until > 2022? > > I think that an exchange between Martin and Mohit raised the question of > whether the EAP server-id and peer-id would be available for use in the > 'context' argument of the TLS Exporter, as that would help strengthen the > binding between keys and the authentication exchange. > I do recall a mention that WolfSSL doesn't support a context argument for > the exporter, but I don't know how prohibitive that limitation would be in > practice. > > [Joe] This could also address the early export of keys before the peer is authenticated. RFC 5216 provides a canonical way to create these IDs, but I'm not sure anyone follows it today and it may be difficult to implement in practice due to ordering. It might be simpler to just specify that the end entity peer and client certificates are used in the key derivation. Most libraries provide APIs to get the raw certs. It looks like the WolfSSL API that Mohit linked is specifically for RFC5216 EAP keys and not a general exporter API. I'm not sure if they have a general exporter API.
> -Ben > > _______________________________________________ > 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
