Markdown Version | Session Recording

Session Date/Time: 07 Nov 2025 16:30

EMU IETF-124 Meeting Minutes

Summary

The EMU Working Group convened at IETF-124 to discuss the status and future direction of several EAP-related drafts. Key discussions included a proposal for an EAP-TLS default for onboarding devices, an update on EAP-Token-based Authentication (EPPT), and the need for a TEAPv2 revision. There was general support for the EAP-TLS onboarding proposal, with further discussion requested on the mailing list. EPPT is ready for a thorough working group review, with ongoing considerations regarding privacy-preserving abuse management. The working group also agreed to initiate the definition of requirements for TEAPv2 to address interoperability issues of its predecessor.

Key Discussion Points

• EAP-TLS Default for Onboarding Devices (Michael)

  • Problem Statement: EAP-TLS lacks a defined behavior when a client does not provide an identity during authentication.
  • Proposal: Direct clients without credentials to a "quarantine" or "magic network" by having them use a "no credential" Network Access Identifier (NAI), such as [email protected]. This leverages existing EAP-TLS mechanisms rather than introducing new EAP methods.
  • Benefits: Facilitates secure (encrypted) onboarding for devices (e.g., via captive portals for general devices or dedicated onboarding protocols for IoT devices) without requiring a separate SSID for onboarding, thereby reducing airtime consumption and network management overhead. It also allows devices needing remediation (e.g., patches for compliance) to access necessary resources.
  • Server Authentication: While initial client validation of the server certificate might not be possible for an unprovisioned client, retaining server authentication is considered beneficial. This approach aims to avoid creating further hurdles for future PKI solutions and allows clients to recognize previously encountered networks, aiding in network selection.
  • EAP Type vs. NAI: A separate EAP type was suggested for explicit signaling of onboarding intent. However, the sense of those present leaned towards the NAI approach for its ease of implementation with existing EAP-TLS software, relying on server-side policy changes.
  • Comparison to OWE: A concern was raised that if neither side authenticates, the proposal might replicate Opportunistic Wireless Encryption (OWE). The presenter clarified that the proposal does include server authentication (even if initially unvalidated by the client) and provides per-device encryption, differentiating it from purely open networks.
  • Industry Alignment: Noted alignment with FIDO Device Onboard (FDO) mechanisms that use EAP-TLS for "trust on first use" to provision permanent credentials, and with Wireless Broadband Alliance (WBA) concepts for "short-lived credentials" in Passpoint discovery.

• EAP-Token-based Authentication (EPPT) (Bart)

  • Status Update: The draft has been adopted by the working group and is deemed ready for a more detailed review.
  • Abuse Control and User Identification:
    • EPPT's design incorporates identity-free credentials and recommends against including user identifiers in outer RADIUS attributes to enhance privacy.
    • Discussion highlighted the inherent tension between user privacy and network operators' needs to identify and mitigate abusive behavior (e.g., pre-authentication attacks, Acceptable Use Policy violations).
    • Traditional methods like MAC address blocking are becoming less effective due to MAC randomization.
    • The general sense was that specific identity-based abuse control mechanisms are largely out of scope for the EAP method itself, and are typically handled at higher layers (e.g., RADIUS proxy, out-of-band communication with an Identity Provider (IDP)).
    • Privacy Pass (ACTs): Work on Anonymous Creditor Tokens (ACTs) within the Privacy Pass WG was noted as a potential avenue to allow for linking multiple sessions for abuse detection while attempting to preserve privacy. EPPT's remediation exchange could potentially be extended to support such tokens.
  • Channel Binding: A question was raised regarding the effectiveness of RFC 6677 channel binding and whether EPPT's prototype includes it. The presenter confirmed the prototype includes it and expressed interest in research to enhance channel binding.
  • Call for Review: The draft is considered ready for comprehensive working group review.

• TEAPv2 (Michael)

  • Problems with TEAPv1: TEAPv1 suffers from overly complex key derivation, inconsistent crypto binding, and significant unimplemented portions, leading to poor interoperability (with only a small subset of Microsoft implementations working reliably).
  • Goal for TEAPv2: The objective is to develop an interoperable specification that accurately reflects implementable practices and addresses the shortcomings of TEAPv1. The proposed approach emphasizes interoperability testing before comprehensive documentation.
  • Key Design Questions for TEAPv2:
    • Crypto Binding: Re-evaluation is needed for the necessity and extent of crypto binding. Specifically, whether all inner methods need to be bound to the outer TLS tunnel, or if a simpler binding is sufficient for tunnel integrity verification.
    • PKCS7/PKCS10: A decision is required on whether to explicitly implement or mark these as optional. Experience with RFC 5216 suggests that "optional" often means "unimplemented."
    • Feature Stripping: Consideration is being given to explicitly removing unimplemented and unused features from TEAPv2, while ensuring the protocol design remains extensible for future additions.
  • Use Cases and Requirements: There is a clear need to define the requirements and use cases for TEAPv2, particularly concerning combined machine and user authentication, which appears to be a strong driver for enterprise interest.
  • Compatibility: TEAPv2 must maintain compatibility with existing Windows TEAPv1 use cases, as this is considered a hard requirement for deployment.

Decisions and Action Items

• EAP-TLS Default for Onboarding Devices:
  • Decision: The working group will continue discussion on the mailing list to gauge interest in adopting the "EAP-TLS default for devices that need to onboard" draft. A poll of those present indicated no objections to pursuing this work.
  • Action Item: Mark (speaker) to post a comment on the mailing list clarifying the distinction between this proposal and Opportunistic Wireless Encryption (OWE).
• EAP-Token-based Authentication (EPPT):
  • Action Item: Alan and Jan-Fredrikas committed to reviewing the EPPT draft. Other working group members are encouraged to review the draft and post comments to the mailing list.
• TEAPv2:
  • Action Item: Michael to draft a new revision of the TEAPv2 document, starting with open questions about requirements and design choices (e.g., crypto binding, optional features), and encourage discussion on the mailing list.
  • Action Item: Working group members to articulate and track requirements and use cases for TEAPv2 on the mailing list.

Next Steps

• EAP-TLS Default for Onboarding Devices: Further discussion on the mailing list to determine if there is sufficient consensus for working group adoption.
• EPPT: Conduct a thorough review by working group members and discuss feedback on the mailing list. Continue investigating the integration of Anonymous Creditor Tokens (ACTs) and improvements to channel binding.
• TEAPv2: Proceed with the development of requirements and design proposals, followed by active discussion and feedback from implementers and the working group to refine the protocol specification.