Thanks again for the input! That's a good point about HTTPS vs HTTP. The document should never mention HTTP as part of the solution.
On 6 July 2018 at 13:43, Tirupachur Comerica, Subash < [email protected]> wrote: > Hi Kyle, > > Thanks for CC’ing the right alias. > > The draft seems to use HTTP / HTTPS interchangeably, maybe we should just > stick with HTTPS then, to ensure the TLS protects the API server? > > For example, the abstract says HTTP: > > This document aims to document consensus on the CAPPORT architecture. > > DHCP or Router Advertisements, an optional signaling protocol, and an > > HTTP API are used to provide the solution. The role of Provisioning > > Domains (PvDs) is described. > > > > I agree that the functionality bundling is a design decision and may not > be architectural. > > I still haven’t completely gone through the API draft you mention in II) > below. I may come back to you on this for questions, inputs, if any. > > > > Thanks again for the quick turn-around. > > > > Thanks, > > Subash > > > > > > *From: *Kyle Larose <[email protected]> > *Date: *Friday, July 6, 2018 at 4:46 AM > *To: *"Tirupachur Comerica, Subash" <[email protected]> > *Cc: *"[email protected]" <draft-ietf-capport- > [email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, "[email protected]" < > [email protected]> > > *Subject: *Re: Comments/Queries on draft-ietf-capport-architecture > > > > Hi Subash, > > > > captive-portals is the publicly archived list. I've copied it. I'll > respond to your question inline. > > > > For those on the list who haven't seen this yet, please read my previous > reply. I had some thoughts related to the API in it. > > > > On 5 July 2018 at 19:54, Tirupachur Comerica, Subash < > [email protected]> wrote: > > Hi Kyle, > > Thanks for your response. > > BTW, do you know if this is the right alias that gets archived? Otherwise > can you please include the right alias? > > > > Thanks for your responses. > > I have a follow-up question. > > 1) Was it considered to provide two URIs during provisioning, one > for Server API and another for the actual web-portal, because that way it > becomes more tough to break two systems to masquerade an end-user? > > I don't think we ever seriously considered it. > > > > a. In the current design, with just 1 URI returned during > provisioning, dns-spoofing the Server API URI and returning an > eavesdropping web-portal can gather legitimate login/password. > > Would this not lead to a failure to validate the tls certificate of the > malicious server? From the document: > > > > " > > The API MUST use TLS for privacy and server authentication. The > > implementation of the API MUST ensure both privacy and integrity of > > any information provided by or required by it. > > " > > b. Secondly, may be, the API server may also send the Signal, which > is kept separate from the web-portal. I definitely like the word > authenticity(that is mentioned below) and in this architecture, a single > authenticity check for API server and Signal combo would suffice. However, > this is bundling(co-hosting) the functionality of Signaling to the API > Server. > > The Enforcement Device is logically responsible for triggering the signal, > since it is the device which actually devices whether to block or allow > traffic. That said, there is no reason it could not relay it through the > API server. Or, the API server could also be the enforcement device. > However, those are design decisions for the protocol or deployment; I > wouldn't want to tie down the options in the architecture. As you've noted > it'd couple the functionality. This is certainly an option to consider > when we design the protocol! > > > > But then, if the DHCP server is compromised, nothing much can be done. > > > > Thanks, > > Subash > > > > *From: *Kyle Larose <[email protected]> > *Date: *Tuesday, July 3, 2018 at 5:51 PM > *To: *"Tirupachur Comerica, Subash" <[email protected]> > *Cc: *"[email protected]" <draft-ietf-capport- > [email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > *Subject: *Re: Comments/Queries on draft-ietf-capport-architecture > > > > Thanks for the detailed feedback, Subash. I'll respond inline. > > > > On 2 July 2018 at 02:40, Tirupachur Comerica, Subash < > [email protected]> wrote: > > Dear Authors, > > I was reviewing the new version of the draft and had the following > queries/comments. > > I) > > In the excerpt below, isn’t it the network that decides the policy rules > to configure the default route on the user equipment and not the user > equipment’s operating system? > > MAY restrict application access to networks not granting full > > network access. E.g., a device connected to a mobile network may > > be connecting to a WiFi network; *the operating system MAY avoid* > > * updating the default route until network access restrictions have* > > * been lifted* (excepting access to the Captive Portal server). This > > has been termed "make before break". > > > > > > A device may be connected to two independently managed networks, so at > some point it will be faced with the decision to choose one over the other, > particularly for cases where both networks advertise a default route. > Consider the common case of a mobile device connected to 4G. It is using > that connection for all of its IP communication. Now consider that same > device entering into the range of a known wifi hostpot. The hotspot is > going to tell the device that it may be used as its default route. Which > should the device choose? My understanding is that typically the OS will > favour wifi networks over mobile networks, since wifi tends not to be > metered, and is often faster. > > > > What this point is trying to capture is that the OS will first try to > determine whether the wifi network actually has network connectivity prior > to changing its routes. This prevents existing connections from needlessly > breaking if you've wandered into range of a broken/misconfigured/etc > network. > > > > II) > > In the excerpt below, sorry I could not clearly get if you meant the DHCP > server or the web-server serving the captive portal page? > > What exactly is the *Accept* field here, I didn’t find any mention in RFC > 7710 as well. > > > > For backwards compatibility, it is > > RECOMMENDED that *the server check the "Accept" field* when serving the > > URI , and serve HTML pages for "text/html" and serve the API for > > "application/json". [REVISIT: are these details appropriate?] > > > > > > This is talking about the web-server (aka the API). > > > > We actually discussed this at IETF 101 if I remember correctly. The idea > is that the client indicates in its http request accept header ( > https://tools.ietf.org/html/rfc2616#section-14.1 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Frfc2616%23section-14.1&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7Cec3104d8533b406e590d08d5e1483747%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=I8ZnWtBFvDGJaHs8GkVMw6Ce3wEplIZ6M52tk8ohvmY%3D&reserved=0>) > what type of content the client expects. A legacy client would likely > request text, and they certainly would not request json. Thus, by serving > up a standard html page for the text/html case, we maintain backwards > compatibility. On the other hand, for modern clients, which will request > application/json, we can serve up the API. > > > > That said, there are two issues here for sure: > > > > 1. The most recent API doc (https://tools.ietf.org/html/ > draft-ietf-capport-api-01 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Fdraft-ietf-capport-api-01&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7Cec3104d8533b406e590d08d5e1483747%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=TDrVeMfhSlUgqK7NlZFNHN7XGtyAqJPaKNvCFN5cSWc%3D&reserved=0>) > uses application/json-capport, so at the very least we need to update this\ > > 2. I don't see anything about accepting text to fall back to html in the > api doc. > > > > Ultimately, it feels to me like the architecture is providing too much > detail--it should simply recommend some form of backwards compatibility > mechanism, and some other document should specify the details of *how* to > provide that backwards compatibility. On the other hand, it doesn't seem > like we've provided this mechanism in the API so far. > > > > Does anyone remember what we concluded here at IETF 101? :) I don't see > anything in the minutes. > > III) Minor typos here: > > 3. User Equipment Identity > > > > Multiple components in the architecture interact with both the User > > Equipment and each other. Since the User Equipment is the focus of > > these interactions, the components must be able to both identify the > > user equipment from their interactions with it, and be able to agree > > on the *identifty* of the user equipment when interacting with each > > other. > > > > Whoops! I even ran it through a spell check. Must have missed that one. :) > > > > 3.2.3. Visible to the API > > > > Since the API will need to perform operations which rely on the > > * identifty* of the user equipment, such as query whether it is > captive, > > the API needs to be able to relate requests to the User Equipment > > making the request. > > > > *sigh* > > > > IV) For this step, how do you verify the plausibility(I guess it includes > authenticity, integrity)? > > *5. The User Equipment verifies the signal is plausible.* > > > > > > It's not really well defined yet, since we haven't specified the signal. > That said, we were considering signing the packet somehow, IIRC, or putting > some hint that would be relatively hard to spoof if not on-path. > > > > Perhaps authenticity is a better term? > > > > Either way, the signal currently specifies these requirements, and now > that I read them or the Nth time, it seems like we're not doing a good job > of suggesting that the signal allow for validation/verification: > > > > > > 3. The protocol SHOULD have a method of identifying the source of > > signals. > > > > 4. The signal SHOULD NOT include any information other than a prompt > > to contact the API, and any information necessary for validation. > > > > Do we really need to identify the source of the signals? Not unless the > validation mechanism requires it. So, I think that #3 should be rephrased > along the lines of: > > > > "The protocol SHOULD have a method of validating that signals were sent by > an enforcement device on the user equipment's path to the external > network." (That last bit may be unnecessary... Trying to capture what it > means for the signal to be valid) > > > > Thanks, > > Subash Tirupachur Comerica > > Ruckus Networks(An Arris Company) > > > > On 6/30/18, 5:04 AM, "IETF Secretariat" <[email protected]> > wrote: > > > > > > Hello, > > > > This is a notification from the ID list for Captive Portal Interaction. > > > > Document: draft-ietf-capport-architecture, > > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf- > capport-architecture%2F&data=01%7C01%7Csubash.tirupachurcomerica%40arris. > com%7Cbae1510308a743e43f6d08d5de81ad83%7Cf27929ade5544d55837ac561519c > 3091%7C1&sdata=SCJ2Lo%2BpR%2BsghePG8oLxjZ2HV%2BkBZKqfOKO2nsfSTW0%3D& > reserved=0 > > > > Change by Kyle Larose on 2018-06-30 05:04 PDT: > > > > New version available: *draft-ietf-capport-architecture-02.txt* > > > > Best regards, > > > > The Datatracker draft tracking service > > (for the IETF Secretariat) > > > > > > > > >
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
