Re: [Emu] Murray Kucherawy's No Objection on draft-ietf-emu-tls-eap-types-12: (with COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Feb 16, 2023 at 6:20 AM Alan DeKok <[e-mail]>
wrote:

> >   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.
>

You do have control over what's compliant with this specification though.


> > 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.
>

Is there any legitimate reason for an implementer to decide to deviate from
the SHOULD and still expect to interoperate?  The text you're suggesting
sounds a lot like a MUST to me.


>   i.e. follow the recommendation and work with others, or don't follow it
> and you're on your own.
>

So does that.


> >   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".
>

I think this point should be made clear, i.e., that this is only a SHOULD
because of backward compatibility with previous documents.  In fact, I
suggest using "MUST, unless ..."

Private environments, I would imagine, are always free to interoperate or
not, so I'm not too worried about the (b) case.

-MSK