authenticating to, and interacting with the captive portal is out of scope of this document.  [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis.  The most recent version of the document, open issues, etc should all be available here.  The 1. In many environments, users need to connect to a captive-portal <del> server and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  It is anticipated that the IETF will work on a more fully featured protocol at some point, to ease interaction with Captive Portals.  Regardless of how that protocol operates, it is expected that this document will provide needed functionality because the client will need to know when it is behind a captive portal and how to contact it. </del>  In order to present users with the payment or AUP pages, presently a captive-portal enforcement device has to intercept the user's The format of the IPv4 Captive-Portal DHCP option is shown below. <del> Code: The Captive-Portal DHCPv4 Option (160) (one octet) </del>  Len: The length, in octets of the URI. be less likely to disable useful security safeguards like DNSSEC validation, VPNs, etc.  In addition, because the system knows that it is behind a captive portal, it can know not to send cookies, <del> credentials, etc.  By provisioning a URI using which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </del>

Forgot to make PR. This is the "good" one, should be abandoned...
Nope -- I think it is still TBD - we've asked / strongly suggested 114 in the IANA section, but I think it would feel presumptive to state that it is... W
I believe this should be changed to 114, or IANA-TBD.
Yikes, good catch. I changed it to TBD, and also added a sentence to the Abstract noting that it has changed from 160 to TBD (it seemed important enough). Thank you! W
NAME have changed or will change? I can't see this in the current version(s) of the draft here.
I swear I'd done this, and event sent a PR, but I cannot find it.... so, just made a new one...
I had created the branch, and made the edits, but apparently forgot to make the PR.... and then, because I couldn't find it, I made a new branch, change and PR (), and then realized the original was better, so I removed PR and created ... Oy vey, W
Done, had forgotten to close...
Should the TBDs be 114? Either that, or the list of changes should be TBD as well?

authenticating to, and interacting with the captive portal is out of scope of this document. <ins> RFC7710 used DHCP code point 160.  Due to a conflict, this document specifies TBD. </ins> [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis.  The most recent version of the document, open issues, etc should all be available here.  The 1. In many environments, users need to connect to a captive-portal  <ins> device and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  Regardless of how that mechanism operates, this document provides functionality to allow the client to know when it is behind a captive portal and how to contact it. </ins> In order to present users with the payment or AUP pages, presently a captive-portal enforcement device has to intercept the user's The format of the IPv4 Captive-Portal DHCP option is shown below.  <ins> Code: The Captive-Portal DHCPv4 Option (TBD) (one octet) </ins> Len: The length, in octets of the URI. be less likely to disable useful security safeguards like DNSSEC validation, VPNs, etc.  In addition, because the system knows that it is behind a captive portal, it can know not to send cookies,  <ins> credentials, etc.  By handing out a URI which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </ins>


1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del>  2.

— Section 1.1 — Please use the new BCP 14 boilerplate from RFC 8174.

1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",  <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.


3. A device may learn about Captive Portal API URIs through more than <del> one of (or indeed all of) the above options.  It is a network configuration error if the learned URIs are not all identical. However, if the URIs learned are not in fact all identical the captive device MUST prioritize URIs learned from network provisioning or configuration mechanisms before all other URIs.  Specifically, URIs learned via any of the options in option should take precedence over any URI learned via some other mechanism, such as a redirect. </del>  If the URIs learned via more than one option described in option are not all identical, this condition should be logged for the device <del> owner or administrator.  Implementations can select their own precedence order. </del>  4.

""" — Section 3 — Specifically, URIs learned via any of the options in Section 2 should take precedence over any URI learned via some other mechanism Given the MUST that comes before this, I think the word “should” ought to be removed, to avoid any confusion. """ Actually, this text is left over from the brief period of time when there was an HTTP redirect Link-Relation header. That option was removed, and I think the 2nd paragraph can be deleted. The 1st and 3rd paragraphs can probably be reworked into two much tighter paragraphs.

3. A device may learn about Captive Portal API URIs through more than  <ins> one of (or indeed all of) the above options.  Implementations can select their own precedence order (e.g., prefer one of the IPv6 options before the DHCPv4 option, or vice versa, et cetera). </ins> If the URIs learned via more than one option described in option are not all identical, this condition should be logged for the device  <ins> owner or administrator; it is a network configuration error if the learned URIs are not all identical. </ins> 4.


request. In order to support multiple "classes" of clients (e.g.  IPv4 only, <del> IPv6 only with DHCPv6 (RFC3315), and IPv6 only with RA) the captive </del>  network can provision the client with the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, and IPv6 RA).  The captive portal operator SHOULD ensure that the URIs provisioned by each method are equivalent to reduce the chance of operational problems.  The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer <del> than 255 bytes should not be provisioned via IPv6 DHCP or IPv6 RA either. </del>  In all variants of this option, the URI MUST be that of the captive portal API endpoint, conforming to the recommendations for such URIs Code: The Captive-Portal DHCPv4 Option (TBD) (one octet) <del> Len: The length, in octets of the URI. </del>  URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986).  Note that the URI parameter is not null terminated. 2.2. option-code: The Captive-Portal DHCPv6Option (103) (two octets) <del> option-len: The length, in octets of the URI. </del>  URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986). See RFC7227, Section 5.7 for more examples of DHCP Options with URIs.  Note that the URI parameter is not null terminated.

Additionally: Update DHCPv6 reference from RFC 3315 to RFC 8415. Include reference to DHCPv6 option format text. Include reference to DHCPv4 option format text in RFC 2132. The DHCPv4 and v6 diagrams are not harmonized in this change. Each option format has sever documents using the style currently depicted. Issue:
""" — Sections 2.1 and 2.2 — Why aren’t the diagrams for the two in the same format? And neither explicitly says what the length of the “len” field is. In the v4 version, one has to guess that it’s the same size as the “code” field, 1 byte. In the v6 version, one can look at the diagram. I suggest making the diagrams the same format (calibrated with bit/byte markings) and explicitly specifying in the text the size of the “len” field. """ I rather suspect this goes back to whichever source documents from which the option format text was copied. Nevertheless, harmonizing them seems reasonable.
Additionally: we should restate the 255 byte limit from DHCPv4 in each option's description.

request. In order to support multiple "classes" of clients (e.g.  IPv4 only,  <ins> IPv6 only with DHCPv6 (RFC8415), and IPv6 only with RA) the captive </ins> network can provision the client with the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, and IPv6 RA).  The captive portal operator SHOULD ensure that the URIs provisioned by each method are equivalent to reduce the chance of operational problems.  The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer  <ins> than 255 bytes should not be provisioned via IPv6 DHCP nor IPv6 RA options. </ins> In all variants of this option, the URI MUST be that of the captive portal API endpoint, conforming to the recommendations for such URIs Code: The Captive-Portal DHCPv4 Option (TBD) (one octet)  <ins> Len: The length (one octet), in octets of the URI. </ins> URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986). <ins> See RFC2132, Section 2 for more on the format of IPv4 DHCP options. </ins> Note that the URI parameter is not null terminated. 2.2. option-code: The Captive-Portal DHCPv6Option (103) (two octets)  <ins> option-len: The unsigned 16-bit length, in octets, of the URI. </ins> URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986). See RFC7227, Section 5.7 for more examples of DHCP Options with URIs. <ins> See RFC8415, Section 21.1 for more on the format of IPv6 DHCP options. </ins> Note that the URI parameter is not null terminated.


portal API endpoint, conforming to the recommendations for such URIs [draft-ietf-capport-api]. <del> A captive portal server MAY redirect requests that do not have an Accept header field (RFC7231 Section 5.3) containing a field item whose content-type is "application/capport+json" to the URL conveyed in the "user-portal-url" API key.  When performing such content negotiation (RFC7231 Section 3.4), implementors of captive portals need to keep in mind that such responses might be cached, and therefore SHOULD include an appropriate Vary header field (RFC7231 Section 7.1.4) or mark them explicitly uncacheable (for example, using Cache-Control: no-store RFC7234 Section 5.2.2.3). </del> A captive portal MAY do content negotiation (RFC7231 section 3.4) and attempt to redirect clients querying without an explicit indication of support for the captive portal API content type (i.e. without application/capport+json listed explicitly anywhere within an Accept header vis.  RFC7231 section 5.3).  In so doing, the captive portal SHOULD redirect the client to the value associated with the "user- <del> portal-url" API key. </del>  The URI SHOULD NOT contain an IP address literal.

""" It looks like the two consecutive paragraphs that both begin with “A captive portal” have some duplication with regard to the absence of “Accept” headers; please check that and adjust if you agree that some information can be merged or removed. """ Indeed, these paragraphs seem to be saying almost the exact same thing. I think the 2nd paragraph can be removed, once it's clear whether/how to move its SHOULD to the 1st paragraph.
A bunch of unrelated changes :)

