Section 1 says:
This document defines how to use EAP-TLS with TLS 1.3 (or higher) and
This text is incorrect.
Q: Does this document define how to use EAP-TLS with TLS 1.4? What if
TLS 1.4 changes the TLS layer in such a way that EAP-TLS requires
modification, as done with TLS 1.2 to TLS 1.3?
Suggestion: remove all "or higher" text. Add in text which says that
by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS
version to 1.3, unless later versions are explicitly enabled by the
administrator.
There is no reason for implementations to allow the use of an
undefined version of EAP-TLS. It is not appropriate for this document
to suggest that it defines EAP-TLS 1.4+ when it does not.
As background, most EAP-TLS implementations have relied on the
underlying TLS library to negotiate TLS versions. Most EAP-TLS
implementations did not limit the maximum TLS version. As a result,
when the TLS libraries were updated to for TLS 1.3, many EAP-TLS
implementations would negotiate TLS 1.3, and then fail. Because any
behavior was accidental instead of specified, and therefore nothing
would interoperate.
This interoperability failure has been the source of a great many
problems in many deployments. The only solution was to upgrade the
EAP peer and/or the EAP server in order to forcibly limit the maximum
TLS version to 1.2. In some cases, the implementations did not even
export a configuration option which controlled the TLS versions, so
that had to be added, too.
Implementations should not make the same mistake with TLS 1.4 as was
done with TLS 1.3. Therefore, this document should explicitly call
out this issue, and suggest a path for implementations to follow.
Section 1 says:
While this document updates EAP-TLS [RFC5216], it
remains backwards compatible with it and existing implementations of
EAP-TLS.
Other than the abstract, this is the only reference to EAP-TLS 1.3
being backwards compatible with older versions of EAP-TLS. This
compatibility is simply asserted, with no further explanation given.
Q: What does "backwards compatible" mean? How is it achieved?
Suggestion: add text explaining how it is backwards compatible. How
will EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2? Perhaps
update Section 2.1 with text indicating that TLS version negotiation
is handled by the TLS layer, and thus outside of the scope of EAP-TLS.
Therefore so long as the underlying TLS implementation correctly
implements TLS version negotiation, EAP-TLS will automatically
leverage that capability.
Section 1 says:
... Privacy, which in EAP-TLS means that the peer username is not
disclosed
Nit: For resumption, the peer username (TLS PSK identity) is
disclosed, but it is meaningless. Also, EAP uses "Identity" and not
"username".
Suggestion: instead, say
... Privacy, which in EAP-TLS means that no information about
the underlying peer identity is disclosed.
Section 2.1.1 says:
TLS 1.3 introduced the Post-Handshake KeyUpdate
message which is not useful and not expected in EAP-TLS.
Q: What does it mean that the message is "not expected"? This seems
like a source of implementation-defined behavior, which experience
shows has been a source of interoperability and security issues.
Suggestion: If there is no use for KeyUpdate messages, then mandate
that it SHOULD be ignored, or perhaps connections which use KeyUpdate
MUST be closed without updating the keys. OpenSSL as APIs to
determine the status of key updates, so this suggestion is
implementable.
Section 2.1.1 says:
The EAP-TLS
server always commits to not send any more handshake messages by
sending a TLS close_notify alert.
The topic of close_notify versus application data has been discussed
elsewhere. However, the text here implies that EAP-TLS is overloading
TLS layer semantics in order to signal EAP-TLS layer behavior. This
process is a layering violation. See other comments for detailed
suggestions.
Section 2.1.2 says:
To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS
server MUST send one or more NewSessionTicket messages ...
Please see other comments about why RFC 8446 suggests that EAP-TLS
permit only one NewSessionTicket message. Also, that it makes no
sense to send any session tickets until after the client certificate
has been validated.
There is also the issue that a server can send a NewSessionTicket
message before TLS Finished, and before the client certificate has
been validated. This ticket is useless, and serves only to bloat the
packet exchange. The document should recommend that this practice be
forbidden, or not recommended.
Changing the number of session tickets can be done by the EAP-TLS
server via APIs. APIs which are public, and meant to be publicly used
as discussed here. See OpenSSL documentation which describes similar
use-cases.
Section 2.1.2 says:
The NewSessionTicket message MUST NOT include an
"early_data" extension.
Q: What happens if this requirement is violated? Is the connection
insecure? Should the early data be ignored?
Experience with implementations and deployments shows that many
implementors are happy to ignore MUST / MUST NOT requirements in
specifications. It is therefore useful to suggest what compliant
implementations can do when these requirements are violated.
Perhaps simply say "early data MUST ignored".
Section 2.1.3 says:
For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If
the client has received a NewSessionTicket message from the EAP-TLS
server, the client can use the PSK identity received in the ticket to
negotiate the use of the associated PSK.
This text implies that only one session ticket is received. This
implication either contradicts the text in Section 2.1.2 on multiple
session tickets, or gives no guidance on what to do if multiple
session tickets are received.
Suggestion: Use only one session ticket, and leave this text alone.
Alternately, if the suggestion to follow the guidance of RFC 8446 is
rejected, update this text to describe what clients should do when
presented with multiple session tickets.
Section 2.1.3 says this about the session ticket:
... If the EAP-TLS server
accepts it, then the security context of the new connection is tied
to the original connection and the key derived from the initial
handshake is used to bootstrap the cryptographic state instead of a
full handshake.
Nit: This the the only reference to "bootstrap the cryptographic
state" in this document. This text seems like an unnecessary
repetition of RFC 8446 Section 2.2.
Suggestion: Perhaps say instead
... If the EAP-TLS server
accepts it, then the resumed session has been deemed to be
authenticated, and securely associated with the prior authentication
or resumption.
Section 2.1.3 says:
It is up to the EAP-TLS peer whether to offer
resumption, ut it is RECOMMENDED
NIT: typo "but".
Section 2.1.3 says:
... However, the EAP-TLS server
MAY choose to require a full handshake. As in a full handshake,
sending a NewSessionTicket is optional.
Q: The text seems unclear, a full handshake is given as an example of
"as in" a full handshake? Perhaps the following is clearer:
... However, the EAP-TLS server MAY choose to require a full
handshake. In the case a full handshake is required, the
negotiation proceeds as if the session was a new authentication,
and resumption had never been requested. The requirements of
Sections 2.1.1 and 2.1.2 then apply in their entirety.
Section 2.1.3 says:
As described in Appendix C.4
of [RFC8446], reuse of a ticket allows passive observers to correlate
different connections. EAP-TLS peers and EAP-TLS servers SHOULD
follow the client tracking preventions in Appendix C.4 of [RFC8446].
That section also suggests that EAP-TLS should only request one
session ticket. If this document is updated to require only one
session ticket, then this text should remain as-is. If the document
permits multiple session tickets, then this text contradicts earlier
text in this document, and should therefore be updated.
Section 2.1.3 Figures 3 and 4:
The figures show the Commitment Message in the same EAP-TLS packet as
the handshake data (NewSessionTicket). This is the behavior
implementors see.
However, as noted on the EMU list, TLS has a wide variety of possible
behaviors, which means that these diagrams are misleading. They
document what "might" happen, not what "will" happen.
It is possible for the NewSessionTicket to be sent in a different
EAP-TLS packet than the Commitment Message. The document gives no
guidelines for what other packet flows are possible, which ones are
preferred / permitted / forbidden, or what implementations should do
with other packet flows.
Leaving such behavior as implementation-defined means that EAP-TLS is
under-specified. Such under-specifications lead to implementation
difficulties, security bugs, and interoperability issues.
Section 2.1.3 says:
It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the
same realm in the resumption and the original full handshake.
As discussed further in 2.1.3, not following this suggestion creates
difficulties. The later text gives a recommendation, but this
recommendation is likely not strong enough.
Specifically, there is no reason to use different identities for full
authentication and for resumption. The TLS PSK identity used for
resumption can (and should) be independent of the identity given in
the EAP Identity Response.
Perhaps the best thing is to make this suggestion a MUST:
When resumption is use, the value of the EAP Identity Response MUST
be the same as used in the original full authentication.
Section 2.1.3 continues with the same subject:
When NAI reuse can
be done without privacy implications, it is RECOMMENDED to use the
same anonymous NAI in the resumption, as was used in the original
full handshake [RFC7542]
Based on recent investigation into EAP / TLS / resumption, this
recommendation should be changed to a MUST:
When resumption is use, the value of the EAP Identity Response MUST
be the same as used in the original full authentication. This
reuse means that the issues of identy privacy are the same for full
authentication and resumption.
Section 2.1.3 says:
... For example, the NAI @realm can safely be
reused since it does not provide any specific information to
associate a user's resumption attempt with the original full
handshake. However, reusing the NAI
P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path attacker to
associate a resumption attempt with the original full handshake.
On-path attackers can access significantly more information than the
identity. This information includes things like MAC address of end
device, which even with MAC address randomization, typically only
changes once a day. It may be good to explain that attackers may have
access to other information, but also that it is beneficial to
minimize the amount of identification information that an attacker
has. Section 5 has more dicussion on this topic, which could perhaps
be used here.
Section 2.1.3 says:
... The
TLS PSK identity is typically derived by the TLS implementation and
may be an opaque blob without a routable realm. The TLS PSK identity
is therefore in general unsuitable for deriving a NAI to use in the
Identity Response.
This comment states what should not be done, but it gives no
recommendations for what should be done. It is also not clear why an
EAP peer would "derive" an NAI from the Identity Response. Would the
EAP peer not simply use the TLS PSK identity verbatim in the Identity
Response for the next authentication? Or, would the EAP peer simply
not re-use the same identity as for the original full authentication?
These questions are addressed by simply requiring re-use of the EAP
Identity Response from the original full authentication.
Section 2.1.4 says:
Figures 5, 6, and 7 illustrate message flows in several cases where
the EAP-TLS peer or EAP-TLS server sends a TLS fatal alert message.
In earlier versions of TLS, error alerts could be warnings or fatal.
NIT: it may be good to note that these TLS alerts meet the RFC 4137
requirement for altReject indicator.
Section 2.1.5 says:
In the case where EAP-TLS is used without peer authentication (e.g.,
emergency services, as described in [RFC7406]) the conversation will
appear as shown in Figure 8.
Question: Is there guidance as to when no peer authentication should /
should not be used? Is it possible for an EAP peer to present a
client certificate, but have the EAP server ignore it?
Perhaps suggest that in the normal case, deployments SHOULD use peer
authentication. Also that the "no peer authentication" case be
strictly limited in both time, and network access.
e.g. The "no peer authentication" situation MUST NOT be used to give
normal network access to EAP peers. Instead, deployments SHOULD
provide access which is limited in both time, and in capability.
Usually this means a "quarantine" network, or "walled garden", which
has only limited capability.
Also, the Security Considurations section has no discussion of the
security impact of not authenticating the peer. As Section 2.1.5 is
new, it has major impacts on security, and thus needs to be discussed.
Section 2.1.6 says:
As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a
HelloRetryRequest message in response to a ClientHello if the EAP-TLS
server finds an acceptable set of parameters but the initial
ClientHello does not contain all the needed information to continue
the handshake.
It's not clear why this section is necessary. The text here appears
to be discussing internals of TLS layer negotiation, which are
invisible to EAP-TLS. That is, this packet flow has no effect on the
EAP-TLS state machine, other than a different number of packets are
exchanged than with other packet flows.
Question: Is it that "EAP-TLS server" does not have sufficient
information to continue the handshake, or is it "the TLS layer" ?
Question: if the EAP-TLS implementation can do nothing other than ask
the TLS layer to continue the handshake, is this section even
necessary or relevant?
It may be worth simply noting that there are a variety of possibly
flows in TLS, including negotiation. And that the only visible
results to the EAP-TLS layer are:
- session resumed or not
- session successfully authenticated or not
Section 2.1.9 says:
Some EAP implementations and access networks may limit the number of
EAP packet exchanges that can be handled.
This is under-stating the issue rather severely. We know with
absolute certainty that most (if not all) EAP implementations and
access networks limit the number of EAP packet exchanges. Perhaps
update the text to reference implementation and interoperability
experience.
Section 2.3 says:
A zero-length context (indicated by "") is used in the TLS exporter
interface. The EAP-TLS Type-Code of '0D' (in hexadecimal) is
appended to the label strings. Other TLS based EAP methods can use
exporters in a similar fashion by replacing the EAP-TLS Type-Code
with their own Type-Code (encoded as a hexadecimal string).
It is not appropriate for this document to update other TLS-based EAP
types. The WG already has accepted a document which does exactly
that. There was resistance to the idea of discussing TLS internals in
this document, in which case doesn't seem right to have this document
do exactly what it's not supposed to do: talk about something outside
of it's scope.
Suggestion: delete the inappropriate text.
Section 2.3 says:
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
without having to extract the Master Secret, ClientHello.random, and
ServerHello.random in a non-standard way.
NIT: the exporters were first defined in TLS 1.2, and have been widely
available in TLS library implementations. Using master secret,
etc. has not been necessary for a while. Further, the "non-standard"
use of Master Secret, etc. was first done in the original EAP-TLS RFC
[2716], in 1999. The TLS WG later defined and standardized the
exporters in order to meet the needs of EAP-TLS.
Perhaps instead say:
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
which provides a public API for the exporter. There has been no need
to access internal fields in TLS since the public exporters were
defined in [RFC5705].
Section 4 says:
This memo requires IANA to add the following labels to the TLS
Exporter Label Registry defined by [RFC5705]. These labels are used
in derivation of Key_Material, IV and Method-Id as defined in
Section 2.3:
The labels given here are prefixes, while RFC 5705 mandates
registration of full labels. This conflict will have to be addressed
before this document is published. Perhaps by updating the
registration requirements of the TLS Exporter Label Registry.
Or, we should simply use the exporters from the -13 draft, which have
no such problems.
Question: Can that update be done without prior consultation without
the TLS WG? Perhaps we should check with the TLS WG to see if these
updates are permitted.
Section 5 says:
5. Security Considerations
5.1. Security Claims
NIT: it is generally not good editorial process to have section titles follow
each other without text in between.
Section 5.1 says:
[1] Mutual authentication: By mandating revocation checking of
certificates, the authentication in EAP-TLS with TLS 1.3 is stronger
as authentication with revoked certificates will always fail.
How is this claim affected by the "no peer authentication" situation
noted earlier in the document?
Section 5.1 says:
[4] Cryptographic Negotiation: TLS 1.3 increases the number of
cryptographic parameters that are negotiated in the handshake. When
EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
groups, and signature algorithm, see Section 4.1.1 of [RFC8446].
Question: what does this mean in practice for EAP-TLS? i.e. this text
describes a capability. It does not describe what that capability
does, or how it benefits EAP-TLS.
Section 5.4 says:
An implementation MAY enforce limited authorization before revocation
checking has been done.
Question: an implementation of what? The EAP peer? EAP server?
RADIUS server? What does "limited authorization" look like in practice?
Section 5.7 says:
There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies to all version of TLS.
NIT: These requirements are for EAP-TLS, and not TLS. Perhaps instead:
There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies EAP-TLS when is used
with any version of TLS.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
