Re: [Emu] Review of draft-ietf-emu-eap-tls13-04
Hi > On 20 Mar 2019, at 11:03, Jim Schaad wrote: > > TLS 1.3 introduced early application data; if a server receives a client > hello with early application data it MUST abort the handshake with an > EAP-Failure. The server MAY generate a TLS-Alert as well. This precise text actually may have implications for onboarding, where the notion is to validate the data retrospectively. In particular this impacts the previous statement: The EAP server MUST authenticate with a certificate and SHOULD require the EAP peer to authenticate with a certificate. draft-ietf-anima-bootstrapping-key-infra defers the authentication during onboaridng stages, which I would expect draft-lear-eap-teap-brski to do as well. However, the purpose of the deferral is extremely limited, and the information exchanged must be authenticated in order for any state generated to be retained. Some eyes on this particular aspect would be useful next week. Eliot___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of draft-ietf-emu-eap-tls13-04
> -Original Message- > From: John Mattsson > Sent: Thursday, March 21, 2019 8:56 AM > To: Jim Schaad ; draft-ietf-emu-eap-tl...@ietf.org > Cc: 'EMU WG' > Subject: Re: Review of draft-ietf-emu-eap-tls13-04 > > Thanks for the thorough review Jim! > > -Original Message- > From: Jim Schaad > Date: Wednesday, 20 March 2019 at 11:03 > To: "draft-ietf-emu-eap-tl...@ietf.org" > Cc: 'EMU WG' > Subject: Review of draft-ietf-emu-eap-tls13-04 > Resent-From: > Resent-To: John Mattsson , > > Resent-Date: Wednesday, 20 March 2019 at 11:03 > > General Comment: I have a strong tendency to like positive rather than > negative statements in documents, thus the use of MUST rather than > MUST NOT. > Additionally, I have a general tendency to like to know what should happen > if a statement is violated. Thus consider the following from section > 2.1.1: > > Agree, if possible it is often better with "MUST" statements describing what > is happening. The disadvantage with MUST statements are that they rule out > things that may be specified in updates to RFC 8446. > > TLS 1.3 introduces early application data; early application data SHALL > NOT > be used with EAP-TLS. > > I would prefer to see this as > > TLS 1.3 introduced early application data; if a server receives a client > hello with early application data it MUST abort the handshake with an > EAP-Failure. The server MAY generate a TLS-Alert as well. > > In the case of early data, Section 4.2.10 of RFC 8446 states that "A server > which receives an "early_data" extension MUST behave in one of three > ways:". The three ways are: ignoring early_data, send HelloRetryRequest, > and accepting early_data. > > Aborting the handshake would not follow RFC 8446, so I don't think we want > that. I would suggest to follow RFC 8446 and specify that the server ignore > the early_data extension or replies with HelloRetryRequest. I suggest > writing: > > TLS 1.3 introduced early application data which is not used in EAP-TLS. A > server which receives an "early_data" extension MUST ignore the extension > or respond with a HelloRetryRequest as described in Section 4.2.10 of RFC > 8446. That is better, an additional note that new session tickets MUST NOT include the early data extension would also be relevant. > > This made me realize that draft-ietf-emu-eap-tls13-04 does not mention > HelloRetryRequest at all. I think draft-ietf-emu-eap-tls13-04 should mention > HelloRetryRequest add add a figure describing the message flow. > Alternatively state that HelloRetryRequest MUST NOT be used (or positively > that the server MUST respond with ServerHello). > > Section 2.1.2 - The following sentence: > If the EAP peer did not supply a "key_share" extension >when offering resumption, the EAP server needs to reject the >ClientHello and the EAP peer needs to restart a full handshake. > > Appears to state that the key share MUST be provided even though the > previous sentence said that it was only a SHOULD. Which is it? > > Good catch. Definitely something missing in that sentence. Should be > SHOULD following RFC 8446. Suggested update: > > "If the EAP peer did not supply a "key_share" extension when offering > resumption, an EAP server declining resumption needs to reject the > ClientHello and force the EAP peer to restart a full handshake. The message > flow in this case is given by Figure 4 followed by Figure 1 or Figure 2." Yes better > > Section 2.1.3 - I am having a problem understanding why you have Figure 8 > in > the system. > > There was an earlier comment from someone requesting more figures > describing messages flows for various use cases and errors. > > First, a new session ticket would only be returned if the > client asked for one to be returned. Thus the client will never receive > one > that is unexpected. > > That is not my understanding of how NewSessionTicket works according to > RFC 8446. The session_ticket extension is a far as I understand deprecated in > TLS 1.3. The only text I can find in RFC 8446 is that Oh fudge. Losing the indicator that a client wants this seems to be a stupid decision on the part of TLS.I guess that I just assumed it was still there because it was in the past. > > "At any time after the server has received the client Finished message, it > MAY send a NewSessionTicket message." > > Secondly, the authentication has finished and you are > in a situation where if you had not asked for the ticket everything would > be > fine. The only possible reason for doing this would be if the client > suddenly decided that it no longer wanted the ticket and was going to tell > the server that it did not need to cache the information associated with > it. > However, since this is not a normal flow in TLS that would never happen. > If > the client decides that it does not want
Re: [Emu] Review of draft-ietf-emu-eap-tls13-04
Thanks for the thorough review Jim! -Original Message- From: Jim Schaad Date: Wednesday, 20 March 2019 at 11:03 To: "draft-ietf-emu-eap-tl...@ietf.org" Cc: 'EMU WG' Subject: Review of draft-ietf-emu-eap-tls13-04 Resent-From: Resent-To: John Mattsson , Resent-Date: Wednesday, 20 March 2019 at 11:03 General Comment: I have a strong tendency to like positive rather than negative statements in documents, thus the use of MUST rather than MUST NOT. Additionally, I have a general tendency to like to know what should happen if a statement is violated. Thus consider the following from section 2.1.1: Agree, if possible it is often better with "MUST" statements describing what is happening. The disadvantage with MUST statements are that they rule out things that may be specified in updates to RFC 8446. TLS 1.3 introduces early application data; early application data SHALL NOT be used with EAP-TLS. I would prefer to see this as TLS 1.3 introduced early application data; if a server receives a client hello with early application data it MUST abort the handshake with an EAP-Failure. The server MAY generate a TLS-Alert as well. In the case of early data, Section 4.2.10 of RFC 8446 states that "A server which receives an "early_data" extension MUST behave in one of three ways:". The three ways are: ignoring early_data, send HelloRetryRequest, and accepting early_data. Aborting the handshake would not follow RFC 8446, so I don't think we want that. I would suggest to follow RFC 8446 and specify that the server ignore the early_data extension or replies with HelloRetryRequest. I suggest writing: TLS 1.3 introduced early application data which is not used in EAP-TLS. A server which receives an "early_data" extension MUST ignore the extension or respond with a HelloRetryRequest as described in Section 4.2.10 of RFC 8446. This made me realize that draft-ietf-emu-eap-tls13-04 does not mention HelloRetryRequest at all. I think draft-ietf-emu-eap-tls13-04 should mention HelloRetryRequest add add a figure describing the message flow. Alternatively state that HelloRetryRequest MUST NOT be used (or positively that the server MUST respond with ServerHello). Section 2.1.2 - The following sentence: If the EAP peer did not supply a "key_share" extension when offering resumption, the EAP server needs to reject the ClientHello and the EAP peer needs to restart a full handshake. Appears to state that the key share MUST be provided even though the previous sentence said that it was only a SHOULD. Which is it? Good catch. Definitely something missing in that sentence. Should be SHOULD following RFC 8446. Suggested update: "If the EAP peer did not supply a "key_share" extension when offering resumption, an EAP server declining resumption needs to reject the ClientHello and force the EAP peer to restart a full handshake. The message flow in this case is given by Figure 4 followed by Figure 1 or Figure 2." Section 2.1.3 - I am having a problem understanding why you have Figure 8 in the system. There was an earlier comment from someone requesting more figures describing messages flows for various use cases and errors. First, a new session ticket would only be returned if the client asked for one to be returned. Thus the client will never receive one that is unexpected. That is not my understanding of how NewSessionTicket works according to RFC 8446. The session_ticket extension is a far as I understand deprecated in TLS 1.3. The only text I can find in RFC 8446 is that "At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message." Secondly, the authentication has finished and you are in a situation where if you had not asked for the ticket everything would be fine. The only possible reason for doing this would be if the client suddenly decided that it no longer wanted the ticket and was going to tell the server that it did not need to cache the information associated with it. However, since this is not a normal flow in TLS that would never happen. If the client decides that it does not want to save the ticket that it received, say because it is too big, then it can just not save it but still have EAP run to success. Agree that the client should just most likely just ignore the ticket. Let's remove the figure and the text. Section 2.1.4 - an EAP-TLS server MUST treat an empty certificate_list as a terminal condition when client authentication is required. Current text implies it is always true. The text in draft-ietf-emu-eap-tls13-04 "For TLS 1.3 this means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition." follows
