Re: [Emu] Resolving EAP-TLS issues

[Mohit Sethi M <[e-mail]>]

Updates on the actions thus far:

On 3/29/21 12:20 AM, Joseph Salowey wrote:
The authors have been working on the draft-ietf-emu-eap-tls13 in the GitHub Repo (https://github.com/emu-wg/draft-ietf-emu-eap-tls13).  Below is a brief summary of the Issues and PRs that have recently been merged or ready to be merged.  If you are aware of issues that are not currently tracked in the repo please add them or let the chairs know.  We are looking to publish a new draft in the next few weeks so indicate on the list if there are problems with these resolutions.

Thanks,

Joe

PR #44<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/44> - Merged - Editorial - Clarifies that Message Flows are Examples
PR #50<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/50> - Merged - Editorial - Moving from Master to Main terminology as in RFC8446bis
PR #51<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/51> - Merged - Editorial - added text to suggest that one session ticket be sent - Issue 48<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/48>
PR #53<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/53> - Merged - Normative - Uses type code in the context of the key derivation - Issue 32<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/32> - Issue 56<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/56>
PR #40<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/40> - Ready to Merge - Editorial - alignment with EAP State Machine Terminology - Issue 33<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/33> Issue 36<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/36>
Merged.
PR #41<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/41> - Ready to Merge - Editorial - Discussion of packet modification attacks - Issue 36<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/36>
Merged.
PR #42<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/42> - Ready to Merge - Editorial - Reference EAP-Types draft
Merged.
PR #45<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/45/files> - Ready to Merge - Editorial - Describes why session resumption is needed - Issue 34<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/34>
Merged.
PR #46<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/46> - Ready to Merge - Normative - Makes it mandatory to send Error Alerts to single EAP Failure - Issue 37<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/37> - Issue 38<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/38>
Merged.
PR #54<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/54> - Ready to Merge - Normative - uses protected success indicators as single 0x00 byte of application data - Issue 55<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/55>
Merged.

Open Issues without proposed Resolution

Issue #52<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/52> - Needs Discussion and Proposal - Update security considerations with discussion of implications no peer authentication

Commit (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/c1e648ab9e9f6b44f833689205528f8b53cc7db0) with the following text pushed:

   EAP servers will usually require the EAP peer to provide a valid
   certificate and will fail the connection if one is not provided.
   Some deployments may permit no peer authentication for some or all
   connections.  When peer authentication is not used, implementations
   MUST take care to limit network access appropriately for
   unauthenticated peers and implementations MUST use resumption with
   caution to ensure that a resumed session is not granted more
   privilege than was intended for the original session.


Issue #47<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/47> - Needs DIscussion and proposal - how does the peer validate the identity of the server?

Commit (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d0c3d6f04c97a62ef80002d2f32622b5e8b5fbd6) with the following text merged:

  The EAP server identity in the TLS server certificate is typically a
   fully qualified domain name (FQDN).  EAP peer implementations SHOULD
   allow users to configuring a unique trust root (CA certificate) and a
   server name to authenticate the server certificate and match the
   subjectAlternativeName (SAN) extension in the server certificate with
   the configured server name.  In the absence of a user-configured root
   CA certificate, implementations MAY rely on system-wide root CA
   certificate bundles for authenticating the server certificate.  If
   server name matching is not used, then peers may end up trusting
   servers for EAP authentication that are not intended to be EAP
   servers.  If name matching is not used with a public CA bundle, then
   effectively any server can obtain a certificate which will be trusted
   for EAP authentication by the Peer.

   The process of configuring a root CA certificate and a server name is
   non-trivial and therefore automated methods of provisioning are
   RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
   a Configuration Assistant Tool (CAT) to automate the configuration  process.  In the absence of a trusted root CA certificate (user
   configured or system-wide), EAP peers MAY implement a trust on first
   use (TOFU) mechanism where the peer trusts and stores the server
   certificate during the first connection attempt.  The EAP peer
   ensures that the server presents the same stored certificate on
   subsequent interactions.  Use of TOFU mechanism does not allow for
   the server certificate to change without out-of-band validation of
   the certificate and is therefore not suitable for many deployments.


Issue #29<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/29> -  Needs DIscussion and proposal - mutual authentication section is broader than mutual authentication

Section 2.1.1 renamed to "Authentication".

We plan to push a few more updates during the coming week. We plan to submit version -15 shortly afterwards. Publishing version -15 does not mean that it is ready for publication as RFC. Instead, it will be an opportunity for others who don't follow the draft on github to review and provide feedback.

--Mohit





_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu