Re: [Captive-portals] Onboarding devices and Captive Portal API

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 01 February 2020 13:30 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD0D120100 for <captive-portals@ietfa.amsl.com>; Sat, 1 Feb 2020 05:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tX8Bf_7FOTJ for <captive-portals@ietfa.amsl.com>; Sat, 1 Feb 2020 05:30:05 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A99612004D for <captive-portals@ietf.org>; Sat, 1 Feb 2020 05:30:05 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:1810:f051:b5d3:c826:67dc:3e5a]) by relay.sandelman.ca (Postfix) with ESMTPS id 1054B1F45B; Sat, 1 Feb 2020 13:30:03 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 499711A3529; Sat, 1 Feb 2020 14:30:01 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "M. Ranganathan" <mranga@gmail.com>
cc: captive-portals@ietf.org
In-reply-to: <CAHiu4JP8ZyXFXNODLspsobfoSiViCAQZDBsyF942oSqe6H8rBg@mail.gmail.com>
References: <CAHiu4JP8ZyXFXNODLspsobfoSiViCAQZDBsyF942oSqe6H8rBg@mail.gmail.com>
Comments: In-reply-to "M. Ranganathan" <mranga@gmail.com> message dated "Fri, 31 Jan 2020 09:15:44 -0500."
X-Mailer: MH-E 8.6; nmh 1.7.1-RC3; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sat, 01 Feb 2020 14:30:01 +0100
Message-ID: <10571.1580563801@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/d5-_k_JSILzESlSJqPittjoc75s>
Subject: Re: [Captive-portals] Onboarding devices and Captive Portal API
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2020 13:30:07 -0000

M. Ranganathan <mranga@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  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [