Re: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Wed, Aug 15, 2018 at 8:26 AM, Alan DeKok <[e-mail]> wrote:

> On Aug 15, 2018, at 11:15 AM, Eric Rescorla <[e-mail]> wrote:
> >
> > I concur with Adam's DISCUSS (but marking no-objection to let him
> > manage this). Specifically, you need to describe what the security
> > expectations are for the Operator-NAS-Identifier. Need it be
> > unguessable? Should separate identifiers that refer to the same NAS be
> > unlinkable? "Cryptographically strong" is not a sufficiently specific
> > term to determine what the requirements are here.
>
>   I've rewritten the problem text in order to (a) avoid these issues, and
> (b) discuss the security implications in more detail.
>
> > COMMENTS
> > S 6.
> >>     issues.
> >>
> >>     The Operator-NAS-Identifier SHOULD be created by the Visited Network
> >>     such that its contents are opaque to all other parties.  This
> ensures
> >>     that anyone observing unencrypted RADIUS traffic gains no
> information
> >>     about the internals of the Visited Network.
> >
> > See above about the requirements here. Does there need to be an
> > unlinkable identifier each time?
>
>   No.
>
>   External parties already know the identity and number of NASes in a
> Visited Network.  The Operator-NAS-Identifier attribute here is opaque
> simply because there is no compelling reason for giving it a public meaning.
>
>   As such, there is no need for integrity checks, replay detection,
> privacy, etc.
>

OK, well, the text needs to say this, because the existing text implies
otherwise.

-Ekr


>   Alan DeKok.
>
>