Captive Portal API
draft-ietf-capport-api-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-09-18
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-09-03
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-07-13
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-07-07
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-07-07
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-07-07
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-07-07
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-07-02
|
08 | (System) | RFC Editor state changed to EDIT |
2020-07-02
|
08 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-07-02
|
08 | (System) | Announcement was received by RFC Editor |
2020-07-02
|
08 | (System) | IANA Action state changed to In Progress |
2020-07-02
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-07-02
|
08 | Amy Vezza | IESG has approved the document |
2020-07-02
|
08 | Amy Vezza | Closed "Approve" ballot |
2020-07-02
|
08 | Amy Vezza | Ballot approval text was generated |
2020-07-01
|
08 | Barry Leiba | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-06-22
|
08 | Magnus Westerlund | [Ballot comment] Thanks for discussion and resolving my issue. |
2020-06-22
|
08 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss |
2020-06-19
|
08 | Roman Danyliw | [Ballot comment] Thanks for addressing my DISCUSS and COMMENT points. |
2020-06-19
|
08 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-06-18
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-06-18
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-06-18
|
08 | Tommy Pauly | New version available: draft-ietf-capport-api-08.txt |
2020-06-18
|
08 | (System) | New version accepted (logged-in submitter: Tommy Pauly) |
2020-06-18
|
08 | Tommy Pauly | Uploaded new revision |
2020-06-11
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-06-11
|
07 | Magnus Westerlund | [Ballot discuss] Section 4.1: The API server endpoint MUST be accessed using HTTP over TLS (HTTPS) and SHOULD be served on port 443 … [Ballot discuss] Section 4.1: The API server endpoint MUST be accessed using HTTP over TLS (HTTPS) and SHOULD be served on port 443 [RFC2818]. I have another reason than Roman to discuss this particular sentence. First of all what is the intention of which HTTP version should be supported here? And which protocol are the port 443 you are recommending, TCP, UDP or SCTP? This also relates to HTTP/3 as it is getting close to being published, we can expect that in the future maybe people would like to upgrade to HTTP/3. Already now I am wondering if the written allow for HTTP/2 over TLS/TCP? Note, that I am mostly commenting from the perspective if you want to be specific that it is HTTP/1.1. over TLS/TCP that is the goal. Then this document should make certain changes in the formulation. If you want to be unspecific and don't think that will hurt interoperability, then another formulation that the current is also needed. Likely also a discussion about how a client will figure out what versions are supported. And maybe one of the ART ADs can help untangle if RFC 2818 really is the right normative reference here? Or if it should be RFC 7230 and possibly additional references for HTTP/2? |
2020-06-11
|
07 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2020-06-11
|
07 | Robert Wilton | [Ballot comment] Hi, I found this document straight forward and easy to read. Linda's comment in the Opsdir review is interesting. I would have expected … [Ballot comment] Hi, I found this document straight forward and easy to read. Linda's comment in the Opsdir review is interesting. I would have expected the CAPPORT architecture document to discuss/reference the problem being solved, but it seems to be mostly silent on this. I will redirect Linda's comment to the CAPPORT architecture. In section 5. "API State Structure", it does not state whether a connection could be both time and data limited. My reading of the spec is that this would be allowed, assuming that is the case, the current text is fine. 6. Example Interaction Upon receiving this information the client will use this information direct the user to the the web portal (as specified by the user- portal-url value) to enable access to the external network. Once the user satisfies the requirements for extenal network access, the client SHOULD query the API server again to verify that it is no longer captive. Nit: information direct => information to direct 7. Security Considerations I'm slightly concerned about the third paragraph in the security considerations. Ideally I would like a solution that doesn't require humans to potentially spot potentially dubious spoofed domain names. But I can appreciate that is probably out of scope here. 7.1. Privacy Considerations Possibly worth adding a comment about the necessity to keep personal information secure. In addition, should there be any comments about GDPR like constraints (if they apply)? Thanks, Rob |
2020-06-11
|
07 | Robert Wilton | Ballot comment text updated for Robert Wilton |
2020-06-11
|
07 | Robert Wilton | [Ballot comment] Hi, I found this document straight forward and easy to read. In section 5. "API State Structure", it does not state whether a … [Ballot comment] Hi, I found this document straight forward and easy to read. In section 5. "API State Structure", it does not state whether a connection could be both time and data limited. My reading of the spec is that this would be allowed, assuming that is the case, the current text is fine. 6. Example Interaction Upon receiving this information the client will use this information direct the user to the the web portal (as specified by the user- portal-url value) to enable access to the external network. Once the user satisfies the requirements for extenal network access, the client SHOULD query the API server again to verify that it is no longer captive. Nit: information direct => information to direct 7. Security Considerations I'm slightly concerned about the third paragraph in the security considerations. Ideally I would like a solution that doesn't require humans to potentially spot potentially dubious spoofed domain names. But I can appreciate that is probably out of scope here. 7.1. Privacy Considerations Possibly worth adding a comment about the necessity to keep personal information secure. In addition, should there be any comments about GDPR like constraints (if they apply)? Thanks, Rob |
2020-06-11
|
07 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-06-11
|
07 | Erik Kline | [Ballot Position Update] New position, Recuse, has been recorded for Erik Kline |
2020-06-10
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-06-09
|
07 | Roman Danyliw | [Ballot discuss] “Discuss discuss”. Section 4 says “The API server endpoint MUST be accessed using HTTP over TLS (HTTPS) and SHOULD be served on port … [Ballot discuss] “Discuss discuss”. Section 4 says “The API server endpoint MUST be accessed using HTTP over TLS (HTTPS) and SHOULD be served on port 443 [RFC2818].” There is also various guidance on verifying the API server identity and access to revocation and time resources. However, the way I read the definition of the “Captive Portal API Server” per Section 2 and per Figure 1 of draft-ietf-capport-architecture, the API server is logically different than the service at the user-portal-url URL (i.e., Web Portal Server in the architecture). Section 7.1 helpfully points out “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.” The first sentence is makes sense, but the second, while true, doesn’t follow the first for me. PII and credit card information would be the kind of input you would provide to the _Web Portal Server_ not the Captive Portal API (of course both are part of the overall Captive Portal system). I feel there is missing guidance roughly on the order of the user-portal-url “provides the URL of a web portal _that MUST be accessed over TLS_ with which a user can interact.” (and the venue-info-url SHOULD use TLS too). Both this draft and draft-ietf-capport-rfc7710bis-07 are fundamentally providing pointers to other resources. Would it be out of scope for this document to place restrictions on what the API is capable of pointing to? If not here, then where? |
2020-06-09
|
07 | Roman Danyliw | [Ballot comment] Thanks for describing the protocol interaction within the reference architecture of draft-ietf-capport-architecture. ** Ben points to a few places to tighten up the … [Ballot comment] Thanks for describing the protocol interaction within the reference architecture of draft-ietf-capport-architecture. ** Ben points to a few places to tighten up the TLS mechanics (e.g., referencing BCP195, non-OCSP stapling revocation) which I won't repeat here. These are important. ** Are there any retry behavior to specify for the client? Say the client tries to the visit the API URL and the server returns an HTTP 500 error? Or, the API server doesn’t respond at all? ** Editorial Nits -- Section 4.1. Typo. s/mechnism/mechanisms/ -- Section 6. Typo. s/the the/the/ -- Section 6. Typo. s/extenal/external/ |
2020-06-09
|
07 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-06-09
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-06-09
|
07 | Benjamin Kaduk | [Ballot 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 … [Ballot 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". |
2020-06-09
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-06-08
|
07 | Martin Duke | [Ballot comment] This document is clearly written. Thanks. I am also confused by this sentence at the end of section 4.1 about failed authentication: “It … [Ballot comment] This document is clearly written. Thanks. I am also confused by this sentence at the end of section 4.1 about failed authentication: “It may still be possible for the user to access the network by being redirected to a web portal.” I suggest “...access the network by redirecting a clear text webpage to a web portal.” I was a bit confused by the original wording. As I said in the architecture review, the term for the user portal keeps changing. Over there it’s called a “Captive Portal Server” and a “web portal server”. Here it’s a “user-portal.” The authors of the two docs should get together and agree on a term. One nit: s/extenal/external |
2020-06-08
|
07 | Martin Duke | [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss |
2020-06-07
|
07 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. The document is easy to read and the content is useful. Special thanks to … [Ballot comment] Thank you for the work put into this document. The document is easy to read and the content is useful. Special thanks to the document shepherd, Martin Thomson, for describing the consensus within the WG. Please find below a couple on non-blocking COMMENTs and some NITs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2 -- While I understand that most captive portals are currently for human beings, I still find the "User Equipment" terminology restrictive for potential devices where the users never interact with (think IoT or health devices or ...). I suggest to rewrite this part. -- Section 4 -- In "client's IP address" (singular address), is a dual-stack (IPv6/IPv4) client covered? Or should this client use the API both over IPv4 and IPv6 ? -- Section 5 -- I suggest to clarify "bytes-remaining" to specify whether the IP header is included in the count. == NITS == -- Section 1 -- Just wondering whether the TLS part is a part of the API rather than a means. -- Section 6 -- Suggestion: mention that "/captive-portal/api/X54PD" was discovered before as in section 4. s/extenal network access/external network access/ |
2020-06-07
|
07 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2020-06-07
|
07 | Éric Vyncke | Request closed, assignment withdrawn: Donald Eastlake Telechat INTDIR review |
2020-06-07
|
07 | Éric Vyncke | Closed request for Telechat review by INTDIR with state 'Withdrawn': No need anymore to review, I have done my own review. |
2020-06-06
|
07 | Martin Duke | [Ballot discuss] Unless I am misinterpreting the language here, there is a disconnect between this document and the architecture document. Sec 2.3 of -architecture says: … [Ballot discuss] Unless I am misinterpreting the language here, there is a disconnect between this document and the architecture document. Sec 2.3 of -architecture says: At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server. But in section 5 user-portal-url is an optional field. Is -architecture actually levying a requirement on the api spec, or the api server? I am also confused by this sentence at the end of section 4.1 about failed authentication: “It may still be possible for the user to access the network by being redirected to a web portal.” Who is doing the redirecting here? If authentication has failed, how is this redirect authenticated and secure against theft of credentials? |
2020-06-06
|
07 | Martin Duke | [Ballot comment] This document is otherwise clearly written. Thanks. As I said in the architecture review, the term for the user portal keeps changing. Over … [Ballot comment] This document is otherwise clearly written. Thanks. As I said in the architecture review, the term for the user portal keeps changing. Over there it’s called a “Captive Portal Server” and a “web portal server”. Here it’s a “user-portal.” One nit: s/extenal/external |
2020-06-06
|
07 | Martin Duke | [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke |
2020-05-13
|
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2020-05-13
|
07 | Murray Kucherawy | [Ballot comment] Nice work. A couple of points on the IANA registrations: Section 8.1: The "Interoperability Considerations" text isn't quite what I think is anticipated … [Ballot comment] Nice work. A couple of points on the IANA registrations: Section 8.1: The "Interoperability Considerations" text isn't quite what I think is anticipated by RFC 6838. Given what you're saying there against what Section 6.2 of that document says, I think you could just have "None" here, but either way I suggest it's worth a second look. Section 8.2: I suggest either having a column dedicated to recording the specification (since the Designated Expert is supposed to ensure there is one), or explicitly encourage that it be referenced in the Description column. |
2020-05-13
|
07 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-05-12
|
07 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Donald Eastlake |
2020-05-12
|
07 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Donald Eastlake |
2020-05-11
|
07 | Barry Leiba | Telechat date has been changed to 2020-06-11 from 2020-05-21 |
2020-05-11
|
07 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-05-11
|
07 | Amy Vezza | Placed on agenda for telechat - 2020-05-21 |
2020-05-11
|
07 | Barry Leiba | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2020-05-11
|
07 | Barry Leiba | Ballot has been issued |
2020-05-11
|
07 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2020-05-11
|
07 | Barry Leiba | Created "Approve" ballot |
2020-05-11
|
07 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2020-05-09
|
07 | Linda Dunbar | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Linda Dunbar. Sent review to list. |
2020-05-08
|
07 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-05-08
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-capport-api-07. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-capport-api-07. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the application registry on the Media Type registry page located at: https://www.iana.org/assignments/media-types/ a new registration will be made as follows: Name: captive+json Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] Second, a new registry is to be created called the Captive Portal API Keys registry. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? The new registry is to be managed via Specification Required as defined in RFC8126. There are initial registrations in the new registry as follows: Key: captive Type: boolean Description: Indicates whether the client is in a state of captivity, i.e it has not satisfied the conditions to access the external network. If the client is captive (i.e. captive=true), it can still be allowed enough access for it to perform server authentication [ RFC-to-be Section 4.1 ]. Reference: [ RFC-to-be ] Key: user-portal-url Type: string Description: Provides the URL of a web portal with which a user can interact. Reference: [ RFC-to-be ] Key: venue-info-url Type: string Description: provides the URL of a webpage or site on which the operator of the network has information that it wishes to share with the user (e.g., store info, maps, flight status, or entertainment). Reference: [ RFC-to-be ] Key: can-extend-session Type: boolean Description: Indicates that the URL specified as "user-portal-url" allows the user to extend a session once the client is no longer in a state of captivity. This provides a hint that a client system can suggest accessing the portal URL to the user when the session is near its limit in terms of time or bytes. Reference: [ RFC-to-be ] Key: seconds-remaining Type: integer Description: Indicates the number of seconds remaining, after which the client will be placed into a captive state. The API server SHOULD include this value if the client is not captive (i.e. captive=false) and the client session is time-limited, and SHOULD omit this value for captive clients (i.e. captive=true) or when the session is not time-limited. Reference: [ RFC-to-be ] Key: bytes-remaining Type: integer Description: Indicates the number of bytes remaining, after which the client will be in placed into a captive state. The byte count represents the sum of the total number of IP packet (layer 3) bytes sent and received by the client. Captive portal systems might not count traffic to whitelisted servers, such as the API server, but clients cannot rely on such behavior. The API server SHOULD include this value if the client is not captive (i.e. captive=false) and the client session is byte-limited, and SHOULD omit this value for captive clients (i.e. captive=true) or when the session is not byte-limited. Reference: [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-05-04
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2020-05-04
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2020-05-03
|
07 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Brian Carpenter. Sent review to list. |
2020-04-30
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2020-04-30
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2020-04-30
|
07 | Robert Sparks | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
2020-04-30
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Robert Sparks |
2020-04-30
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Robert Sparks |
2020-04-27
|
07 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-04-27
|
07 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-05-11): From: The IESG To: IETF-Announce CC: draft-ietf-capport-api@ietf.org, Martin Thomson , captive-portals@ietf.org, mt@lowentropy.net, … The following Last Call announcement was sent out (ends 2020-05-11): From: The IESG To: IETF-Announce CC: draft-ietf-capport-api@ietf.org, Martin Thomson , captive-portals@ietf.org, mt@lowentropy.net, barryleiba@gmail.com, capport-chairs@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Captive Portal API) to Proposed Standard The IESG has received a request from the Captive Portal Interaction WG (capport) to consider the following document: - 'Captive Portal API' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-05-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an HTTP API that allows clients to interact 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-capport-api/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-capport-api/ballot/ No IPR declarations have been submitted directly on this I-D. |
2020-04-27
|
07 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-04-27
|
07 | Barry Leiba | Last call was requested |
2020-04-27
|
07 | Barry Leiba | Last call announcement was generated |
2020-04-27
|
07 | Barry Leiba | Ballot approval text was generated |
2020-04-27
|
07 | Barry Leiba | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-04-27
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-04-27
|
07 | Tommy Pauly | New version available: draft-ietf-capport-api-07.txt |
2020-04-27
|
07 | (System) | New version accepted (logged-in submitter: Tommy Pauly) |
2020-04-27
|
07 | Tommy Pauly | Uploaded new revision |
2020-04-23
|
06 | Barry Leiba | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2020-04-21
|
06 | Barry Leiba | Ballot writeup was changed |
2020-04-21
|
06 | Barry Leiba | IESG state changed to AD Evaluation from Publication Requested |
2020-04-20
|
06 | Martin Thomson | Publication request writeup for draft-ietf-capport-api-06 Intended status: Proposed Standard Working group: capport Document shepherd: Martin Thomson Technical Summary: This document defines a simple HTTP API … Publication request writeup for draft-ietf-capport-api-06 Intended status: Proposed Standard Working group: capport Document shepherd: Martin Thomson Technical Summary: This document defines a simple HTTP API that allows a network to provide information about captive portal status. Working Group Summary: This document was at times controversial in discussions. Some participants felt that the potential for an API of this form to be spoofed was a problem. Some participants felt that this particular design was especially hard for network operators to deploy due to some of the inherent complexities in deployments. Some participants felt that it would be necessary to include more detailed information, such as what sites were accessible and what sites were not. At times there were communication difficulties in the working group that exacerbated problems. However, as a baseline set of features, both clients and networks have demonstrated agreement that the current shape of this document is acceptable. Document Quality: The document is short and concise and of high quality. The fields that are defined are all driven by real client requirements and implementation experience in multiple implementations. We have experience with deploying this on the IETF network. Personnel: Martin Thomson is document shepherd. Barry Leiba is the responsible Area Director. Important information: This document represents the consensus of the capport WG. There were some contentious issues, but there is consensus within the working group to publish. IPR disclosures from authors have been checked. No IPR disclosures have been made with reference to this work. IANA considerations were checked. There is a new registry for this API, which will need an expert assigned. The document registers a media type, and mail has been sent to media-types@ietf.org to solicit a preliminary review. Validation is limited to nits check (which only has false positives). |
2020-04-20
|
06 | Martin Thomson | Responsible AD changed to Barry Leiba |
2020-04-20
|
06 | Martin Thomson | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2020-04-20
|
06 | Martin Thomson | IESG state changed to Publication Requested from I-D Exists |
2020-04-20
|
06 | Martin Thomson | IESG process started in state Publication Requested |
2020-04-20
|
06 | Martin Thomson | Publication request writeup for draft-ietf-capport-api-06 Intended status: Proposed Standard Working group: capport Document shepherd: Martin Thomson Technical Summary: This document defines a simple HTTP API … Publication request writeup for draft-ietf-capport-api-06 Intended status: Proposed Standard Working group: capport Document shepherd: Martin Thomson Technical Summary: This document defines a simple HTTP API that allows a network to provide information about captive portal status. Working Group Summary: This document was at times controversial in discussions. Some participants felt that the potential for an API of this form to be spoofed was a problem. Some participants felt that this particular design was especially hard for network operators to deploy due to some of the inherent complexities in deployments. Some participants felt that it would be necessary to include more detailed information, such as what sites were accessible and what sites were not. At times there were communication difficulties in the working group that exacerbated problems. However, as a baseline set of features, both clients and networks have demonstrated agreement that the current shape of this document is acceptable. Document Quality: The document is short and concise and of high quality. The fields that are defined are all driven by real client requirements and implementation experience in multiple implementations. We have experience with deploying this on the IETF network. Personnel: Martin Thomson is document shepherd. Barry Leiba is the responsible Area Director. Important information: This document represents the consensus of the capport WG. There were some contentious issues, but there is consensus within the working group to publish. IPR disclosures from authors have been checked. No IPR disclosures have been made with reference to this work. IANA considerations were checked. There is a new registry for this API, which will need an expert assigned. The document registers a media type, and mail has been sent to media-types@ietf.org to solicit a preliminary review. Validation is limited to nits check (which only has false positives). |
2020-04-20
|
06 | Martin Thomson | Publication request writeup for draft-ietf-capport-architecture-07 Intended status: Informational Working group: capport Document shepherd: Martin Thomson Technical Summary: This document defines terminology related to the operation … Publication request writeup for draft-ietf-capport-architecture-07 Intended status: Informational Working group: capport Document shepherd: Martin Thomson Technical Summary: This document defines terminology related to the operation of a captive portal. Using those terms, it then defines how a network that deploys a captive portal should work. Working Group Summary: This document was difficult to reach consensus on. The complexity of the architecture here is reflective of a far greater complexity in practice of deployment. More contentious in discussion was the question of what signals from the network would be provided and what clients might do in response to those signals. The hard reality of the situation is that clients will be forced to use the existing heuristics they use, likely indefinitely, even when the mechanisms we define are in relatively wide deployment. A particularly difficult discussion was the option for a network to signal that conditions have changed. There was considerable discussion about the security properties of unsolicited signals from the network, how that related to the identification of endpoints (or User Equipment to use the terminology here), and how these signals might be turned to malicious ends. In the end, we decided to document requirements for how User Equipment is identified and how to avoid identifier spoofing. A high-level design and security requirements for a signal from the network about changed conditions was also documented, but no mechanism that met these requirements was proposed and the working group decided to proceed to publication without a specific mechanism. Document Quality: This document has not had a whole lot of attention from editors over time, and editors have changed. This shows in some editorial aspects of the document, but aside from a few areas in which things like terminology are inconsistently capitalized, the document is in good shape. The current editors have made some significant improvements. Personnel: Martin Thomson is document shepherd. Barry Leiba is the responsible Area Director. Important information: This document represents the consensus of the capport WG. The above summarizes some of the challenges overcome. There were a few occasions where this consensus was a little rocky though. This document has no special requirement for review and so has received limited external review. IPR disclosures from authors have been checked. No IPR disclosures have been made with reference to this work. No request is made of IANA. Validation is limited to nits check (which only reported false positives). |
2020-03-31
|
06 | Martin Thomson | Changed consensus to Yes from Unknown |
2020-03-31
|
06 | Martin Thomson | Intended Status changed to Proposed Standard from None |
2020-03-31
|
06 | Martin Thomson | Notification list changed to Martin Thomson <mt@lowentropy.net> |
2020-03-31
|
06 | Martin Thomson | Document shepherd changed to Martin Thomson |
2020-03-31
|
06 | Tommy Pauly | New version available: draft-ietf-capport-api-06.txt |
2020-03-31
|
06 | (System) | New version approved |
2020-03-31
|
06 | (System) | Request for posting confirmation emailed to previous authors: Darshak Thakore , Tommy Pauly |
2020-03-31
|
06 | Tommy Pauly | Uploaded new revision |
2020-03-31
|
06 | Tommy Pauly | Uploaded new revision |
2020-02-04
|
05 | Tommy Pauly | New version available: draft-ietf-capport-api-05.txt |
2020-02-04
|
05 | (System) | New version approved |
2020-02-04
|
05 | (System) | Request for posting confirmation emailed to previous authors: Tommy Pauly , Darshak Thakore |
2020-02-04
|
05 | Tommy Pauly | Uploaded new revision |
2020-02-04
|
05 | Tommy Pauly | Uploaded new revision |
2020-01-02
|
04 | Tommy Pauly | New version available: draft-ietf-capport-api-04.txt |
2020-01-02
|
04 | (System) | New version approved |
2020-01-02
|
04 | (System) | Request for posting confirmation emailed to previous authors: Tommy Pauly , Darshak Thakore |
2020-01-02
|
04 | Tommy Pauly | Uploaded new revision |
2020-01-02
|
04 | Tommy Pauly | Uploaded new revision |
2019-07-14
|
03 | Martin Thomson | Added to session: IETF-105: capport Mon-1000 |
2019-07-06
|
03 | Tommy Pauly | New version available: draft-ietf-capport-api-03.txt |
2019-07-06
|
03 | (System) | New version approved |
2019-07-06
|
03 | (System) | Request for posting confirmation emailed to previous authors: Tommy Pauly , Darshak Thakore |
2019-07-06
|
03 | Tommy Pauly | Uploaded new revision |
2019-03-11
|
02 | Tommy Pauly | New version available: draft-ietf-capport-api-02.txt |
2019-03-11
|
02 | (System) | New version approved |
2019-03-11
|
02 | (System) | Request for posting confirmation emailed to previous authors: Tommy Pauly , Darshak Thakore |
2019-03-11
|
02 | Tommy Pauly | Uploaded new revision |
2019-01-02
|
01 | (System) | Document has expired |
2018-07-01
|
01 | Darshak Thakore | New version available: draft-ietf-capport-api-01.txt |
2018-07-01
|
01 | (System) | New version approved |
2018-07-01
|
01 | (System) | Request for posting confirmation emailed to previous authors: Tommy Pauly , Darshak Thakore |
2018-07-01
|
01 | Darshak Thakore | Uploaded new revision |
2018-07-01
|
01 | Darshak Thakore | Uploaded new revision |
2018-02-04
|
00 | Darshak Thakore | New version available: draft-ietf-capport-api-00.txt |
2018-02-04
|
00 | (System) | WG -00 approved |
2018-02-02
|
00 | Darshak Thakore | Set submitter to "Darshak Thakore " and sent approval email to group chairs: capport-chairs@ietf.org |
2018-02-02
|
00 | Darshak Thakore | Uploaded new revision |