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

[Kyle Larose <[e-mail]>]

Inline again.

Note: I've clipped sections I'm not responding to.

On Fri, 12 Jun 2020 at 20:50, Benjamin Kaduk <[e-mail]> wrote:
>
> Also inline.
>
> On Thu, Jun 11, 2020 at 09:12:34AM -0400, Kyle Larose wrote:
> > Hi Benjamin,
> >
> > >
> > >    None of the above requirements are mandatory because (a) we do not
> > >    wish to say users or devices must seek full access to the captive
> > >    network, (b) the requirements may be fulfilled by manually visiting
> > >    the captive portal web application, and (c) legacy devices must
> > >    continue to be supported.
> > >
> > > side note: in my opinion, it's possible to support legacy devices in
> > > practice without baking their limitations into the spec.
> > >
> > >    If User Equipment supports the Captive Portal API, it MUST validate
> > >    the API server's TLS certificate (see [RFC2818]).  An Enforcement
> > >
> > > We should probably cite RFC 6125 here and say something about how the UE
> > > gets a name to validate the server's certificate against (and what name
> > > type to use).
> >
> > We can do this.
>
> Please feel free to reach out if you want advice on text to put here; it's
> (unfortunately) a little prone to jargon.

I would definitely appreciate some help here. Thanks!

> > >
> > > Section 3.2.1
> > >
> > >    Each instance of User Equipment interacting with the Captive Network
> > >    MUST be given an identifier that is unique among User Equipment
> > >    interacting at that time.
> > >
> > > side note: "MUST be given" gets a knee-jerk "by whom?" response from me.
> > > It's probably okay for this document to not specify, though, as it may
> > > depend on the nature of the Captive Network.
> > >
> >
> > What if we say "by the Captive Network"? I think that makes it clear
> > that it's the responsibility of
> > the network, though that does perhaps complicate things if the system
> > chooses to use the MAC address, for example, which isn't "given" by
> > the network. In that case, the network would use the MAC that it has
> > inferred from its communication with the UE to construct the identity
> > that it then gives to the UE. I guess it makes sense when put that
> > way.
> >
> > But, perhaps "given" is the wrong term here? Should we rephrase to
> > "The Captive Network MUST associate the User Equipment with an
> > identifier that is unique among User Equipment that is interacting at
> > that time?"
>
> That's a pretty good point; the association is more important than giving
> or assignment.

Alright. I'll rephrase along the lines of my second suggestion about
association.

>
> > >    Over time, the User Equipment assigned to an identifier value MAY
> > >    change.  Allowing the identified device to change over time ensures
> > >    that the space of possible identifying values need not be overly
> > >    large.
> > >
> > > Is the identifier assigned to a given UE on the same network expected to
> > > be able to change as well?  This may have some privacy considerations...
> > >
> >
> > I think so. E.g. if a DHCP lease expires, or the UE reattaches
> > multiple times. What are the
> > privacy considerations you're thinking of?
>
> A device may seek to cause such an identity change simultaneously with
> other privacy-promoting activities (like clearing cookies, changing MAC/IP
> Address, etc.).  That's the main one that comes to mind, at least, though
> privacy is a tricky area...
>

Thanks for the clarification.  I'll add some text along the lines of:

"Note that the User Equipment could force a change of the associated
identifier as part of a
workflow related to promoting privacy, though the mechanisms by which
it does so are out of
scope of the document."

