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

[Jim Schaad <[e-mail]>]

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:

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.

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?


Section 2.1.3 - I am having a problem understanding why you have Figure 8 in
the system.  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.  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.

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.

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.  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.

Section 5.7 para 7 - Current sentence appears to say that the IP address is
part of the EAP-Response/Identity.  I generally find this entire section
confusing and think that a large amount should probably be in the main text
and not here.

Jim