IETF Last Call Review of draft-ietf-emu-eap-arpa-06
review-ietf-emu-eap-arpa-06-genart-lc-robles-2025-05-13-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-emu-eap-arpa-06
Reviewer: Ines Robles
Review Date: 2025-05-13
IETF LC End Date: 2025-05-13
IESG Telechat date: Not scheduled for a telechat

Summary:

This document defines the eap.arpa domain as a way for Extensible
Authentication Protocol (EAP) peers to signal to EAP servers that they wish to
obtain limited and unauthenticated network access. EAP peers indicate the type
of access requested by using pre-defined identifiers in the Network Access
Identifier (NAI) format defined in RFC 7542.

The document is generally well written. I have a few comments and suggestions
below for clarification and potential improvements.

Comments/Suggestions below as follows:

1- Section 3.5: "...when a provisioning NAI is used, any EAP NAK sent by a
server MUST contain only EAP type zero (0)... Similarly, when an EAP peer uses
a provisioning NAI and receives an EAP NAK, the contents MUST be ignored."

If the peer is required to ignore the content, then it cannot enforce or
validate that the received EAP type was 0. Perhaps a clarification would be
nice. What about something like: " when an EAP peer uses a provisioning NAI and
receives an EAP NAK, the peer MUST ignore any suggested EAP type in the NAK..."
?

2- Section 5.1: "...The device SHOULD ignore the EAP server certificate
entirely, as the server's identity does not matter..."

2.1- Would the authors agree that this guidance departs from the TLS security
model, where server authentication is generally considered a core security
mechanism?

2.2- How does the recommendation to ignore the server certificate align with
the guidance in RFC 5216 (Section 5.3), which states that the peer SHOULD
perform certificate path validation and MUST ensure that the certificate is
appropriate for use with EAP-TLS,

2.3- Could alternative approaches such as pinned certificates (trusting a
specific server certificate) or local trust anchors (constraining validation to
a preloaded CA set) provide a better trade-off between security and
provisioning usability?

3- Section 5.3: "It is RECOMMENDED that EAP-NOOB peers use "@noob.eap.arpa"
first, and if that does not succeed, use "noob@eap-noob.arpa""

3.1- Why is @noob.eap.arpa preferred? Is it simply newer? Does it offer
implementation or operational advantages? Are there any security implications?

3.2- Suppose the server fails to respond to @noob.eap.arpa, and the peer
retries with noob@eap-noob.arpa. Should the peer treat a failure as equivalent
to “form not supported” or “provisioning failed”?

3.3- What about rate limiting? Since both identity forms map to EAP-NOOB,
should peers be permitted one attempt per NAI form, or should rate limiting
apply per EAP method regardless of the NAI used?

4- Section 6.2.1:

"The following table gives the initial values for this table."  -> The table is
not displayed correctly in this section, and it is missing a caption.

Nits:

“specificatipon” → “specification”

“Tf the server...” → “If the server...”

“wif the peer...” → “if the peer...”

“actoes” → “actors”

“poeers” → “peers”

“registed” → “registered”

“its' access” → “its access”

"Section Section 3.4.2" → "Section 3.4.2"

Thanks for this document,

Ines.