Dear Alan, Thank you for addressing my comments.
Best Regards, Ines On Fri, May 30, 2025 at 7:45 PM Alan DeKok <al...@deployingradius.com> wrote: > 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