portal API endpoint, conforming to the recommendations for such URIs [draft-ietf-capport-api].  A captive portal MAY do content negotiation (RFC7231 section 3.4) and attempt to redirect clients querying without an explicit indication of support for the captive portal API content type (i.e. without application/capport+json listed explicitly anywhere within an Accept header vis.  RFC7231 section 5.3).  In so doing, the captive portal SHOULD redirect the client to the value associated with the "user-  <ins> portal-url" API key.  When performing such content negotiation (RFC7231 Section 3.4), implementors of captive portals need to keep in mind that such responses might be cached, and therefore SHOULD include an appropriate Vary header field (RFC7231 Section 7.1.4) or mark them explicitly uncacheable (for example, using Cache-Control: no-store RFC7234 Section 5.2.2.3). </ins> The URI SHOULD NOT contain an IP address literal.


mark them explicitly uncacheable (for example, using Cache-Control: no-store RFC7234 Section 5.2.2.3). <del> The URI SHOULD NOT contain an IP address literal. </del>  Networks with no captive portals MAY explicitly indicate this condition by using this option with the IANA-assigned URI for this

Approved -- discussed on phone...
""" The URI SHOULD NOT contain an IP address literal. Why not, and how does it maintain interoperability to have this as SHOULD NOT, rather than MUST NOT? """
My recollection (possibly faulty), is that we could have made this a MUST NOT in large part because we want the URI to be identical across IPv4 and IPv6 -based options, but that going from SHOULD NOT to MUST NOT could be over-prescriptive. Is my recollection correct, and would such a move be over-prescriptive?
That is right. It is also somewhat more challenging to get a valid certificate for an IP address than a domain name.

mark them explicitly uncacheable (for example, using Cache-Control: no-store RFC7234 Section 5.2.2.3).  <ins> The URI SHOULD NOT contain an IP address literal.  Exceptions to this might include networks with only one operational IP address family where DNS is either not available or not fully functional until the captive portal has been satisfied. </ins> Networks with no captive portals MAY explicitly indicate this condition by using this option with the IANA-assigned URI for this


Note that the URI parameter is not null terminated.  2.3. This section describes the Captive-Portal Router Advertisement Note that the URI parameter is not guaranteed to be null terminated.  3. A device may learn about Captive Portal API URIs through more than

Additionally, clarify recommended URI limit of 255 in each of DHCPv6 and IPv6 RA option description text.
Approved (text crafted on phone). The duplication of the warning length is intentional....
""" — Sections 2.1 and 2.2 — Why aren’t the diagrams for the two in the same format? And neither explicitly says what the length of the “len” field is. In the v4 version, one has to guess that it’s the same size as the “code” field, 1 byte. In the v6 version, one can look at the diagram. I suggest making the diagrams the same format (calibrated with bit/byte markings) and explicitly specifying in the text the size of the “len” field. """ I rather suspect this goes back to whichever source documents from which the option format text was copied. Nevertheless, harmonizing them seems reasonable.
Additionally: we should restate the 255 byte limit from DHCPv4 in each option's description.

Note that the URI parameter is not null terminated. <ins> The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be provisioned via IPv6 DHCP options. </ins> 2.3. This section describes the Captive-Portal Router Advertisement Note that the URI parameter is not guaranteed to be null terminated. <ins> The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be provisioned via IPv6 RA options. </ins> 3. A device may learn about Captive Portal API URIs through more than


5.  An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of his choosing.  As an attacker with this capability could expectations of being hijacked - this may improve security by making users more reluctant to accept TLS hijacking, which can be performed from beyond the network associated with the captive portal. <del> By simplifying the interaction with the captive portal systems, and doing away with the need for interception, we think that users will be less likely to disable useful security safeguards like DNSSEC validation, VPNs, etc.  In addition, because the system knows that it is behind a captive portal, it can know not to send cookies, credentials, etc.  By handing out a URI which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </del>

""" — Section 5 — Purely a judgment thing here, so do what you hink is best: it seems to me that the Security Considerations in 7710 rather buried the lede. The bottom line is that by removing the MitM interception, this mechanism improves security by making the portal and its actions visible, rather than hidden, and that vulnerabilities that exist here also existed before and are now lessened. I would say something like that up front, in a new first paragraph, and then continue with the existing text as is. But, again, as you judge best; this is just a comment. """

5. <ins> By removing or reducing the need for captive portals to perform MITM hijacking, this mechanism improves security by making the portal and its actions visible, rather than hidden, and reduces the likelihood that users will disable useful security safeguards like DNSSEC validation, VPNs, etc.  In addition, because the system knows that it is behind a captive portal, it can know not to send cookies, credentials, etc.  By handing out a URI which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </ins> An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of his choosing.  As an attacker with this capability could expectations of being hijacked - this may improve security by making users more reluctant to accept TLS hijacking, which can be performed from beyond the network associated with the captive portal.


the captive portal operator can attempt to reassure the user that the captive portal is not malicious.  An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of his choosing.  As an attacker with this capability could <del> simply list himself as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more capabilities, but because this document removes the need for </del>  interception, the attacker may have an easier time performing the <del> attack.  As the operating systems and application that make use of </del>  this information know that they are connecting to a captive-portal device (as opposed to intercepted connections) they can render the page in a sandboxed environment and take other precautions, such as

Thread: URL
Perhaps a reference to URL as well as the security considerations sections of 2131, 4861, 4862, and 8415.
The new paragraph is good. The other sentence is a little hard to understand and risks opening questions that we probably don't want opened. Reviewer: Rifaat Shekh-Yusef Review result: Has Issues Since the use of IP address literal is not forbidden by this document, what if an attacker with the ability to inject DHCP messages or RAs uses this option to force the user to contact an IP address of his choosing? In this case, the use of TLS and presenting the identity in the certificate might not be of much help. I think this case should be discussed in the security consideration section.

the captive portal operator can attempt to reassure the user that the captive portal is not malicious. <ins> Each of the options described in this document is presented to a node using the same protocols used to provision other information critical to the node's successful configuration on a network.  The security considerations applicable to each of these provisioning mechanisms also apply when the node is attempting to learn the information conveyed in these options.  In the absence of security measures like RA Guard (RFC6105, RFC7113) or DHCP Shield RFC7610, an attacker could inject, modify, or block DHCP messages or RAs. </ins> An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of his choosing.  As an attacker with this capability could  <ins> simply list themselves as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more capabilities, but because this document removes the need for </ins> interception, the attacker may have an easier time performing the  <ins> attack. However, as the operating systems and application that make use of </ins> this information know that they are connecting to a captive-portal device (as opposed to intercepted connections) they can render the page in a sandboxed environment and take other precautions, such as


4.1. This document registers a new entry under the IETF URN Sub-namespace <del> defined in RFC3553: </del>  <del> Captive Portal Unrestricted Identifier urn:ietf:params:capport:unrestricted </del>  RFC TBD (this document) <del> RFC TBD (this document) </del>  <del> Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </del>  4.2.

Looking at this now it's really not clear what I was thinking before. Fortunately, IANA folks are on top things. =)
""" First, Section 4.1 states that "This document registers a new entry under the IETF URN Sub-namespace defined in [RFC3553]" however, the registry at URL defined by RFC 3553 is actually the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry. In addition, neither registry's columns match the columns named in the registration. IANA Question --> The authors provide the following registration information in Section 4.1 of the draft: Registry name: Captive Portal Unrestricted Identifier URN: urn:ietf:params:capport:unrestricted Specification: RFC TBD (this document) Repository: RFC TBD (this document) Index value: Only one value is defined (see URN above). No hierarchy is defined and therefore no sub-namespace registrations are possible. The IETF URN Sub-namespaces registry records the following information: Sub-namespace Reference IANA Registry Reference And the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers provide the following information: Registered Parameter Identifier Reference IANA Registry Reference Is the registration information in Section 4.1 of the draft for a different registry; or, is the information provided different from the requirements for the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry? """
Per Barry: """ The way we'd normally do this sort of registration is to register "capport" in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry, and create a new registry (probably with Expert Review or Specification Required, but it also could be FCFS) for "Captive Portal URN Labels" or some name like that, and that registry would have "unrestricted" in it, resulting in the full URN we want. The "Captive Portal URN Labels" registry would be the IANA Registry Reference for the first registration. """ I propose we go for the Fully Monty registration.
Given recent discussion that capport:unrestricted may be fine on its own I will close this (again) for now.

4.1. This document registers a new entry under the IETF URN Sub-namespace  <ins> for Registered Protocol Parameter Identifiers defined in RFC3553: </ins>  <ins> capport:unrestricted </ins> RFC TBD (this document)  <ins> https://www.iana.org/assignments/params/params.xml#params-1 </ins>  <ins> Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </ins> 4.2.


