On Jan 9, 2018, at 8:46 AM, John Mattsson <john.matts...@ericsson.com> wrote: > > We have submitted an updated version of draft-mattsson-eap-tls13. The new > version is a significant update based on the feedback and comments on the EAP > and EMU mailing lists. The new version also fills in all the sections that > was TDB in the -00 version.
That looks a lot cleaner, thanks. > - The draft now updates version updates RFC5216 (instead of obsoleting) and > all text have been updated to make sure that the update stays compatible with > all existing implementations of EAP-TLS > - Added more text on what TLS 1.3 changes and why an update to RFC5216 is > needed. Nit: This means that significant parts of the normative text in the previous EAP-TLS specification [RFC5216] no longer apply, and aspects such as privacy handling, resumption, and key derivation need to be handled differently. Instead of "no longer apply", I would say "are not applicable to EAP-TLS using TLS 1.3". A simple "no longer applies" text could be interpreted as meaning it no longer applies to *any* variant of EAP-TLS. > - As this is now an update, all duplicated text is removed, and the draft > only describe the changes to message flow, messages, key derivation, privacy, > etc. when TLS 1.3 is used. The new draft follows the structure of RFC5216 and > lists updates (if any) to each section. Nit: The EAP server MUST authenticate with a certificate and SHOULD require the EAP peer to authenticate with a certificate. If the client certificate isn't provided, how is the client to be authenticated? It may be better to say that the peer MUST authenticate itself initially with a certificate, and then MUST use a provisioned PSK for session resumption. Only those two authentication methods are allowed. > - Clearly stated that PSK authentication SHALL not be used (except for > resumption). Why would PSK be forbidden? The TLS 1.3 spec clearly allows PSKs to be established out of band: https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.2.2 While RFC 5216 doesn't explicitly allow PSKs to be used, it doesn't forbid them or define how they're used. The only other reference to EAP-TLS with PSK seems to be draft-otto-emu-eap-tls-psk-02.txt, from 2007. I guess my question here is how to allow PSK for session resumption, while forbidding the use of static keys everywhere else. Nit: ... If the client has received a NewSessionTicket message from the server, the client can use the PSK identity "can" use the PSK identity? What if it chooses to not use the PSK identity? I suspect it would be better to say that the EAP server MUST provide an identity and PSK for session resumption. When doing session resumption, the EAP peer MUST use that identity and PSK. There's no benefit to the peer using a *different* identity. The current phrasing "can use..." sounds philosophical instead of prescriptive. It would be better to mandate the correct behaviour. Nit: A subsequent authentication using resumption, where both sides authenticate successfully is shown in Figure 3. It would be good to show a subsequent authentication using session resumption, where the server rejects the resumption, and requests that the EAP peer re-authenticate from scratch. It would also be good to note that if the session resumption is rejected, the EAP peer MUST discard the ticket, along with any associated identity and PSK. > - Due to the encrypted handshake in TLS 1.3 there is no longer any need for > the EAP client to send and empty certificate list. A privacy section has been > added that explains this. > > - A key hierarchy section has been added specifying that when TLS 1.3 is used > then Key_Material, IV, and Session-Id SHALL be derived from the > exporter_master_secret using the TLS exporter interface. That's good. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
