Benjamin Kaduk has entered the following ballot position for draft-ietf-capport-api-07: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-capport-api/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'll start off with a handful of high-level comments, some of which might qualify for Discuss-level points, but which have obvious resolution and for which I trust the authors and AD to do the right thing. JSON only has Numbers, not integers; Section 5 should not describe fields as integers without additional clarification (e.g., "integer, represented as a JSON Number"). Also, the GET example in Section 6 seems to be malformed, not specifying an HTTP-version. I also think we should go into more detail on the TLS usage, pulling in the relevant preexisting IETF BCP and proposed standards to take advantage of the current state of the art (details in the section-by-section comments). Additionally, I note some places in the section-by-section comments where we can go into more detail on the "chain of custody" of information presented to the user, making sure that we keep a trusted path from initial provisioning through to API server access and captive portal server access. There are some places where we don't seem to have a 100% airtight solution, and those gaps can be called out more clearly. Abstract with a Captive Portal system. With this API, clients can discover how to get out of captivity and fetch state about their Captive Portal sessions. The architecture document only implicitly talks about "Captive Portal sessions" (one mention in passing of when the "end of a session is imminent"). Should it have more text introducing the term/topic? Also, the architecture doc talks about learning the "state of captivity", but this formulation implies that there might be a much richer state to learn about. Section 1 * A URI that a client browser can present to a user to get out of captivity nit: this feels worded oddly to me; merely presenting (displaying?) a URI to the user does not help to do anything to get out of captivity. Presenting the dereferenced content referred to by that URI might be more effective at it, but would still require user action... * An encrypted connection (using TLS for connections to both the API and user portal) I think "authenticated" is equally as important as "encrypted" and should be mentioned alongside it. Section 3 2. API Server interaction, in which a client queries the state of the captive portal and retrieves the necessary information to get out of captivity. I may be overly tied to this "state of captivity" phrase, but is there a need to use "state" in a different formulation here? Section 4 For example, if the Captive Portal API server is hosted at "example.org", the URI of the API could be "https://example.org/ captive-portal/api" The architectures says that "the URIs provided in the API SHOULD be unique to the UE and not dependent on contextual information to function correctly." I guess this is referring to the contents of the resource retrieved by dereferencing the URI of the API and not the URI of the API itself? So this example is not in conflict with the SHOULD. If the API server needs information about the client identity that is not otherwise visible to it, the URI provided to the client during provisioning can be distinct per client. Thus, depending on how the Captive Portal system is configured, the URI might be unique for each client host and between sessions for the same client host. I appreciate having this explanation for why "[t]he client SHOULD NOT assume that the URI for a given network attachment will stay the same" as the first paragraph of the section tells us. The explanation is a little further from the requirement than I would like, but I don't have a suggestion for bringing them closer together :-/ For example, a Captive Portal system that uses per-client session URIs could use "https://example.org/captive-portal/api/X54PD" as its API URI. Hmm, assuming a base64 alphabet, that has like 30-ish bits of entropy available in the final path component. Is that representative of a large-enough identifier space for real deployments? Section 4.1 I mentioned this on the architecture document already, though perhaps it makes more sense to be done in the procotol document (this one): RFC 6125 has guidelines for TLS server authentication and is a good reference to cite. However (and regardless of whether we reference 6125 or not), we still will need to say what name type the client looks for in the certificate and how the client obtains the reference name to compare against the certificate contents. For us the latter is probably simple: just use what we got from the capport provisioning stage (and leave to 7710bis the question of how we authenticate *that* information), but it should still be said. example above). The hostname of the API SHOULD be displayed to the user in order to indicate the entity which is providing the API service. Should this hostname only be presented to the user (as, presumably, the identity of the captive network?) when the certificate validation succeeds? Presenting a name that has not been authenticated leaves the user open to spoofing attacks. Clients performing revocation checking will need some means of accessing revocation information for certificates presented by the API server. Online Certificate Status Protocol [RFC6960] (OCSP) stapling, using the TLS Certificate Status Request extension [RFC6066] SHOULD be used. OCSP stapling allows a client to perform This is consistent though not fully alligned with the recommendations in BCP 195 (RFC 7525). Should we reference the BCP and discuss our deviations from its recommendations? revocation checks without initiating new connections. To allow for other forms of revocation checking, a captive network could permit connections to OCSP responders or Certificate Revocation Lists (CRLs) that are referenced by certificates provided by the API server. In addition to connections to OCSP responders and CRLs, a captive This leaves it to the reader to know that there may be clients that don't support OCSP stapling and would need access to some other mechanism for revocation checking. It might be worth making that more explicit, since the type of client on the network is not always under the control of the network operator. network SHOULD also permit connections to Network Time Protocol (NTP) [RFC5905] servers or other time-sync mechnisms to allow clients to accurately validate certificates. Is there a way to reliably identify "NTP servers or other time-sync mechanisms"? My understanding is that the network generally doesn't have a way to indicate to a client what NTP (or other time protocol) server to use, so it would be fairly easy to end up in a situation where client and enforcement device disagree on what time-synchronization mechanism to use and the client gets locked out. be used by the Captive Portal API server. If the certificates do require the use of AIA, the captive network MUST allow client access to the host specified in the URI. [This implicitly assumes that the DNS resolution of that host is the same at both client and enforcement device, which hopefully goes without saying.] Section 6 Upon receiving this information the client will use this information direct the user to the the web portal (as specified by the user- nit: "to direct" Captive Portal JSON content can contain per-client data that is not appropriate to store in an intermediary cache. Captive Portal API servers SHOULD set the Cache-Control header in any responses to "private", or a more restrictive value [RFC7234]. Is there a well-defined ordering on Cache-Control header [field] restrictiveness such that "more restrictive value" is clearly defined? (nit: s/header/header field/.) Also, it's easy to miss a normative requirement like this when it's in an "Example Interaction" section; I suggest moving it elsewhere. Section 7 which the client can perform revocation checks. This allows the client to ensure that the API server has authority for a hostname that can be presented to a user. We should say something about how a client does (or does not) determine that the authenticated hostname is authorized to act for the network being joined. The last paragraph's discussion of confusables and "trustworthy name"s suggests that there isn't much of a direct chain here, just whether the certified domain name is "trustworthy" or not. Even if so (which I could understand being the case; it's not an easy problem), we should be clear about the gap in the system and the potential risks it entails. It is important to note that while the server authentication checks can validate a specific hostname, it is certainly possible for the API server to present a valid certificate for a hostname that uses non-standard characters or is otherwise designed to trick the user into believing that its hostname is some other, more trustworthy, name. This is a danger of any scenario in which a hostname is not typed in by a user. Do we want to reference any of the PRECIS stuff (RFC 7564/etc.)? Section 7.1 Information passed between a client and a Captive Portal system may include a user's personal information, such as a full name and credit card details. Therefore, it is important that Captive Portal API Servers do not allow access to the Captive Portal API over unencrypted sessions. While I support this requirement, it seems like the personal information exchange is more likely to occur between client and Captive Portal Server than between client and Captive Portal API Server. Protecting the exchange with the API server is still important, though, to make sure that the client talks to the right Captive Portal Server! Section 8.2 New assignments for Captive Portal API Keys Registry will be administered by IANA using the Specification Required policy [RFC8126]. The Designated Expert is expected to validate the existence of documentation describing new keys in a permanent publicly available specification. The expert is expected to validate Does an I-D that is never published as an RFC meet this bar? that new keys have a clear meaning and do not create unnecessary confusion or overlap with existing keys. Keys that are specific to I trust that this includes "matches an existing key name using a case-insensitive comparison". _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals