Thanks for the thorough review Jim!
-----Original Message-----
From: Jim Schaad <[email protected]>
Date: Wednesday, 20 March 2019 at 11:03
To: "[email protected]" <[email protected]>
Cc: 'EMU WG' <[email protected]>
Subject: Review of draft-ietf-emu-eap-tls13-04
Resent-From: <[email protected]>
Resent-To: John Mattsson <[email protected]>, <[email protected]>
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 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.
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
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