Captive-Portal Identification in DHCP / RA <del> draft-ietf-capport-rfc7710bis-09 </del>  Abstract information faster and more reliably.  Note that, for the foreseeable future, captive portals will still need to implement interception techniques to serve legacy clients, and clients will need to perform <del> probing to detect captive portals. </del>  Clients that support the Captive Portal DHCP option SHOULD include the option in the Parameter Request List in DHCPREQUEST messages.

Ben suggested: "I was just thinking that if we have a whole sentence about how "you're going to have to do the old thing anyway, though", someone might read that and say "well, if I have to keep doing the old thing, why should I bother with this new thing". So, appending a "; nonetheless, the mechanism provided by this document provides a more reliable and performant way to do so, and is therefore the preferred mechanism for captive-portal detection" or similar is what I had in mind."
Will do, and just submit ('ain't nobody got time for nit PRs :-P)
Maybe de-hyphenate captive-portal

Captive-Portal Identification in DHCP / RA  <ins> draft-ietf-capport-rfc7710bis-10 </ins> Abstract information faster and more reliably.  Note that, for the foreseeable future, captive portals will still need to implement interception techniques to serve legacy clients, and clients will need to perform  <ins> probing to detect captive portals"; nonetheless, the mechanism provided by this document provides a more reliable and performant way to do so, and is therefore the preferred mechanism for captive-portal detection. </ins> Clients that support the Captive Portal DHCP option SHOULD include the option in the Parameter Request List in DHCPREQUEST messages.


In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode.  This highly restricts what the user can do <del> until the user has satified the Captive Portal conditions. </del>  This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some <del> sort of captive-portal enforcement device, and that they will need to </del>  satify the Captive Portal conditions to get Internet access.  It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a 1. <del> In many environments, users need to connect to a captive-portal </del>  device and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  Regardless of how that mechanism operates, this document provides functionality how to contact it. In order to present users with the payment or AUP pages, presently a <del> captive-portal enforcement device has to intercept the user's </del>  connections and redirect the user to a captive portal server, using methods that are very similar to man-in-the-middle (MITM) attacks. As increasing focus is placed on security, and end nodes adopt a more This document describes a DHCPv4 RFC2131 and DHCPv6 RFC8415 option (Captive-Portal) and an IPv6 Router Advertisement (RA) RFC4861 option <del> that informs clients that they are behind a captive-portal </del>  enforcement device and the API endpoint that the host can contact for more information. 2. <del> The Captive Portal DHCP / RA Option informs the client that it may be </del>  behind a captive portal and provides the URI to access an API as defined by [draft-ietf-capport-api].  This is primarily intended to improve the user experience by showing the user the captive portal attack. However, as the operating systems and application(s) that make use of <del> this information know that they are connecting to a captive-portal </del>  device (as opposed to intercepted connections where the OS/ application may not know that they are connecting to a captive portal or hostile device) they can render the page in a sandboxed

2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...) [Gahforthe_hyphens a87eb8d] 2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...)

In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode.  This highly restricts what the user can do  <ins> until the user has satisfied the captive portal conditions. </ins> This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some  <ins> sort of captive portal enforcement device, and that they will need to </ins> satify the Captive Portal conditions to get Internet access.  It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a 1.  <ins> In many environments, users need to connect to a captive portal </ins> device and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  Regardless of how that mechanism operates, this document provides functionality how to contact it. In order to present users with the payment or AUP pages, presently a  <ins> captive portal enforcement device has to intercept the user's </ins> connections and redirect the user to a captive portal server, using methods that are very similar to man-in-the-middle (MITM) attacks. As increasing focus is placed on security, and end nodes adopt a more This document describes a DHCPv4 RFC2131 and DHCPv6 RFC8415 option (Captive-Portal) and an IPv6 Router Advertisement (RA) RFC4861 option  <ins> that informs clients that they are behind a captive portal </ins> enforcement device and the API endpoint that the host can contact for more information. 2.  <ins> The Captive-Portal DHCP / RA Option informs the client that it may be </ins> behind a captive portal and provides the URI to access an API as defined by [draft-ietf-capport-api].  This is primarily intended to improve the user experience by showing the user the captive portal attack. However, as the operating systems and application(s) that make use of  <ins> this information know that they are connecting to a captive portal </ins> device (as opposed to intercepted connections where the OS/ application may not know that they are connecting to a captive portal or hostile device) they can render the page in a sandboxed


