Re: [Anima] Ownership Concept

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 26 March 2015 18:59 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374461A8792 for <anima@ietfa.amsl.com>; Thu, 26 Mar 2015 11:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level:
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 yrD7v8VN205B for <anima@ietfa.amsl.com>; Thu, 26 Mar 2015 11:59:30 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555A31A901D for <anima@ietf.org>; Thu, 26 Mar 2015 11:59:30 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EE61620421 for <anima@ietf.org>; Thu, 26 Mar 2015 15:09:27 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 58BA063B76; Thu, 26 Mar 2015 14:59:29 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 393E563731 for <anima@ietf.org>; Thu, 26 Mar 2015 14:59:29 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "anima@ietf.org" <anima@ietf.org>
In-Reply-To: <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com> <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 26 Mar 2015 14:59:29 -0400
Message-ID: <13229.1427396369@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/1tbPEoQybGFyKrVhlazIQmJ8F9g>
Subject: Re: [Anima] Ownership Concept
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 18:59:32 -0000

Max Pritikin (pritikin) <pritikin@cisco.com> wrote:
    > I don’t understand how one can expect the backend to be totally
    > “optional” since the device doesn’t know if it should be optional or
    > not. The best I think we can do is make the backend “no decision” and
    > “air gap compliant”. But if the device itself is willing to make the
    > back end optional thats like saying that the end device has a trivial
    > downgrade attack.

I have read this thread.
Unfortunately, I missed the discussion at the session, as I had to present in
6lo at that time.

I don't see a conflict between MASA and no-MASA.  Both are valid, legitimate
security models, and business models.

In the certificate based ownership mechanism (I hesitate to call it a
protocol), that I envision, the MASA function defends against certain kinds
of attacks, and enables other kinds of attacks.

A MASA may be operated by either a vendor or their supply chain delegate.
As such, it is subject to various attacks: National Security letters,
takeovers (friendly and hostile), etc.  The existence of the MASA provides
a way to detect, or prevent, transfers from one owner to another.  Some
device claim mechanisms may include knowledge of a pre-shared (symmetric)
key (such as might come from a QRcode on the packaging).  That key, if
disclosed in the supply chain, can enable logical device theft.

A MASA could also in some cases be operated by a sophisticated end user.
How the trust relationship to do so is setup depends upon some details that
need to be worked out, but not here.

Solutions without a MASA have the advantage that MASA do not need to be
available.  This isn't just about network "availability", but also about
business continuity.  A device that sits in a warehouse for 20 years should
not have to depend the company that made it still existing at the same
address. (I saw a closet full of Nortel Meridian spare parts last week...)

Solutions without a MASA enable the end owner to decide how/when to
resell/transfer the device to another owner. This is a transaction that the
MASA can prevent.  (Reselling things is business as usual for some, and theft
to other vendors)  The solution I describe at:
  https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

has a potential flaw: a previous owner, and any supplier in the supply chain
could assert their ownership certificate again, and steal the device "back"
From the end user.  This happens if either you do not replace the 802.1AR
certificates with locally significant certificates.  (If you merely augment
the 1AR with a LDevID, then the originally UDevID may be still useable)
This may be a "feature" --- it means that you can call up the guy who sold
you the device, and get their help to "reset your password".

In the scenario that I describe above, using 1AR certificates with an
extension like I describe at
          http://datatracker.ietf.org/doc/draft-richardson-6tisch-idevid-cert/

one can operate this online or offline. The certificate could be shipped
with the device when you buy it.  It could also be generated online from a
MASA-type device based upon a one-time token that you provide to the MASA
device (along with the public key you want to have bound).
It could be that the work in ACME applies as well here.

I suggest that a virtual interim meeting would be appropriate soon.

-- 
]               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    [