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
