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

[[e-mail]]

Kyle, Ben,
One comment below.

On 2020-06-23 07:42, Kyle Larose wrote:
> 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!

Looking at RFC6125 (section B.2), should we replace
"the iPAddress subjectAltName is used to validate the server 
certificate."
with,
"... the iPAddress subjectAltName must be present in the certificate and 
must
exactly match the IP address in the API server's URI."


> 
>> > > > >
>> > > > > 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
> 
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals

-Dave