Re: [Emu] Review of draft-ietf-emu-eap-tls13-04

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: John Mattsson <[e-mail]>
> Sent: Thursday, March 21, 2019 8:56 AM
> To: Jim Schaad <[e-mail]>; [e-mail]
> Cc: 'EMU WG' <[e-mail]>
> Subject: Re: Review of draft-ietf-emu-eap-tls13-04
> 
> Thanks for the thorough review Jim!
> 
> -----Original Message-----
> From: Jim Schaad <[e-mail]>
> Date: Wednesday, 20 March 2019 at 11:03
> To: "[e-mail]" <[e-mail]>
> Cc: 'EMU WG' <[e-mail]>
> Subject: Review of draft-ietf-emu-eap-tls13-04
> Resent-From: <[e-mail]>
> Resent-To: John Mattsson <[e-mail]>,
> <[e-mail]>
> 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 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."
> 

Right but the first sentence in the paragraph is

As the certificate messages in TLS 1.3 are encrypted, there is no  need to send an empty certificate_list ...

So both statements are not true.

> follows Section 4.4.2.4 of RFC 8446:
> 
> "If the client does not send any certificates (i.e., it sends an empty Certificate
> message), the server MAY at its discretion either continue the handshake
> without client authentication or abort the handshake with a
> "certificate_required" alert."
> 
> I do not understand what you mean with " Current text implies it is always
> true." The term terminal condition came from RFC 5216. Should I rewrite it
> with text from RFC 8446?
> 
> "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 at its discretion either continue the handshake without
> client authentication or abort the handshake with a "certificate_required"
> alert."
> 
>     Section 5.7 para 3 - The term "other authentication information" is
>     confusing to me.  You should only be capturing the information from the
> TLS
>     handshake and nothing else.
> 
> I think the group need to discuss this more. I think Alan's suggestion was that
> you capture quite a lot.

Agreed on the discussions

Jim

> 
>     As an example, I would not expect that the
>     client would do any additional revocation checking when offering to use a
>     session ticket.  If the revocation information is not sufficiently current,
>     then the client should not do resumption.  But this does not require
>     reevaluation of revocation information or the server certificate chain.  A
>     client quite likely to be unable to access a network to check for revocation
>     until after the EAP process has finished and thus would be unable in EAP to
>     do these checks.
> 
> That are very good points. I will update the text based on these suggstions.
> 
>     Section 5.7 para 7 - Current sentence appears to say that the IP address is
>     part of the EAP-Response/Identity.
> 
> Ok, let's reformulate
> 
> I generally find this entire section
>     confusing and think that a large amount should probably be in the main
> text
>     and not here.
> 
> Yes, moving some of the information to 2.1.2 seems to make sense
> 
>     Jim
> 
> 
> 
> 
> 
> 
> 
> 
> 
>