> > >
> > >    3.  The User Equipment's UI indicates that the length of time left
> > >        for its access has fallen below a threshold
> > >
> > >    4.  The User Equipment visits the API again to validate the expiry
> > >        time
> > >
> > > side note: I feel like there's implicitly some User action in here,
> > > though I don't know that we need to actually say anything about it.
> > > (Otherwise we wouldn't have the UI indicating things.)
> > >
> >
> > We may need to change this up a bit and then mention that the user
> > accepts the prompt. E.g.
> >
> >
> >
> >    3.  The User Equipment's detects that the length of time left
>
> (nit: s/'s//)

Whoops. Thanks.

>
> >        for its access has fallen below a threshold
> >
> >    4.  The User Equipment visits the API again to validate the expiry
> >        time
> >
> >    5.  If expiry is still imminent, the User Equipment prompts the user
> >        to access the web-portal URI again
> >
> >    6. The user equipment accepts the prompt
>
> (not sure if this is user or UE)
>

Since we're talking about devices with user interfaces, it should be the user.

New:
    6. The user accepts the prompt displayed by the user equipment.

> >    7.  The User extends their access through the web-portal via the UI
>
> nits aside, this looks good to me.
>

> > > Section 7.3
> > >
> > >    The API MUST ensure the integrity of this information, as well as its
> > >    confidentiality.
> > >
> > > Who/what is the attacker(s) that we need to preserve confidentiality from?
> > >
> >
> > 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.

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.

> > > Section 7.4
> > >
> > >    *  Accesses to the API Server are rate limited, limiting the impact
> > >       of a repeated attack.
> > >
> > > One might consider a flooding attack that tries to get the UE to use all
> > > its (rate-limited) connections to get some information that is not the
> > > information that it's most important for the UE to have.  If there's
> > > only a single operation that can be performed at the API Server (which I
> > > believe is the intent?) there is no such attack, but it may be worth
> > > mentioning that there is no such attack.
> > >
> >
> > In this case that's the intent (i.e. only visit to get whether we're
> > still captive). That's a good point, though: if we ever expand on
> > that, it could open the door to such an attack, so it's worth
> > mentioning why it's not a problem.
> >
> > That said, I actually don't quite see how the uni-directional signal
> > could be used to get information back to the attacker. Could you maybe
> > describe that in a bit more detail?
>
> The attack I had in mind did not involve exfiltrating information to the
> attacker, just causing the UE to get confused (or miss updates, etc.).
>

Ah, I see. Thanks for the clarification: we don't discuss that the
rate limiting, while preventing the system from being
brought to its knees, could still cause a loss of information. How about:

".. limiting the impact of a repeated attack. However, note that if
the rate limit stops the UE from requesting information from the API
that it needs, particularly if there are multiple types of request the
UE could make to the API, then there is a chance that the UE could
lose information when under such an attack. The UE could take steps to
mitigate such an attack by rate limiting each type of request
individually."

I suppose we may also want to mention that if there are an unbounded,
or large number of types of request, then my above suggestion for a
mitigation may not suffice... Or do you think that's obvious?

> >
> > > Section 8.1
> > >
> >
> > >    Another test that can be performed is a DNS lookup to a known address
> > >    with an expected answer.  If the answer differs from the expected
> > >    answer, the equipment detects that a captive portal is present.  DNS
> > >    queries over TCP or HTTPS are less likely to be modified than DNS
> > >    queries over UDP due to the complexity of implementation.
> > >
> > > Is the reader supposed to draw the conclusion that DoTCP/DoH provide
> > > less-reliable captive-portal detection than Do53?  (I assume "TCP" is
> > > not a typo for "TLS", here, though am unsure enough to want to check.)
> >
> > Correct on both accounts. Do you think we should clarify the intent?
>
> I would like to say a little more here, yes.  There's a few ways we could
> do it, ranging from talking about effectiveness of portal-detection to
> discussion of what is common in captive portals at present.
>

Robert brought up the lack of a problem statement for the document in
his review. We may choose to add that. If we do, I think we can
probably refer to that section here to clarify. Regarding what is
common in captive portals as present, perhaps rephrasing this bit to
point out that
the common UE implementation of detection is in response to the common
captive portal implementation of DNS modifications could
help to clarify.

Perhaps rephrasing to:
   ... Typical implementations use DNS over UDP, under the assumption that most
   existing captive portal implementations will only modify DNS over UDP, since
   queries over TCP or HTTPS are less likely to be modified than DNS
queries over
   UDP due to the complexity of implementation.

will do it?

>
> -Ben

Thanks again!

Kyle