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

[Joseph Salowey <[e-mail]>]

I went through the review and created issues for the ones that were not
covered by existing issues or PRs.  Some issues, such as Issue 58 on nits
contain several of the comments below.

Issues may be discussed on the list or in github issues, however
resolutions for any normative or substantial text not discussed on the list
are to be posted to the list before resolution.  Therefore it would be
better to have substantial changes discussed on the mailing list.

Thanks,

Joe

On Thu, Mar 4, 2021 at 9:47 AM Alan DeKok <[e-mail]> wrote:

> 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.
>
> [Joe] I agree with being cautious about the next version.     I created an
issue to track this - Issue #57
<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/57>.


>
> 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.
>
>
[Joe]  It seems it would be sufficient to just add "backwards compatible
through TLS version negotiation.


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

[Joe] OK


>
> 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.
>
>
[Joe] I think the best thing to do here is to say the key update MUST NOT
be sent and SHOULD be ignored if it is received.




>
> 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.
>
>
[Joe] Perhapsthis will get resolved with the new text that moves to
application data.  I think this text is related to that.


>
> 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.
>
> [Joe] See PR #51
<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/51>.  I'll open an
issue for the timing with respect to cert validation. Issue 60
<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/60>


>
> 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".
>
> [Joe] Added to issue 60


>
> 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.
>
>
[Joe]  Handling of new session tickets is described in TLS 1.3.  I don't
think we need to say more here.  Less text would be better.


>
> 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.
>
>
[Joe] See PR 44 - https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/44


>
> 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.
>
>
[Joe] Opened issue for NAI handling


>
> 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.
>
>
[Joe] See PR 40 - https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/40


>
> 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.
>
>
[Joe] Issue 52


>
> 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
>
>
[Joe]  It seems it would be good to discuss that the number of flights may
vary for several reasons including this one.


>
> 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.
>
> [Joe] what is the reference?


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

[Joe] This test is defunct


>
> 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.
>
> [Joe] This text is defunct.


>
> 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?
>
> [Joe] There is an issue for this.


>
> 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.
>
>
[Joe] There may be some superfluous text in this, however it does describe
that TLS provides algorithm negotiation.


>
> 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?
>
>
[Joe] I think this means limited access to the network, but it is
not clear.


>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>