techniques to serve legacy clients, and clients will need to perform probing to detect captive portals.  In order to support multiple "classes" of clients (e.g.  IPv4 only, IPv6 only with DHCPv6 (RFC3315), IPv6 only with RA) the captive portal can provide the URI via multiple methods (IPv4 DHCP, IPv6

Fixes issue
Aaaaannd fixed the merge conflicts again. NAME NAME please take a look!
In our interop testing, all of the implementations of portals require that the DHCP option is in the request list in order for it to be sent. We should be explicit that this is what SHOULD be done in the document (clients SHOULD request).

techniques to serve legacy clients, and clients will need to perform probing to detect captive portals. <ins> Clients that support the Captive Portal DHCP option SHOULD include the option in the Parameter Request List in DHCPREQUEST messages. DHCP servers MAY send the Captive Portal option without any explicit request. </ins> In order to support multiple "classes" of clients (e.g.  IPv4 only, IPv6 only with DHCPv6 (RFC3315), IPv6 only with RA) the captive portal can provide the URI via multiple methods (IPv4 DHCP, IPv6


3. <del> Some captive portal network deployments may be unable to change, or unwilling to risk changing, the network infrastructure necessary to use any of the above options.  In such deployments, when clear text HTTP intercept and redirection are used, a Link relation header (RFC8288, Section 3.3) MAY be inserted to convey to a HTTP client (user agent) the associated Captive Portal API URI. HTTP user agents MUST ignore this link relation in any context other than when explicitly probing to detect the presence of a captive portal.  Failure to do so could allow an attacker to inject a Captive Portal API URI other than the correct URI for a given network or for networks where there is no captive portal present at all. 4. </del> A device may learn about Captive Portal API URIs through more than one of (or indeed all of) the above options.  It is a network configuration error if the learned URIs are not all identical. captive device MUST prioritize URIs learned from network provisioning or configuration mechanisms before all other URIs.  Specifically, URIs learned via any of the options in option should take precedence <del> over any URI learned via a mechanism like the one described in linkrel. </del>  If the URIs learned via more than one option described in option are not all identical, this condition should be logged for the device owner or administrator.  URI precedence in this situation is not specified by this document. <del> 5. </del>  This document requests two new IETF URN protocol parameter (RFC3553) entries. Thanks IANA! <del> 5.1. </del>  <del> 5.1.1. </del>  Registry name: Captive Portal Unrestricted Identifier Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. <del> 5.1.2. Registry name: Captive Portal API Link Relation Type URN: urn:ietf:params:capport-api Specification: RFC TBD (this document) Repository: RFC TBD (this document) Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. 6. </del>  <del> An attacker with the ability to inject DHCP messages, RAs, or HTTP headers into cleartext HTTP communications could include an option or link relation from this document and so force users to contact an </del>  address of his choosing.  As an attacker with this capability could simply list himself as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more

At IETF 106, we discussed removing the link relation. This PR does that.
I suppose we should be reading and implementing draft-ietf-git-github-wg-configuration ... As Warren's T-shirt says: "In my defense I was left unsupervised."
100% agreed about the build output...
People who put build output in their repository deserve a special place.

3.  A device may learn about Captive Portal API URIs through more than one of (or indeed all of) the above options.  It is a network configuration error if the learned URIs are not all identical. captive device MUST prioritize URIs learned from network provisioning or configuration mechanisms before all other URIs.  Specifically, URIs learned via any of the options in option should take precedence  <ins> over any URI learned via some other mechanism, such as a redirect. </ins> If the URIs learned via more than one option described in option are not all identical, this condition should be logged for the device owner or administrator.  URI precedence in this situation is not specified by this document.  <ins> 4. </ins> This document requests two new IETF URN protocol parameter (RFC3553) entries. Thanks IANA!  <ins> 4.1. </ins>  <ins> 4.1.1. </ins> Registry name: Captive Portal Unrestricted Identifier Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible.  <ins> 5. </ins>  <ins> An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an </ins> address of his choosing.  As an attacker with this capability could simply list himself as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more


Captive-Portal Identification in DHCP / RA <del> draft-ietf-capport-rfc7710bis-01 </del>  Abstract 4. <del> This document requests two new IETF URN protocol parameter (RFC3553) entries.  This document also requests a reallocation of DHCPv4 option </del>  codes (see exp106 for background). Thanks IANA!

Earlier version of this document requested a parameter to be used for Link Relation purposes. This LinkRel use was removed as was the explicit parameter request, but the surround grammar was overlooked. Also: rev draft version to -02 and document month to February in anticipation of post a new version.

Captive-Portal Identification in DHCP / RA  <ins> draft-ietf-capport-rfc7710bis-02 </ins> Abstract 4.  <ins> This document requests one new IETF URN protocol parameter (RFC3553) entry.  This document also requests a reallocation of DHCPv4 option </ins> codes (see exp106 for background). Thanks IANA!


<del> Mode of Operation extension and Capabilities draft-ietf-roll-mopex-cap-latest </del>  Abstract <del> RPL allows different mode of operations which allows nodes to have a consensus on the basic primitives that must be supported to join the network.  The MOP field in RFC6550 is of 3 bits and is fast depleting.  This document extends the MOP field specification and adds a notion of capabilities using which the nodes can further advertise their support for, possibly optional, capabilities. </del>  1. mandatory set of primitives to be supported by all the participating nodes. <del> MOP as per RFC6550 is a 3-bit value carried in DIO messages and is specific to the RPL Instance.  The receipient of the DIO message can join the specified network as a router only when it can support the primitives as required by the mode of operation value.  For example, in case of MOP=3 (Storing MOP with multicast support) the nodes can join the network as routers only when they can handle the DAO advertisements from the peers and manage routing tables.  The 3-bit value is already exhausted and requires replenishment.  This document introduces a mechanism to extend mode of operation values. This document further adds a notion of capabilities using which the nodes in the network could inform its peers about its additional capabilities/features.  This document highlights the differences of capabilities from that of Mode of operation and explains the necessity of it. </del>  1.1. Instance as administratively provisioned at and distributed by the DODAG root. <del> MOPex: Extended MOP: This document extends the MOP values over a bigger range.  This extension of MOP is called MOPex. </del>  Capabilities: Additional features or capabilities which might possibly be optional that are supported by the node. MOPex: MOP extension as defined in this document.  This document uses terminology described in RFC6550.  For the sake of readability all the known relevant terms are repeated in this section.  2. Following are the requirements considered for this documents: <del> MOP extension.  Current MOP of 3-bit is fast depleting.  An MOP extension needs to extend the possibility of adding new MOPs in the future. </del> Backwards compatibility.  The new options and new fields in the DIO message should be backward compatible i.e. if there are nodes which support old MOPs they could still operate in their own independent i.e. a DIO can have a capabilities option, MOP- extension option or both in the same message. <del> 3. This document reserves existing MOP value 7 to be used as an extender.  DIO messages with MOP value of 7 may refer to the Extended MOP (MOPex) option in the DIO message. </del>  <del> 3.1. An implementation supporting this document MUST calculate the final MOP value as the sum of base MOP (as supported in Section 6.3.1. of RFC6550) plus the MOPex value.  Thus if the MOPex value is 0, it means the final MOP is 7 since the base MOP in this case will be set to 7. </del>  <del> 3.2. </del>  <del> If the MOPex option is absent in the DIO whose MOP is 7, then the MOPex value can be assumed to be zero (thus the final MOP in this case will be 7).  The MOPex value should be referred only if the base MOP value is 7 and if the MOPex option is present.  In case the base MOP is 7 and if the MOPex option is present, then the implementation MUST calculate the final MOP after considering the value in MOPex. </del>  <del> Note that RFC6550 allows the node who does not support the received MOP to still join the network as a leaf node.  This semantic continues to be true even in case of MOPex. </del>  <del> 4. </del>  <del> Currently RPL specification does not have a mechanism whereby a node can signal the set of features that are available on its end.  Such a mechanism could help the root to advertise its capabilities and in response also determine some advanced information about the capabilities of the joining nodes.  The Mode of Operation field in RPL mandates the operational requirement and does not allow loose coupling of additional capabilities.  This document defines Capabilities as additional features which could be supported by the nodes and handshaked as part of RPL signaling.  Capabilities are embedded as RPL control message option as defined Section 6.7 of RFC6550 in the base messages of DIO, DAO and DAO-ACK signaling. Note that capabilities and MOPex are mutually exclusive and it is possible for an implementation to support either or both of the options. 4.1. </del>  Multiple capabilities could be sent in the same message.  The length field allows the message parser to skip the capability TLV parsing. document.  This document provides a container format for carrying the capability and its context information. <del> 4.2. </del>  The root node could advertise the set of capabilities it supports in the DIO message.  A node could take advantage of the knowledge that This handling is similar to the Transit Information Option as supported in Section 6.7.8. of RFC6550. <del> 5. The MOP-extension could cause 3-byte increase in memory in the RPL- Instance.  The MOP field in the RPL-Instance needs to be upgraded to a 32 bit integer. RFC6550, it was possible to discard an unsupported DIO-MOP just by inspecting the base message.  With this document, the MOPex is a different control message option and thus the discarding of the DIO message could happen after inspecting the message options. A node in storing MOP could independently construct a DAO message with target options containing its child/sub-childs.  Thus with capabilities it needs to reconstruct the capabilities field as well. This may result in increase in the memory requirement on per routing- entry basis. 6. 6.1. IANA is requested to assign a new Mode of Operation, named "MOPex" for MOP extension under the RPL registry.  The value of 7 is to be assigned from the "Mode of Operation" space RFC6550 6.2. Two new entries are required for new supporting new options "MOPex", "Capabilities" from the "RPL Control Message Options" space RFC6550. 6.3. IANA is requested to create a registry for the extended-MOP-value (MOPex).  This registry should be located in TODO.  New MOPex values may be allocated only by an IETF review.  Currently no values are defined by this document.  Each value is tracked with the following qualities: MOPex value </del>  <del> Description </del>  <del> Defining RFC </del>  <del> 6.4. </del>  IANA is requested to create a registry for the Capabilities flags as described in cap-why of this document.  This registry should be Defining RFC <del> 7. </del>  The options defined in this document are carried in the base message objects as defined in RFC6550.  The RPL control message options are

splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1

<ins> RPL Capabilities draft-ietf-roll-capabilities-latest </ins> Abstract  <ins> This draft enables the discovery, advertisement and query of capabilities for RPL nodes. </ins> 1. mandatory set of primitives to be supported by all the participating nodes.  <ins> This document adds a notion of capabilities using which the nodes in the network could inform its peers about its additional capabilities/ features.  This document highlights the differences of capabilities from that of Mode of operation and explains the necessity of it. </ins> 1.1. Instance as administratively provisioned at and distributed by the DODAG root.  <ins> MOPex: Extended MOP: As defined in [I-D.jadhav-roll-mopex]. </ins> Capabilities: Additional features or capabilities which might possibly be optional that are supported by the node. MOPex: MOP extension as defined in this document. <ins> Upstream path/direction: Path or direction from the node to the Root in a DAG. Downstream path/direction: Path or direction to the node from the Root in a DAG. </ins> This document uses terminology described in RFC6550.  For the sake of readability all the known relevant terms are repeated in this section. <ins> 1.2. Currently RPL specification does not have a mechanism whereby a node can signal the set of features that are available on its end.  Such a mechanism could help the root to advertise its capabilities and in response also determine some advanced information about the capabilities of the joining nodes.  This document defines Capabilities which could be supported by the nodes and handshaked as part of RPL signaling.  Capabilities are embedded as RPL control message option as defined Section 6.7 of RFC6550 in the base messages of DIO, DAO and DAO-ACK signaling. </ins> 2. Following are the requirements considered for this documents:  Backwards compatibility.  The new options and new fields in the DIO message should be backward compatible i.e. if there are nodes which support old MOPs they could still operate in their own independent i.e. a DIO can have a capabilities option, MOP- extension option or both in the same message.  <ins> Capabilities could be explicitly queried. </ins>  <ins> 2.1. </ins>  <ins> The Mode of Operation (MOP) field in RPL mandates the operational requirement for the nodes joining as routers.  MOP and DIO Configuration Option is strictly controlled by the Root node in RPL. Intermediate 6LRs could not modify the values.  Also, the MOP never changes for the lifetime of the RPL Instance.  Changes in DIO Configuration Option are possible but are very rare.  Capabilities, on the other hand, might change more dynamically. </ins>  <ins> RPL DIO message also carries routing metrics and constraints as specified in RFC6551.  Metrics and constraints are used as part of objective function which aids in node's rank calculation.  A router may use capabilities carried in DIO message as additional metrics/ constraints.  However, capabilities have a larger scope and may be carried in other messages other than DIO and can flow in both the directions (upstream and downstream). </ins>  <ins> 3. </ins>  <ins> Handling of Capabilities MUST be supported if the network uses MOPex [I-D.jadhav-roll-mopex]. </ins>  <ins> 3.1. </ins> Multiple capabilities could be sent in the same message.  The length field allows the message parser to skip the capability TLV parsing. document.  This document provides a container format for carrying the capability and its context information.  <ins> 3.2. </ins> The root node could advertise the set of capabilities it supports in the DIO message.  A node could take advantage of the knowledge that This handling is similar to the Transit Information Option as supported in Section 6.7.8. of RFC6550.  <ins> 4. </ins>  <ins> 4.1. </ins>  <ins> New entry is required for supporting new Capabilities option in the "RPL Control Message Options" space RFC6550. </ins>  <ins> 4.2. </ins> IANA is requested to create a registry for the Capabilities flags as described in cap-why of this document.  This registry should be Defining RFC  <ins> 5. </ins> The options defined in this document are carried in the base message objects as defined in RFC6550.  The RPL control message options are


Handling of Capabilities MUST be supported if the network uses MOPex [I-D.jadhav-roll-mopex].  3.1.  Multiple capabilities could be sent in the same message.  The length field allows the message parser to skip the capability TLV parsing. Every capability is identified by its type and it may have an optional Capability Info.  Note that a given capability may or may <del> not be diseminated with additional information depending on the 'I' flag. J = Join only as leaf if capability not understood C = Copy capability to children </del>  I = Cap Info present document.  This document provides a container format for carrying the capability and its context information. <del> 3.2. </del>  The root node could advertise the set of capabilities it supports in the DIO message.  A node could take advantage of the knowledge that capabilities advertised by the root. In storing MOP, the DAO message from the 6LR could contain multiple <del> target options.  The targets of the capabilities option are indicated by one or more Target options that precede the Capabilties Option. This handling is similar to the Transit Information Option as supported in Section 6.7.8. of RFC6550. </del>  4.

Modified Capabilities section.
NAME - the complete file seems to be changed! Is it because of the ^M issue? Better you can close this PR and raise another one only with the changes. Thanks
Comments for the PR.

Handling of Capabilities MUST be supported if the network uses MOPex [I-D.jadhav-roll-mopex]. <ins> Note that capabilities and MOPex are mutually exclusive and it is possible for an implementation to support either or both of the options. </ins> 3.1. <ins> Capabilities can be divided into two broad categories Global Capabilities: It will include the features and capability supported across an RPL instance.  These capabilities can be advertised by the Root or 6LRs of the DODAG.  If a Node in the LLN doesn't support a paticular global capability it may have to join the RPL instance as a leaf node, as indicated by that individual capability option.  Example of such capabilities are Compression Methods Supported, Support for TE paths (P-DAO). Local Capabilities: It will include the cpabilities very specific to a Node in the LLN.  Example of such capabilities are NBR Cache information, Routing Table Information. Note that some capabilities can be either global or local depending upon the context they are used ex.P-DAO 3.2. </ins> Multiple capabilities could be sent in the same message.  The length field allows the message parser to skip the capability TLV parsing. Every capability is identified by its type and it may have an optional Capability Info.  Note that a given capability may or may  <ins> not be diseminated with additional information depending on the scope of the capability indicated by the G bit.  The first Bit of the CAPType indicates if the capability is mandatory or optional Value of 1 indicates its a mandatory capability and 0 indicates its an optional capability G = If set indicates a Global Capability/Feature else its a local. For a capability if it's mandatory and global bit is set then node thoes either doesn't understand the capability or doesn't have this capability should not join the DODAG as LR.  All the global capablities MUST be desiminated across the network. </ins> I = Cap Info present document.  This document provides a container format for carrying the capability and its context information.  <ins> 3.3. </ins> The root node could advertise the set of capabilities it supports in the DIO message.  A node could take advantage of the knowledge that capabilities advertised by the root. In storing MOP, the DAO message from the 6LR could contain multiple  <ins> target options beacuse of the DAO-Aggregation.  The targets of the capabilities option are indicated by one or more Target options that precede the Capabilties Option.  This handling is similar to the Transit Information Option as supported in Section 6.7.8. of RFC6550. 3.4. 3.4.1. I-D.ietf-roll-dao-projection proposes mechanisms to compute and install traffic engineered paths in the RPL network.  It enables an RPL Root to install and maintain Projected Routes based on requested path metric, within its DODAG, along with a selected set of nodes that may or may not include self, for a chosen duration.  Projected Route Capability will be used to enable this TE path calculation. PRC will be an optional global capability.  Any node that does not understand or support the projected route functions can still act as an LR. The DODAG root will use projected routes capability to advertise the support of projected routes with the possible mode of operations and set of path metrics it can use to calculate a projected route.  DODAG root will add the PRC to DIO message so that it can disseminate the information in entire DODAG.  Router nodes in the LLN receiving DIOs with PRC MUST forward the same into their sub-DODAG without any change even though they don't understand or support the projected route feature.LR will use the path metric information advertised by the DODAG root to learn these metrics from the network and neighbors. The same information they will use to advertise in the sibling information option.  LR will also use these path metrics information to request traffic-engineered routes optimizing a or set of specific network metric(s). LRs in the network will use this capability to inform the PCE if they can be part of a storing or non-storing or both mode of projected routes.  Here the PRC will be part of the DAO message. The capability will convey the below information.  The PRC MUST have either of the information or both depending upon the node type.If originator is BR, then both the information MUST be there. Supports projected route for both storing and non-storing mode. List of supported path metrics that supported that can be used to compute projected routes [To Decide] Can we add the PCE address information to this? 3.4.1.1. Type: 0x01. Flags: DODAG root MUST set G bit to 1 plus LRs MUST set it to 0.  I bit will always be set to 1. CAPLen: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. MOP: 3-bit field indicating the mode of operation of projected route capability. Resvd: 5-bit unused fields.They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Routing Merric: 16 bit unsigned integer represetning the the routing metric to be used for TE path calculation.  There can be n number of such routing metric fields.  These fileds are alowed with the PRC sent by the DODAG ROOT.  LRs MUST not send routing metric information with PRC. 3.4.2. RFC8138 introduces a new 6LoWPAN Routing Header (6LoRH) to carry IPv6 routing information.  The 6LoRH may contain source routing information such as a compressed form of SRH, and other sorts of routing information such as the RPI and IP-in-IP encapsulation The transition to RFC8138 in a network can only be done when all nodes support the specification.  In a mixed case with both RFC8138-capable and non-capable nodes it would not be posssible to take advantage of 6LoRH.I-D.thubert-roll-turnon-rfc8138 defines a mechanism to control the use of 6LoRH in a DODAG by using "T" flag bit in RPL configuration option.  To assist DODAG root to decide if it has to set "T" flag bit in RPL Configuration Option to enable 6LoRH within its DODAG, all LRs in DODAG MUST inform their support of RFC 8138 by adding 6LoRH capability TLV to their advertised capability control message option. DODAG root MUST use 6LoRH capability TLV to inform all the nodes in the DODAG, that DODAG is RFC8138 compliance. 6LoRH is an optional local capability. Any LR joining the DODAG MUST add 6LoRH capability TLV to the capability control message option in its DAO message to inform BR that it supports RFC8138.If received DAO message doesn't have 6LoRH capability TLV, DODAG Root MUST conclude the target node doesn't support RFC 8138.So if DODAG is still not using 6LoRH, it MUST refrain from using the compression and if it is already using it, it MUST deny the LR from joining the DODAG with proper error code. [TODO- Need to add new Error code]. 6LoRH capability is an optional capability any node that doesn't understand or support the 6LoRH can join the DODAG if the "T" flag in the RPL Configuration option is not set otherwise it MUST join the network as a leaf node. 3.4.2.1. Type: 0x02. Flags: LRs MUST set it to 0.  I bit will always be set to 0. Reserved: 16-bit unsigned integer, they MUST be initialized to zero by the sender and MUST be ignored by the receiver.. 3.4.3. Storing mode of operation requires each intermediate router in the LLN to maintain routing states' information in the routing table. LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Memory limits the number of routing states an LR and BR can maintain.  When the routing table of an LR or BR is full, it will either reject the new DAO messages received or will use some replacement policy to remove a routing entry and add the new one.  Rejection of DAO messages will lead to an increase in DAO message transmission that impacts the energy and network convergence time.  Routing state replacement leads to downward path downtime. One possible way to solve problems due to routing table size constraint is to use this information to add neighbors to the DAO parent set.Routing resource capability can be used by LR and BR to advertise their current routing table usage details in the network. LR or LNs in LLN can use this information in the selection of the DAO parent set.  PCE can use this information to select intermediate routers for the projected routes.  Routing Resource is an optional local capability. Routing reource capability TLV can occur multiple times in the capability control message option to advertise below possible routing table information. Master Routing Table Storing Storing mode P-DAO Table Non-Storing mode P-DAO Routing resource capabablity sent in DIO message has link local scope and it MUST not be forwarded. 3.4.3.1. Type: 0x03. Flags: G bit MUST be set to 0.  I bit will always be set to 1. CAPLen: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. RT: 3-bit field indicating the routing resource type.  This document defines 3 routing resource type. Master Routing Table Storing(RT = 1) Storing mode P-DAO Table(RT = 2) Non-Storing mode P-DAO(RT = 3) Resvd: 5-bit unused fields.They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Total Capacity: 16 bit unsigned integer represetning the the routing table size. Percentage used: 8 bit unsigned integer represetning the the percentage of routing table space currently in use. Threshold: 8 bit unsigned integer represetning the maximum routing table space that can be used.  If the routing resource type is RT1 and used Percentage is greater than or equal to a threshold, its siblings MUST stop using it as the preferred parent or remove it from the parent list.  If the routing resource type is RT2 or RT3 and used Percentage is greater than or equal to a threshold, PCE MUST recompute some projected routes by excluding this node. 3.4.4. A neighbor cache maintains neighboring one-hop connected nodes information such as MAC address, link-local IP address and other reachability state information needed for layer two communication.Node density has direct implications on the neighbor cache.  In the constrained network scenario the size of the neighbor cache will be limited.  Thus there are chances that a node may not be able to store all the neighboring nodes in its cache and use replacement algorithms to evict some of the entries to accommodate the new one.  If the replaced neighbor has installed a DAO route on it then it can lead to packet loss or additional address resolution message exchange.  To avoid unnecessary replacement of neighbor cache entries neighbor cache management policy I-D.ietf-lwig-nbr-mgmt- policy proposes a solution that will put a restriction on the connectivity to immediate neighbor depending upon the type of neighbor.  But this won't solve the problem unless until the availability of neighbor cache is not taken into consideration while selecting the DAO parent set. Neighbor Cache capability can be used by LR and BR to advertise their neighbor cache size information.  This capablity information has only link scope and should not be advertised in the entire network. [TODO-- As neighbor cache entries category is not yet standardized i think we can't use it in capability.  With categories format of the TLV is going to chnage.] 3.4.4.1. </ins> 4.


The access token also comprises a "cnf" claim.  This claim usually contains a "COSE_Key" object that carries either the symmetric key <del> itself or or a key identifier that can be used by the resource server to determine the shared secret.  If the access token carries a symmetric key, the access token MUST be encrypted using a </del>  "COSE_Encrypt0" structure.  The AS MUST use the keying material shared with the RS to encrypt the token. <del> Instead of providing the keying material, the AS MAY include a key derivation function and a salt in the access token that enables the </del>  resource server to calculate the keying material for the <del> communication with C from the access token.  In this case, the token contains a "cnf" structure that specifies the key derivation algorithm and the salt that the AS has used to construct the shared key.  AS and RS MUST use their shared keying material for the key derivation, and the key derivation MUST follow Section 11 of RFC 8152 [18] with parameters as specified here.  The KDF specified in the "alg" parameter SHOULD be HKDF-SHA-256.  The salt picked by the AS must be uniformly random and is carried in the "salt" parameter. </del>  The fields in the context information "COSE_KDF_Context" <del> (Section 11.2 of RFC 8152 [19]) MUST have the following values: </del>  <del> AlgorithmID = "ACE-CoAP-DTLS-salt" </del>  PartyUInfo = PartyVInfo = ( null, null, null ) <del> keyDataLength is a uint equal the length of the key shared between AS and RS in bits </del>  protected MUST be a zero length bstr SuppPrivInfo is omitted <del> The ACE_Salt "cnf" structure specifying HMAC-based key derivation of a symmetric key with SHA-256 as hash function and a random salt value is provided in kdf-cnf. A response that declines any operation on the requested resource is constructed according to Section 5.2 of RFC 6749 [20], (cf. Section 5.7.3. of draft-ietf-ace-oauth-authz [21]). </del>  3.3.1. [17] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz <del> [18] https://tools.ietf.org/html/rfc8152#section-11 </del>  <del> [19] https://tools.ietf.org/html/rfc8152#section-11.2 </del>  <del> [20] https://tools.ietf.org/html/rfc6749#section-5.2 </del>  <del> [21] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz#section- 5.7.3 </del>  [22] https://tools.ietf.org/html/rfc4279#section-2

The normative specification of how to use a salt for deriving a symmetric key to use between C and RS is changed into an example using cnf = COSE_key.
The text claims to present an example, but contains a lot of normative language (probably heritage from when it was normative text). I don't think that goes well together and it leaves the reader with an unclear feeling as to where the example ends and normative text resumes. I would suggest to remove all normative language from the example and make it clear at which point the example ends and normative text resumes. I do like the idea to present this mechanism as an example however, since it is really up to the applications how they retrieve a key based on a key identifier, and I believe derivation is a fine example here.
In 9624eea the normative text is removed from the example and the example is moved to the end of the section to separate the example from the rest of the text.
Just to clarify if my understanding is correct: The proposal says that if the access token contains but no , the RS needs to derive K{C, RS} in some application-specific way?
Yes, with the interpretation that "derive" could mean "look up", "retrieve" etc. I.e. the RS needs to know how to obtain k{C, RS} from kid. Can the text be further clarified?
No, this is what I also think that the text says. Thus, I am fine merging this PR.
Since two co-authors are OK I merge this now. Further comments can be added on the master branch.

The access token also comprises a "cnf" claim.  This claim usually contains a "COSE_Key" object that carries either the symmetric key  <ins> itself or a key identifier that can be used by the resource server to determine the secret key shared with the client.  If the access token carries a symmetric key, the access token MUST be encrypted using a </ins> "COSE_Encrypt0" structure.  The AS MUST use the keying material shared with the RS to encrypt the token.  <ins> A response that declines any operation on the requested resource is constructed according to Section 5.2 of RFC 6749 [18], (cf. Section 5.7.3. of draft-ietf-ace-oauth-authz [19]). The method for how the resource server determines the symmetric key from an access token containing only a key identifier is application specific, the remainder of this section provides one example. The AS and the resource server are assumed to share a key derivation key used to derive the symmetric key shared with the client from the key identifier in the access token.  The key derivation key may be derived from some other secret key shared between the AS and the resource server.  Knowledge of the symmetric key shared with the client must not reveal any information about the key derivation key or other secret keys shared between AS and resource server. In order to generate a new symmetric key to be used by client and resource server, the AS generates a key identifier and uses the key derivation key shared with the resource server to derive the symmetric key as specified below.  Instead of providing the keying material in the access token, the AS includes the key identifier in the "kid" parameter, see kdf-cnf.  This key identifier enables the </ins> resource server to calculate the keying material for the  <ins> communication with the client from the access token using the key derivation key and following Section 11 of RFC 8152 [20] with parameters as specified here.  The KDF to be used needs to be defined by the application, for example HKDF-SHA-256.  The key identifier picked by the AS needs to be unique for each access token where a unique symmetric key is required. </ins> The fields in the context information "COSE_KDF_Context"  <ins> (Section 11.2 of RFC 8152 [21]) have the following values: </ins>  <ins> AlgorithmID = "ACE-CoAP-DTLS-key-derivation" </ins> PartyUInfo = PartyVInfo = ( null, null, null )  <ins> keyDataLength is a uint equal the length of the symmetric key shared between C and RS in bits </ins> protected MUST be a zero length bstr SuppPrivInfo is omitted  <ins> The "cnf" structure in the access token is provided in kdf-cnf. </ins> 3.3.1. [17] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz  <ins> [18] https://tools.ietf.org/html/rfc6749#section-5.2 </ins>  <ins> [19] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz#section- 5.7.3 </ins>  <ins> [20] https://tools.ietf.org/html/rfc8152#section-11 </ins>  <ins> [21] https://tools.ietf.org/html/rfc8152#section-11.2 </ins> [22] https://tools.ietf.org/html/rfc4279#section-2


As recommended in Section 5.8 of I-D.ietf-ace-oauth-authz, this specification uses CBOR web tokens to convey claims within an access token issued by the server.  While other formats could be used as <del> well these are out of scope for this document. </del>  1.1.

Change last sentence of Introduction from: While other formats could be used as well these are out of scope for this document. to: While other formats could be used as well, those are out of scope for this document.
Good point, thank you!

As recommended in Section 5.8 of I-D.ietf-ace-oauth-authz, this specification uses CBOR web tokens to convey claims within an access token issued by the server.  While other formats could be used as  <ins> well, those are out of scope for this document. </ins> 1.1.


response for the client.  The access token MUST be bound to the RPK of the client by means of the "cnf" claim. <del> The response MUST contain an "ace_profile" parameter if the"ace_profile" parameter in the request is empty, and MAY contain this parameter otherwise (see Section 5.8.2 of I-D.ietf-ace-oauth- authz).  This parameter is set to "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server.  The response also contains an access token with information for the resource server about the client's public key. The authorization server MUST return in its response the parameter </del>  "rs_cnf" unless it is certain that the client already knows the public key of the resource server.  The authorization server MUST ascertain that the RPK specified in "rs_cnf" belongs to the resource any re-coding.  This allows the resource server to retrieve the shared secret directly from the "cnf" claim of the access token.  If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater than zero, it MUST parse the contents of the "psk_identity" field as CBOR data structure provide similar forward-secrecy properties to using ephemeral Diffie- Hellman (DHE) key exchange mechanisms.  For longer-lived access tokens, DHE cipher suites should be used, i.e., cipher suites of the <del> form TLS_DHE_PSK_*. </del>  Constrained devices that use DTLS RFC6347 are inherently vulnerable to Denial of Service (DoS) attacks as the handshake protocol requires

It is perhaps a stretch to call the description of using a for DLTS 1.3 as "editorial", but it really is the analogous way to do it, so this seems like just some additional exposition and not new content. I think that it will be okay to just include this in the XML file provided to the RFC Editor when they ask for one after approval.

response for the client.  The access token MUST be bound to the RPK of the client by means of the "cnf" claim.  <ins> The response MUST contain an "ace_profile" parameter if the "ace_profile" parameter in the request is empty, and MAY contain this parameter otherwise (see Section 5.8.2 of I-D.ietf-ace-oauth-authz). This parameter is set to "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server.  The response also contains an access token with information for the resource server about the client's public key.  The authorization server MUST return in its response the parameter </ins> "rs_cnf" unless it is certain that the client already knows the public key of the resource server.  The authorization server MUST ascertain that the RPK specified in "rs_cnf" belongs to the resource any re-coding.  This allows the resource server to retrieve the shared secret directly from the "cnf" claim of the access token. <ins> DTLS 1.3 does not use the ClientKeyExchange message; for DTLS 1.3, the access token is placed in the "identity" field of a "PskIdentity" within the "PreSharedKeyExtension" of the "ClientHello". </ins> If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater than zero, it MUST parse the contents of the "psk_identity" field as CBOR data structure provide similar forward-secrecy properties to using ephemeral Diffie- Hellman (DHE) key exchange mechanisms.  For longer-lived access tokens, DHE cipher suites should be used, i.e., cipher suites of the  <ins> form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*. </ins> Constrained devices that use DTLS RFC6347 are inherently vulnerable to Denial of Service (DoS) attacks as the handshake protocol requires


'key', containing the keying material necessary for the group communication. <del> 'kty', identifying the key type of the key. </del>  The exact format of the 'key' value MUST be defined in applications of this specifications.  Additionally, documents specifying the key <del> format MUST register it in the "ACE Groupcomm Key" registry, defined in iana-key, and MUST register its type in the "ACE Groupcomm Key Type" registry, defined in </del>  Optionally, the Key Distribution Response MAY contain the following parameters, which, if included, MUST have the corresponding values: 9.1. <del> TODO </del>  <del> 9.2. </del>  <del> TODO </del>  <del> 9.3. </del>  This specification establishes the IANA "ACE Groupcomm Profile" registry.  The registry has been created to use the "Expert Review <del> Required" registration procedure RFC8126.  It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. </del>  The columns of this registry are: Reference: This contains a pointer to the public specification of the profile abbreviation, if one exists.

Following URL and a chat at IETF103.
AP8: 'pubkeysrepos', as a CBOR array of tstr containing URIs. Hi Jim, Thanks a lot for your detailed review, as you might have seen we have included most comments in the latest version: URL Please note that this version includes also review comments from Peter, which in some cases overlapped, so some text might be reformulated to include both inputs. Inline, detailed comments and some questions. Thanks, Francesca Section 2 - client - write rights and/or read rights. Unless you think that write implies read in which case you should state that FP: Right, we now specify: " It can request write and/or read rights." Section 2 - KDC - should also say what it does in the later parts - FP: Ok, we added the following text: " During the second part (Section 4), which is not based on the ACE Framework, it distributes the keying material." We also added details about the role of the KDC for redistribution of keying material. Section 2 - Dispatcher - If this is a bus, then you are not really communicating with it securely. Anybody can write on it, but people will just ignore what comes out the other end. FP: Right, reformulated in " entity through which the Clients communicate with the group and which distributes messages to the group members." Section 3- A brief description of all of the operations would be appreciated. FP: we have now added several sections to describe the operations. In section 2 (starting with " This document specifies the message flows and formats for:") we describe the high level operations. At the beginning of each section (3. and 4.) we also give an overview of the exchange described in the subsections. Section 3.1 - Can I get authorization for multiple items at a single time? FP: In theory, it would be possible, and that would require to change the format of scope, going from [ group-id, [role1, role2] ] to [ [group-id1, group-id2], [[role1, role2], [role1]] ]. We haven't implemented this change, because it seems to cause a lot of overhead and complexity, for what seems to be a corner case. But if people think this is a valid use case, we can reconsider. We have added a placeholder comment in the md for this. Section 3.1 - Does it make sense to allow for multiple audiences to be on a single KDC? FP: I am not sure I understand the scenario, could you expand on this? (We have added a comment in the md for this as well) Section 4.x - cnf - text does not allow for key identifier FP: Did you get the section wrong? In 4.x we do not use cnf. In which section exactly would you send the kid in the cnf? That should be defined in the Ace framework (and params)... Section X.X - Define a new cnf method to hold the OSCORE context parameters - should it be a normal COSEKey or something new just to makes sure that it is different. FP: This is the same comment as in the OSCORE Profile. Again, I am not sure why we really need a new structure since COSEKey is general enough to transfer all the keying material, with the addition of the couple of new parameters defined. But if you think this is necessary, we can definitely change. Section 3.X - I am not sure if write or POST is a better answer for what the role being requested is. FP: Again, I don't understand this comment. We don't really define what one should use as role, write or POST are both possible. Section 4 - Should one talk about the ability to use OBSERVE as part of key distribution? FP: We added a comment as a placeholder for this in the md. Observe was just briefly mentioned before and not really elaborated. Although it would work, it seems not useful to have it together with a proper rekeying scheme where the KDC takes the initiative anyway. Section 4.x - I am having a hard time trying to figure out the difference between a group and a topic. The text does not always seem to distinguish these well. FP: It was our purpose to keep the text high level enough so that it would apply to both. Does that create any problem/confusion? Seciton 4.1 - POP on client key esp if bound to an identity (Note using it to access the KDC is one POP) FP: Now added the following text at the end of section 4.: " Note that proof-of-possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing secure communication between the Client and the KDC." Section 4.2 - why not use the exp field from OAUTH in the response FP: the exp field from the AS in the response relates to the token. This exp relates to the keying material. Yes, when the token expires the keying material should expire (and that is specified e.g. in the OSCORE profile), but it could expire before/independently as well. Question - does somebody talk about doing key derivation for a new kid showing up and by the way where is the gid FP: It's in oscore-groupcomm that we describe how a new Recipient Context is derived. This document keeps a high livel perspective (so it does not talk about Gid), while in ace-oscoap-join we explain how the current Group ID is provided to a joining node (in the 'serverID' parameter of the COSE Key in the Join Response). Seciton 4.2 - if you are using profile, then you should return it FP: The Key distribution request and response, although inspired by ACE, do not use ACE, so "profile" is not really defined here. The profile is used in the first phase, between C - AS - KDC, and it is returned there. Introduction - introduce the concept of a key management protocol and point to some. Give some basic properties expected from one. FP: Some text was added at the end of the introduction: " If the application requires backward and forward security, updated keying material is generated and distributed to the group members (rekeying), when membership changes. A key management scheme performs the actual distribution of the updated keying material to the group. In particular, the key management scheme rekeys the current group members when a new node joins the group, and the remaining group members when a node leaves the group. This document provides a message format for group rekeying that allows to fulfill these requirements. Rekeying mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627]." Section 5.2 - What is the message to leave - can I leave one scope but not another? Can I just give up a role? FP: We have now added a TBD: format of the message to leave the group placeholder in Section 5.2. We will address this in a future update. The leave is intended per group, so one scope at the time losing all the roles in that group. Giving up a single role while remaining in the group does not require any particular interaction with the GM. It's just sufficient to stop behaving as that role. Seciton 6.1 - assumes scopes are unique across all audiences. Or assumes that I look up the correct token - should have an argument about why this is possible so that people can implement it right FP: We already had the check for the access token for a first time key distribution. We have added the following text in section 6.2: "the KDC receiving a Key Re-Distribution Request MUST check that it is storing a valid Access Token from that client for that scope." We also have added a TODO: defines error response if it does not have it / is not valid. Would that be enough? Comment somewhere about getting strike zones setup correctly for a newly seen sender of messages. Ptr to OSCORE? FP: Sorry I don't understand what you mean by strike zones. Could you expand on that? Jim Ace mailing list EMAIL URL

'key', containing the keying material necessary for the group communication.  <ins> 'kty', identifying the key type of the key.  The set of values can be found in the Key Type column of the "ACE Groupcomm Key". Implementations MUST verify that the key type matches the profile being used, if present, as registered in the "ACE Groupcomm Key" registry. </ins> The exact format of the 'key' value MUST be defined in applications of this specifications.  Additionally, documents specifying the key  <ins> format MUST register it in the "ACE Groupcomm Key" registry, including its name, type and profile to be used with, as defined in the "ACE Groupcomm Key" registry, defined in iana-key. </ins> Optionally, the Key Distribution Response MAY contain the following parameters, which, if included, MUST have the corresponding values: 9.1.  <ins> This specification establishes the IANA "ACE Groupcomm Key" registry. The registry has been created to use the "Expert Review Required" registration procedure.  Expert review guidelines are provided in </ins>  <ins> The columns of this table are: </ins>  <ins> Name: This is a descriptive name that enables easier reference to the item.  The name MUST be unique.  It is not used in the encoding. </ins>  <ins> Key Type Value: This is the value used to identify the keying material.  These values MUST be unique.  The value can be a positive integer, a negative integer, or a string. Profile: This field may contain a descriptive string of a profile to be used with this item.  This should be a value that is in the Name column of the "ACE Groupcomm Profile" registry. Description: This field contains a brief description of the keying material. References: This contains a pointer to the public specification for the format of the keying material, if one exists. This registry has been initially populated by the values in kty.  The specification column for all of these entries will be this document. 9.2. </ins> This specification establishes the IANA "ACE Groupcomm Profile" registry.  The registry has been created to use the "Expert Review  <ins> Required" registration procedure RFC8126.  Expert review guidelines are provided in review.  It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. </ins> The columns of this registry are: Reference: This contains a pointer to the public specification of the profile abbreviation, if one exists. <ins> 9.3. The IANA registry established in this document is defined as expert review.  This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude. Expert reviewers should take into consideration the following points: Point squatting should be discouraged.  Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments, code points in other ranges should not be assigned for testing. Specifications are required for the standards track range of point assignment.  Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible.  Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. Experts should take into account the expected usage of fields when approving point assignment.  The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range.  The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size. </ins>


specified in RFC8392. In order to facilitate offline processing of access tokens, this <del> draft uses the "cnf" claim from I-D.ietf-ace-cwt-proof-of-possession and specifies the "scope" claim for both JSON and CBOR web tokens. </del>  The "scope" claim explicitly encodes the scope of a given access token.  This claim follows the same encoding rules as defined in 5.8.1.1. When an RS receives an access token, it MUST verify it before storing <del> it.  The verification is based on the claims of the token and its cryptographic wrapper (if any), so the RS needs to retrieve those claims.  If the claims cannot be retrieved the RS MUST discard the token and in case of an interaction via the authz-info endpoint, return an error message with a response code equivalent to the CoAP code 4.00 (Bad Request). The cryptographic wrapper of the token (e.g. a COSE message) MUST be verified by the RS, based on shared cryptographic material with an AS that has the authority to issue tokens for the RS.  Since this wrapper could include encryption, it needs to be verified before the claims can be processed.  If this verification fails, the RS MUST discard the token and if this was an interaction with authz-info it MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized). The following claims MUST be checked if present, and errors returned when a check fails, in the order of priority of this list: </del>  The issuer claim must identify an AS that has the authority to issue access tokens for the receiving RS.  If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized). <del> The expiration date must be in the future.  Note that this has to be verified again at access time.  If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized). </del>  The audience claim must refer to an audience that the RS identifies with.  If that is not the case the RS MUST respond with The RS must recognize value of the scope claim.  If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request).  The RS MAY provide additional <del> information in the error response, in order to clarify what went wrong. </del>  If the access token contains any other claims that the RS cannot process the RS MUST respond with a response code equivalent to the in the error response to clarify which claim couldn't be processed. Note that the Subject (sub) claim cannot always be verified when the <del> token is submitted to the RS, since the client may not have </del>  authenticated yet.  Also note that a counter for the expires_in (exi) claim MUST be initialized when the RS first verifies this token. When sending error responses, the RS MAY use the error codes from <del> section 3.1 of RFC6750, in order to provide additional detail to the client. </del>  5.8.1.2.

