Skip to main content

Captive Portal API
RFC 8908

Revision differences

Document history

Date Rev. By Action
2020-12-17
08 (System) Removed an unintended duplicate version of the opsdir lc review
2020-09-23
08 (System) IANA registries were updated to include RFC8908
2020-09-21
08 (System)
Received changes through RFC Editor sync (created alias RFC 8908, changed abstract to 'This document describes an HTTP API that allows clients to interact …
Received changes through RFC Editor sync (created alias RFC 8908, changed abstract to '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.', changed pages to 11, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-09-21, changed IESG state to RFC Published)
2020-09-21
08 (System) RFC published
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