On Jan 28, 2025, at 9:33 PM, Paul Wouters <paul.wout...@aiven.io> wrote: > I've done my AD review for draft-ietf-emu-eap-arpa > > I found a few issues that I'd like to see addressed or discussed. > I have also have one comment and a bunch of nits.
Thanks. > Issue #1 > > Similarly, if the server does not support the current provisioning > method, and is unable to negotiate a different one, it MUST reply > with a NAK of type zero (0) as per [RFC3748], Section 5.3.1. This > reply indicates that the requested provisioning method is not > available, and that the peer should choose a different method of > authentication. That different method may be another provisioning > method, or it may be a full authentication. > > I find this text conflicting. It talks about if the "current provisioning > method" isnt supported, AND is "unable to negotiate a different one" but > then continues with "the peer should choose a different method" and that > this "may be another provisioning method". But didn't it just say that it > determined it will be "unable to negotiate a different one" ? Yes. The phrase "provisioning method" is perhaps unclear, and can be confused with EAP method. I'll change it to "does not recognize the NAI", and clarify the rest of the text. > Issue #2 > > Once a peer is authenticated, it MUST be placed into a limited > network, such as a captive portal. > > vs > > Implementations SHOULD give peers access which is limited in scope. > > I don't fully understand the difference between "limited network" and > "access limited in scope". These seem similar concepts, but one has a > MUST and the other has a SHOULD, so it feels conflicting? I think possibly > what is meant is limited in size of bandwidth and volume of data transfer? > If so, I wonder if the SHOULD should be a MUST ? (or is the limited network so > boring they will never be able to use much data anyway ? :) The intent is to say not just "a limited network", but to define that a limited network SHOULD also limit the time and bandwidth of the devices. And that the provisioning network should offer minimal services. I'll reword and clarify. > Issue #3 > > Where possible the device SHOULD warn the end user that the > provided certificate is unchecked, and untrusted. > > It was not clear to me initially that this was talking about the HTTPS > captive portal certificate and not the EAP Peer certificate. > > I would probably not use normative text here about the HTTPS layer. That > is totally out of control of this specification and totally depending > on the web brower/OS behaviour and trust store. Perhaps only mention > that it would be expected to throw a warning and that such warnings > can be prevented by using a commonly trusted WebPKI CA to prevent any > warnings. I'll reword to remove the normative text. > Issue #4 > > and where those servers are not updated to ignore the ".arpa" domain > > I would say "eap.arpa" here. Otherwise we are making statements about unknown > possibly future items that will go under ".arpa". Fixed. > Issue #5 > > RFC7542 doesn't say anything about lowercase for NAI, which is in UTF8 format. > Why do the IANA Considerations say "lower case only" ? Also, to be valid DNS, > this would have to be further limited in valid character set and possible > mention > to use A-Label (punycode) and not U-Label. To avoid all of this, would it not > be easier to say the NAI MUST be in US-ASCII with [a..z] and "-" only, where > "-" > may not be the first character (or maybe find a proper reference for this in > the DNS Terminology for syntax of Host Names ? I'll add a referenced to [STF13], which is RFC 1034 and 1035 for DNS name comparison. I'll add a reference to the A-label definition in https://datatracker.ietf.org/doc/html/rfc5890#section-2.3.2.1 > Issue #6 > > But in order to allow for the allocation of values prior to > the RFC being approved for publication, the Designated Expert > can approve allocations once it seems clear that an RFC will > be published. > > I would remove this text and leave it up to the existing Early Code Point > registration policies established IETF wide. OK. > Issue #7 > > Note that the right to use a self-allocated name is tied the > ownership of the corresponding domain. If an organization loses > the right to use a domain name, then it is no longer appropriate > for it to use that domain name within the "v." self-allocation > space. > > I would remove this text and leave it to lawyers and judges to decide > what is allowed or not for some string that looks like a FQDN. We don't > want to become a party in such fights :P OK. I think the sentence before this paragraph makes it clear that only the current domain owner can use the domain. > Issue #8 > > The methods defined here SHOULD only be used to bootstrap initial > network access. > > Why not MUST ? Yup. MUST it is. > Issue #9 > > All subsequent application-layer traffic SHOULD be full authenticated > and secured with systems such as IPsec or TLS > > I am confused about "subsequent" because is that talking about the > post-bootstrap > authentication to the network, or post-boostrap-and-post-authentication ? Eg > if this is about "use of the network", then I think it would be clearer to > remove > from this specification, as this specification is only about bootstrap and > subsequent authentication methods, not about what comes after that. OK. > Comment #1 > > Section 8.2 could give an example, such as abuse using DNS as a tunneling > technique to > gain "full network access". I'll add that, and reference the earlier discussion of limited networks. Then add a summary / checklist of what to do. > > NITS: > - Expand TEAP on first use > - "proxied by any any" - remove duplicate "any" Done. > I find the following sentences a bit weird. I think it can just be removed: > > We now discuss the NAI format in more detail. We first discuss > the eap.arpa realm, and second the use and purpose of the > username field. Done. > - "The subdomain in realm is assigned " Maybe "a realm" or "the realm"? "subdomain in the eap.arpa realm" > I find this sentence also a bit odd: > > Having defined the format and contents of NAIs in the eap.arpa > realm, we now need to define how those NAIs are used by EAP > supplicants and EAP peers. > > Maybe: The use of NAIs by supplicants and EAP peers follow below= Ok. I'll reword. > - "when receiving a an EAP Nak." Remove "a " Done, along with the rest of the comments. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
