M. Ranganathan <mra...@gmail.com> wrote:
> There are scenarios involving device onboarding where Captive Portal
> capability seems like a good fit.
> Consider a device that has been securely onboarded onto a network. The
> device wants to present a signed credential to the network (e.g. it
> could present its signed MUD URL) that can be evaluated challenged by
> the captive portal server.
> Following up on a suggestion by Michael Richardson, can the Captive
> Portal API be extended to do this?
I think that there are two important things here:
1) the capport interface provides a high-level (vs low-level RA) interface
between a
host and the operator of the network.
--> new interfaces can be offered by extending the json file.
2) networks that have devices that use RFC8520(MUD), will want to run capport
in order to be able to communicate the fact that device has been quarantined.
{I think that I owe an ID on this concept}
> 1. Device onboards and presents its certificate, and signed MUD URL to
> the captive portal server.
If the onboarding mechanism uses an IDevID, then that part has already been
communicated. The MUD URL can be embedded into the IDevID certificate, and
the URL is signed by the *manufacturer*, not the device itself.
The device proves who it is by possession of private key.
This is different than the DHCP mechanism for MUD, which is entirely under
control of the device, and thus the malware.
> 2. Captive portal server verifies the
> certificate using the manufacturer certificate.
> 3. If certificate and
> signature are valid, then Captive Portal server removes the device from
> quarantine and allows it onto the network. It could optionally
> challenge the device to authenticate it but presumably that step has
> already been done during onboarding.
I don't think that we should do these things with the captive portal.
> Another situation where captive portal could be useful is BRSKI. Not
> sure if these use cases are too far removed from the intended use of
> this specification.
I don't think this is quite the direction I had in mind.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
