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

[Kyle Larose <[e-mail]>]

Hi Ben,


On Sun, 21 Jun 2020 at 14:51, Benjamin Kaduk <[e-mail]> wrote:
>
> Hi Kyle,
>
> On Sun, Jun 14, 2020 at 12:13:30PM -0400, Kyle Larose wrote:
> > 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!
>
> How about:
>
> % If User Equipment supports the Captive Portal API, it MUST validate the
> % API server's TLS Certificate according to the procedures in [RFC6125].
> % The API server's URI is obtained via a network provisioning protocol,
> % which will typically provide a hostname to be used in TLS server
> % certificate validation, against a DNS-ID in the server certificate.  If
> % the API server is identified by IP address, the iPAddress subjectAltName
> % is used to validate the server certificate.
>
> (The last sentence is optional.)
>

That's excellent. 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."
>
> Thanks!
>
> > > > >
> > > > >    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.
>
> (still looks good)
>
> >
> > > > > 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.
>
> 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?
>
> > > > > 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?
>
> That might be more detail than the level of risk merits (and it's hopefully
> obvious, too).
>
> Thanks for adding the above discussion; it works for me.
>
> > > >
> > > > > 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?
>
> That should work, thanks.  It might be possible to wordsmith it down a
> little bit more, but I don't have any ideas coming to mind at the moment.
>

> Thanks for the updates!
>
> -Ben

Thanks again,

Kyle