Re: [Captive-portals] Benjamin Kaduk's Discuss on draft-ietf-capport-architecture-08: (with DISCUSS and COMMENT)

[Erik Kline <[e-mail]>]

> > > > Without knowing the details of the particular solution, it's a bit
> > > > hard to say for sure, but roughly
> > > > I'd say it's someone who wants to interact with the API using the
> > > > identity of the user. E.g. if we're using an 'unguessable' URI, an
> > > > attacker snooping on the communication with the API could determine
> > > > the URI, and use it.
> > > >
> > > > Does that sound reasonable?
> > >
> > > That seems like it's in the right ballpark.  I guess both the API URI and
> > > the web portal URI could be "unguessable" (though both would be protected
> > > by the same TLS connection, at least for the UE/API part of things).
> > >
> >
> > Tommy raised an objection in the issue
> > (https://github.com/capport-wg/architecture/issues/95) I submitted on
> > github for this. Initially,
> > I said that the API URI should be unguessable. I conflated the two
> > types of URI when I
> > wrote my initial reply. To clarify, I'm now planning only suggesting
> > that the user portal URI
> > be unguessable.
>
> That makes sense; there could be some value in having the API URI be
> consistent (notably, in not having to track devices at as low a level), and
> making it unique only starts adding value for the user-poral URI.
>
> > I'll repeat my earlier question: does anyone else have an opinion on
> > this? I feel like it could
> > be controversial, since it could add complexity to the solution, but I
> > do think it could help.
>
> Perhaps the chairs, at least, could weigh in?

I'm slightly unclear on what "unguessable" means in this context.  If
it means unique to a client, then the API URI should not be
per-client.  This is because the IPv6 RA option is multicasted to all
clients on the link and cannot reasonably be made per-client.