Based on the review by Steffi I updated the text in Section 5.8.1.1 "Verifying an Access Token".

specified in RFC8392. In order to facilitate offline processing of access tokens, this  <ins> document uses the "cnf" claim from I-D.ietf-ace-cwt-proof-of- possession and specifies the "scope" claim for JWT- and CWT-encoded tokens. </ins> The "scope" claim explicitly encodes the scope of a given access token.  This claim follows the same encoding rules as defined in 5.8.1.1. When an RS receives an access token, it MUST verify it before storing  <ins> it.  The details of token verification depends on various aspects, including the token encoding, the type of token, the security protection applied to the token, and the claims.  The token encoding matters since the security wrapper differs between the token encodings.  For example, a CWT token uses COSE while a JWT token uses JOSE.  The type of token also has an influence on the verification procedure since tokens may be self-contained whereby token verification may happen locally at the RS while a token-by-reference requires further interaction with the authorization, for example using token introspection, to obtain the claims associated with the token reference.  Self-contained token MUST, at a minimum, be integrity protected but they MAY also be encrypted. For self-contained tokens the RS MUST process the security protection of the token first, as specified by the respective token format.  For CWT the description can be found in RFC8392 and for JWT the relevant specification is RFC7519. In case the token is communicated by reference the RS needs to obtain the claims first.  When the RS uses token introspection the relevant specification is RFC7662 with CoAP transport specified in introspectionEndpoint. Errors may happen during this initial processing stage: If token or claim verification fails, the RS MUST discard the token and, if this was an interaction with authz-info, return an error message with a response code equivalent to the CoAP code 4.01 (Unauthorized). If the claims cannot be obtained the RS MUST discard the token and, in case of an interaction via the authz-info endpoint, return an error message with a response code equivalent to the CoAP code 4.00 (Bad Request). Next, the RS MUST verify claims, if present, contained in the access token.  Errors are returned when claim checks fail, in the order of priority of this list: </ins> The issuer claim must identify an AS that has the authority to issue access tokens for the receiving RS.  If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized).  <ins> The expiration date must be in the future.  If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized).  Note that the RS has to terminate access rights to the protected resources at the time when the tokens expire. </ins> The audience claim must refer to an audience that the RS identifies with.  If that is not the case the RS MUST respond with The RS must recognize value of the scope claim.  If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request).  The RS MAY provide additional  <ins> information in the error response, to clarify what went wrong. </ins> If the access token contains any other claims that the RS cannot process the RS MUST respond with a response code equivalent to the in the error response to clarify which claim couldn't be processed. Note that the Subject (sub) claim cannot always be verified when the  <ins> token is submitted to the RS since the client may not have </ins> authenticated yet.  Also note that a counter for the expires_in (exi) claim MUST be initialized when the RS first verifies this token. When sending error responses, the RS MAY use the error codes from  <ins> Section 3.1 of RFC6750, to provide additional details to the client. </ins> 5.8.1.2.


