On May 13, 2025, at 6:15 PM, Ines Robles via Datatracker <nore...@ietf.org> wrote: > The document is generally well written. I have a few comments and suggestions > below for clarification and potential improvements.
Thanks. > 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..." > ? The peer isn't supposed to validate the NAK. It's just supposed to ignore it. I'll try to clarify the text. > 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? Yes. This is, however, a common practice in non-web protocols. Are there security issues which result from ignoring the server certificate? > 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, The document can update 5216 and 9190. While 5216 envisions full two-way authentication, it does allow for peer unauthenticated access. This specification clarifies that if the peer is unauthenticated, it doesn't always make sense to require server authentication. I'll clarify the text to explain that it doesn't change the requirements of RFC5216 for non-provisioning methods. And that if the server certificate isn't validated, the provisioning protocol MUST provide a way to authenticate the data being provisioned (e.g. HTTPS) > 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? I don't think that's feasible. The device can't pin a server certificate until it's gained network access. And once it's gained network access, it can be provisioned with real credentials. And therefore doesn't need further provisioning. For local trust anchors, it's difficult to know what those would be. The only ones which could be widely used and available are web certs. > 3- Section 5.3: "It is RECOMMENDED that EAP-NOOB peers use "@noob.eap.arpa" > first, and if that does not succeed, use "n...@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? I don't think there are security implications. The @noob.eap.arpa name is preferred because it lets implementations have a consistent management of domains. i.e. there are fewer special cases. > 3.2- Suppose the server fails to respond to @noob.eap.arpa, and the peer > retries with n...@eap-noob.arpa. Should the peer treat a failure as equivalent > to “form not supported” or “provisioning failed”? If it tries both, then provisioning has 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? I think rate limiting is applicable to all provisioning methods, and not just EAP-NOOB. This subject is covered earlier in the document: "Servers SHOULD rate-limit provisioning attempts. ..." I'll add a paragraph requiring that peers rate limit their attempts, too. > 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. I'll fix that, thanks. > Nits: Fixed, thanks. Alan DeKok. _______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
