Hi all, I took a quick look at the -09 draft.
Here are a few comments. 1. Introduction The text in the introduction is confusing. To be honest, this document is actually not needed because TLS allows you to negotiate version and features.. Obviously, the introduction does not say that and instead dances around the reason of why this document is needed by saying TLS 1.3 made a lot of changes but then concludes everything is backwards compatible. In more details, the first paragraph is fine. It talks about where EAP-TLS is used. Then, the second paragraph says: " TLS 1.3 is in large parts a complete remodeling of the TLS handshake protocol including a different message flow, different handshake messages, different key schedule, different cipher suites, different resumption, different privacy protection, and record padding. This means that significant parts of the normative text in the previous EAP-TLS specification [RFC5216<https://tools.ietf.org/html/rfc5216>] are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, aspects such as resumption, privacy handling, and key derivation need to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). " The change from 1.2 to 1.3 is certainly larger than the change from 1.1. to 1.2. For the user of the EAP method not much has changed though. In fact, you can seamless switch from one version of TLS to the next version. In fact, you say that in the next paragraph: " While this document updates EAP-TLS [RFC5216<https://tools.ietf.org/html/rfc5216>], it remains backwards compatible with it and existing implementations of EAP-TLS. " In the last paragraph you say: " Privacy is mandatory and achieved without any additional round-trips, revocation checking is mandatory and easy with OCSP stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. " You have some specific features in mind when you talk about "privacy" and I wonder what those are. In what sense is revocation checking mandatory? OCSP stapling has been a feature before. What is this issue about fragmentation? As you know from your work on the other document, fragmentation is really introduced by certificates. The certificate format in TLS 1.3 has not changed. Before you answer these questions look at my suggestion below. I would delete large part of the introduction and basically leave the first paragraph intact and then add the following sentences: " EAP-TLS [RFC5216<https://tools.ietf.org/html/rfc5216>] references TLS 1.0 [RFC2246<https://tools.ietf.org/html/rfc2246>] and TLS 1.1 [RFC4346<https://tools.ietf.org/html/rfc4346>], but works perfectly also with TLS 1.2 [RFC5246<https://tools.ietf.org/html/rfc5246>]. TLS 1.0 and 1.1 are formally deprecated and prohibited to negotiate and use [I-D.ietf-tls-oldversions-deprecate<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-09#ref-I-D.ietf-tls-oldversions-deprecate>]. Weaknesses found in TLS 1.2, as well as new requirements for security, privacy, and reduced latency has led to the specification of TLS 1.3 [RFC8446<https://tools.ietf..org/html/rfc8446>], which obsoletes TLS 1.2 [RFC5246<https://tools.ietf.org/html/rfc5246>]. This specification updates RFC 5216 and updates the description to cover TLS 1.3. Security and privacy considerations of this EAP method are updated to reflected the improved security and privacy functionality of TLS 1.3. " Section 2.1 Delete this paragraph. It does not say much. TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of Section 2.1<https://tools.ietf.org/html/rfc5216#section-2.1> of [RFC5216]<https://tools.ietf.org/html/rfc5216#section-2.1> does not apply for TLS 1.3 (or higher). Section 2.1.1 Many client certificates contains an identity such as an email address, which is already in NAI format. A NAI looks like an email address but actually isn't. " The EAP server MUST authenticate with a certificate and SHOULD require the EAP peer to authenticate with a certificate. " You might want to mention the emergency services use case here. You do much later in the document but I believe this is the first occurrence of the server-side only authentication concept. " Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption. " What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder why you want to rule that use case out? It is a perfectly fine use case for TLS 1.3 and there is even the possibility to use PSK with ECDHE. What is the motivation? " SessionID is deprecated in TLS 1.3 and the EAP server SHALL ignore the legacy_session_id field if TLS 1.3 is negotiated. " I am curious why you are pointing out this change in TLS 1.3. Yes, the session id field has been deprecated and the session resumption concept was harmonized but for the EAP layer this appears to be irrelevant. " After the TLS handshake has completed and all Post-Handshake messages have been sent, the EAP server sends EAP-Success. " I think you have to be more precise here with your recommendations regarding post-handshake messages. The following paragraph from the same section (but later in the text) appears relevant to this topic. " When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support of resumption in the initial authentication. To indicate support of resumption, the EAP server sends a NewSessionTicket message (containing a PSK and other parameters) after it has received the Finished message. " Unfortunately, it is not entirely correct. It is not the EAP server role that makes this session resumption support indication but it is a feature of TLS. So, you might want to change the sentence to: " When using session resumption in TLS 1.3, a NewSessionTicket message is sent as a post-handshake message. " " As stated in [RFC5216<https://tools.ietf.org/html/rfc5216>], the TLS cipher suite shall not be used to protect application data. This applies also for early application data. When EAP-TLS is used with TLS 1.3, early application data SHALL NOT be used. " You might want to say that TLS 1.3 in EAP is only used for authentication and the establishment of keys rather than for application data protection. Then, this paragraph becomes more understandable for someone not familiar with the network access authentication concept in general. In Figure 1 you show the "Commitment Message" and I was wondering why you need it. You talk about it later in Section 2.5 but I still don't get it. This appears to be an unnecessary deviation from the TLS 1.3 implementation. Btw, I would give Figure 1 the following title "EAP-TLS 1.3: Full Public Key-based Exchange with mutual authentication". In Figure 2 you show the NewSessionTicket message and this is one possible exchange. I believe you can also add the NewSessionTicket message right after the Finished message and thereby saving an extra roundtrip, if you want. 2.1.2<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10#section-2.1.2>. Ticket Establishment " This is a new section when compared to [RFC5216<https://tools.ietf.org/html/rfc5216>]. " While it is new to RFC 5216 it is not new at all in context of https://tools.ietf.org/html/rfc5077 I don't understand why you introduce a section 2.1.2 for ticket establishment and a separate section 2.1.3 on resumption when the two actually belong together. I suggest to combine the two sections and to call them Resumption.. TLS 1.3 combined three mechanisms into one: PSK-based authentication, classic session resumption and session resumption without server-side state. " TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange. When EAP-TLS is used with TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism compatible with that version of TLS. " I would delete this paragraph because it states the obvious. You state that EAP peers and EAP servers should use the client tracking preventions and then you make recommendations regarding the NAI construction in the following paragraph. How do you see the two to interwork? " As specified in Section 2.2 of [RFC8446]<https://tools.ietf.org/html/rfc8446#section-2.2>, the EAP peer SHOULD supply a "key_share" extension when attempting resumption, which allows the EAP server to potentially decline resumption and fall back to a full handshake. " This is not a good advice IMHO. In the deployments where EAP-TLS is used the EAP peer and the EAP server know quite well what the other parties do and being as conservative as in the web environment does not appear to be appropriate. Considering that the key share(s) cost a fair amount of computation and over-the-wire bandwidth, I would actually recommend the opposite. It is more likely that the EAP exchange succeeds. If you are uncertain, make no recommendations and explain the tradeoffs instead. " Also during resumption, the server can respond with a Hello Retry Request (see Section 2.1.6<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10#section-2.1.6>) or issue a new ticket (see Section 2.1.2<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10#section-2.1.2>) " Not sure why you are stating this. This issue is explained in great detail in the TLS 1.3 specification. I would not repeat the TLS 1.3 here. 2.1.4<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10#section-2.1.4>. Termination " TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, some normative text in Section 2.1.3 of [RFC5216]<https://tools.ietf.org/html/rfc5216#section-2.1.3> does not apply for TLS 1.3 or higher. " I would not repeatedly make this statement. 2.1.8<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-09#section-2.1.8>. Privacy TLS 1.3 significantly improves privacy when compared to earlier versions of TLS by forbidding cipher suites without confidentiality and encrypting large parts of the TLS handshake including the certificate messages. This is not the entire privacy story in TLS 1.3. IMHO TLS 1.2 already had no ciphersuites that allowed integrity only. TLS 1.3 got rid of RSA key transport. TLS also added improved padding and better unlinkability support for session resumption. I stop here for now. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
