On Feb 16, 2023, at 12:21 AM, Murray Kucherawy via Datatracker
<nore...@ietf.org> wrote:
> \\------------------
>
> In Section 2.1:
>
> Which define Master Session Key (MSK) and Extended Master Session Key
> (EMSK).
>
> This seems to be part of a larger sentence that's partly missing.
I'll clarify that.
> It is RECOMMENDED that vendor-defined TLS-based EAP methods use the
> above definitions for TLS 1.3. There is no compelling reason to use
> different definitions.
>
> Why isn't this MUST if there's no compelling reason to do otherwise?
We don't have change control over vendor-defined TLS methods.
> I concur with Roman's comment about the SHOULD NOT in Section 2.4.
Fixed.
> In Section 2.2:
>
> Where || denotes concatenation.
>
> I understand the earlier citation I made above now, but still this should be a
> complete sentence. You later have:
>
> where CMK[n] is taken from the final ("n"th) inner method.
>
> ...which is better in that it looks more like a continuation of something, but
> still it could be better. Suggest:
>
> In this context, CMK[n] is taken from the final ("n"th) inner method.
OK.
> In Section 3.1:
>
> In other weds, [...]
>
> I think you meant "words".
>
> The outer identity SHOULD use an anonymous NAI realm. [...]
>
> I suggest you add a sentence or two explaining why an implementer might
> legitimately choose not to do this.
I'll reference RFC 7542 (NAI), which goes over these issues in detail.
Perhaps:
The outer identity SHOULD use an anonymous NAI realm, which allows for
both user privacy, and for the EAP session to be routed in an AAA
framework as described in [RFC7542] Section 3. Where NAI realms are
not used, packets will not be routable outside of the local
organization.
i.e. follow the recommendation and work with others, or don't follow it and
you're on your own.
> This practice is NOT RECOMMENDED. User accounts for an organization
> should be qualified as belonging to that organization, and not to an
> unrelated third party. There is no reason to tie the configuration
> of user systems to public realm routing, that configuration more
> properly belongs in the network.
>
> This formulation is curious; you first give implementers an "out" with NOT
> RECOMMENDED, and then basically argue that it should be a MUST NOT. I suggest
> revisiting this pattern anywhere you've used it. If you prefer to keep it, I
> suggest changing the prose a bit to explain why one might choose to deviate
> from the advice presented.
TBH I don't see any valid reasons for deviating from the advice given. It's
more that this document cannot mandate (a) changes from historical practices
defined in previous documents, and (b) what people do in their own private
environment.
It's really "If you want your systems to work on the Internet, here's what
you do. If you don't care about that, you're on your own. Go figure it out
yourself".
> Thanks for including Section 5.
>
> In Section 6.1:
>
> There MAY be
> additional protocol exchanges which could still cause failure, so we
> cannot mandate sending success on successful authentication.
>
> This should just be "may", not "MAY". You're not presenting an implementation
> choice.
Fixed.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
