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 Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
