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.
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" ?
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 ? :)
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.
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".
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 ?
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.
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
Issue #8
The methods defined here SHOULD only be used to bootstrap initial
network access.
Why not MUST ?
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.
Comment #1
Section 8.2 could give an example, such as abuse using DNS as a tunneling
technique to
gain "full network access".
NITS:
- Expand TEAP on first use
- "proxied by any any" - remove duplicate "any"
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.
- "The subdomain in realm is assigned " Maybe "a realm" or "the 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
- "when receiving a an EAP Nak." Remove "a "
- "Another way for provisioning to fail is when"
I read that wrong the first time. Perhaps "Another way for the provisioning
method to fail is when"
- "An EAP peer may be have been provisioned" -> "An EAP peer may have
been provisioned"
"dropping off of " -> "dropping off from "
- "additional discussion of this topic." -> "additional discussion on this
topic."
- "MUST examining the identity" -> "MUST examine the identity"
- "MUST process the request through pre-existing methods."
I don't think "pre-existing" is right here. Either "existing" or "other"
seems better
- "Similarly, if the server does"
I would remove "similarly" to avoid implementers thinking the error
reply must be similar or the same, as it can (will?) be different.
- "and of the order of seconds to tens" -> "and in the order of seconds to
tens"
- "times longer than that" -> "times longer than this"
- "where both parties knowing" -> "where both parties know"
- "certification authorities (CAs)" Is it not "certificate authorities" ?
- [RFC5216] Section 2.1.1 The other sections have links but this one
does not. Can you add it?
- "It is possible to also use" -> "It is also possible to use" (to avoid
'also' being read as "additionally"
Paul
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