request, and therefore not stored at the RS. This specification RECOMMENDS that an RS stores only one token per <del> proof-of-possession key, meaning that an additional token linked to the same key will overwrite any existing token at the RS.  The reason is that this greatly simplifies (constrained) implementations, with </del>  respect to required storage and resolving a request to the applicable token.

Feedback from implementers: Section 5.10.1 of the ACE framework uses the term "overwrite" "This specification RECOMMENDS that an RS stores only one token per proof-of-possession key, meaning that an additional token linked to the same key will overwrite any existing token at the RS. The reason is that this greatly simplifies (constrained) implementations, with respect to required storage and resolving a request to the applicable token." and this is mirrored in the OSCORE profile. However, this is not strictly an overwrite of a token because some information in the original token needs to be kept. For example, if the client requests new access rights only using the kid as reference, and the corresponding access token overwrites the original token, then information about the actual key would be lost. Proposed reformulation: "This specification RECOMMENDS that an RS stores only one token per proof-of-possession key. This means that an additional token linked to the same key will supersede any existing token at the RS, by replacing the corresponding authorization information. The reason is that ..."

request, and therefore not stored at the RS. This specification RECOMMENDS that an RS stores only one token per  <ins> proof-of-possession key.  This means that an additional token linked to the same key will supersede any existing token at the RS, by replacing the corresponding authorization information.  The reason is that this greatly simplifies (constrained) implementations, with </ins> respect to required storage and resolving a request to the applicable token.