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

From: Alan DeKok <[email-masked]>
Date: Thu, 4 Mar 2021 12:47:05 -0500

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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 4 Mar 2021 12:48:43 -0500

Summary:

The document says it defines EAP-TLS with TLS 1.3 (or higher).  This
is not true, and all references to "or higher" should be removed.

It allows for multiple session tickets, going against the
recommendations of RFC 8446, and against the consensus from
implementors.

It implicitly permits session tickets to be sent before the client
certificate has been validated.  These tickets are useless, and serve
only to bloat the packet exchange.

It adds "no peer authentication", but is silent on the security
considerations of that change.

It claimes to be "backwards compatible" with earlier versions of
EAP-TLS, but does not explain how that is achieved.

It discusses HelloRetryRequest, with no explanation as to how that
affects EAP-TLS.  From a reading of the document and RFC 8446, it
appears that it doesn't.

It should be updated to suggest that resumption uses the same EAP
Identity as from the first full authentication.  This suggestion
solves a number of potential privacy and interoperability issues.

It defines key exporters for other TLS-based EAP methods.  The WG
already has a document which covers this topic, accepted as a WG
document prior to these changes being added to this document.

The IANA considerations section does not match the rest of the
document.  It defines key label prefixes, not key labels.  Either the
spec needs to be updated, or the IANA registry requirements needs to
be updated.  Preferably after consultation with the TLS WG.

It leaves significant portions of the protocol as
implementation-defined.  Experience shows that implementation-defined
behavior is the source of implementation problems, security issues,
and interoperability issues.

There has been significant push-back against adding implementation
guidance to this specification.  This push-back has had real-world
costs.  If the document is not corrected, there will be years of
issues with interoperability, security, deployment, etc.  These costs
will be borne by the implementors, which is why they believe that
updating the document is critical to the success of EAP-TLS 1.3.

The hackathon showed that a number of the implementation decisions are
not reflected in this document.  Instead, the information has been
shared in "out of band" discussions between the various implementors.
This out of band process is appropriate for discussions before a
standard has been finalized.  However, it is not appropriate to expect
that new implementors obtain guidance through secret "back room"
processes.  Instead, this document should contain sufficient
information to allow everyone to implement EAP-TLS in an interoperable
manner.

The purpose of an engineering specification is to build something.  If
the specification is not sufficiently detailed to build things, then
the specification is wrong.  There should be zero resistance to making
sure that the specification is clear, correct, and useful.

As a result, the document has a large number of major issues which
affect security, implementation, standards compliance, and IANA.

The document is not ready for publication until these issues have been
resolved.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 9 Mar 2021 07:58:36 -0500

Just a note on NAI realm.  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.  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 text is good, but could perhaps be clearer.  It's not obvious where the NAI "P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm" comes from.  The subsequent text referring to TLS PSK identity is, in fact, unrelated.  But having the two subjects next to each other could be misleading.

  i.e. discuss "P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm"  in the context of an NAI which is secure, and hides identities, but is unique and allows tracking.

  Separately, discuss TLS PSK Identity.

  Perhaps it would be good to note that the TLS PSK identity is only used by the TLS layer, and therefore is entirely unrelated to the EAP Response Identity.  As such, from the standpoint of layer separation, the TLS PSK identity MUST NOT be used to derive an EAP Response Identity.

  It may also be worth noting that like RFC 7542, this document uses "@realm" as a short-hand for the realm.  But also that single-label realm names are forbidden by RFC 7542 Section 2.2.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 29 Mar 2021 22:01:29 -0700

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

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

> leverage that capability.
[Joe]  It seems it would be sufficient to just add "backwards compatible
through TLS version negotiation.

>    the underlying peer identity is disclosed.

[Joe] OK

> determine the status of key updates, so this suggestion is
[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.

> process is a layering violation.  See other comments for detailed
[Joe] Perhapsthis will get resolved with the new text that moves to
application data.  I think this text is related to that.

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

> [Joe] Added to issue 60

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

> difficulties, security bugs, and interoperability issues.
[Joe] See PR 44 - https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/44

> Identity Response from the original full authentication.
[Joe] Opened issue for NAI handling

> requirement for altReject indicator.
[Joe] See PR 40 - https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/40

> new, it has major impacts on security, and thus needs to be discussed.
[Joe] Issue 52

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

> [Joe] what is the reference?

> \

[Joe] This test is defunct

> [Joe] This text is defunct.

> [Joe] There is an issue for this.

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

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

> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 30 Mar 2021 08:44:16 -0400

On Mar 30, 2021, at 1:01 AM, Joseph Salowey <[email-masked]> wrote:
> 
> 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.  

  Thanks.

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

  OK.

> [Joe]  It seems it would be sufficient to just add "backwards compatible through TLS version negotiation. 

  Yes.  It would be good also to note that the changes in this document are only to be applied when TLS 1.3 is used.  This limitation means that the old TLS 1.2 state machines are not modified by this specification.

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

  Yes.

> [Joe] what is the reference?

https://github.com/FreeRADIUS/freeradius-server/blob/release_3_0_21/src/modules/rlm_eap/mem.c#L449

https://w1.fi/cgit/hostap/tree/src/eap_peer/eap.c?h=hostap_2_9#n35

  Those are stable references to a particular release / tag.  So the code shouldn't change.  Both sets of code implement a limit on the maximum number of round trips they will support.  The limits noted here are both hard-coded to "50".  Later versions of hostap take that limit from a configuration parameter.  FreeRADIUS still hard-codes it to 50.  TBH, I don't really see a compelling reason to change that.

  Jouni Malinen also has a useful comment here:  http://lists.freeradius.org/pipermail/freeradius-users/2009-February/035654.html

... The main (well, more or less, the only) reason for that limit on
number of round trips is to work around issues where the EAP peer and
server ended up in an infinite loop ACKing their messages. ...

  Alan DeKok.