[T2TRG] Report from breakout on certificate lifetimes for long-lived devices

Erik Nordmark <nordmark@acm.org> Fri, 21 April 2017 21:25 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7604C129AD8 for <t2trg@ietfa.amsl.com>; Fri, 21 Apr 2017 14:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 Q7wrjoL3ZQl0 for <t2trg@ietfa.amsl.com>; Fri, 21 Apr 2017 14:25:38 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E9E127867 for <t2trg@irtf.org>; Fri, 21 Apr 2017 14:25:38 -0700 (PDT)
Received: from [192.168.254.146] (72-172-185-194.bayarea.net [72.172.185.194]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v3LLPXVT006290 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Apr 2017 14:25:34 -0700
To: t2trg@irtf.org
From: Erik Nordmark <nordmark@acm.org>
X-Forwarded-Message-Id:
Message-ID: <28f66c1e-02d6-7efe-3d7c-c65c964edbcd@acm.org>
Date: Fri, 21 Apr 2017 14:25:33 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sonic-CAuth: UmFuZG9tSVbg02FaVkSqBorwDJIjY+RPnCGh/iL6X+ut7SRQ/5jW9IVpiBkBUx8diqfvFIlfNasGWIVofx4La+UyEJmYg8+Rd8fot3gZwYU=
X-Sonic-ID: C;kNanDdkm5xGFZizL7bdh1w== M;QB0VDtkm5xGFZizL7bdh1w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/79FTQLiXZd1vM9Fj3Lj2gCmorPw>
Subject: [T2TRG] Report from breakout on certificate lifetimes for long-lived devices
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 21:25:39 -0000

Report from t2trg breakout session, 2017-03-27.

Topic: Breakout on certificate lifetimes for long-lived devices

Thanks to Mohit Sethi for taking notes.

Participants who wrote their name: Erik Nordmark (lead), Mohit Sethi (note
taker), Robert Sparks, Anorow Auow (sp?), Barry Leiba, Alper Yegin,
Dominique Barthel, Thorsten Dahm, Elliot Lear, Phillip Hallam-Baker

The questions we asked ourselves was examplified by “What would it mean to
configure some remote certificates on a device which then sits in a drawer
for 2 years and will then be expected to be deployed for 10 years, when
the lifetime of that certificate is 1 year?”

 From that starting point the group explored different aspects of 
security for
long-lived devices.

One question was whether the device lifetime be the same as device 
certificate
lifetime, and folks seemed to say that if the certificate expires the device
would be likely to be bricked.

What does it mean to have a device lifetime? The lifetime of the local state
vs. the state in the cloud could be different. Would the cloud forget 
about the
existence of the device after the lifetime? Or can we assume that the 
state in
the cloud lives forever?

One question was around the purpose of the device certificate. If you 
only use
it for saying the device was manufactured by X and it doesn't give you 
access
to the network, then its OK to never revoke.

But can you update the device cert if the curve is compromised?
And would such an attack give access to a single device vs. all of them?

For the device that sits in the drawer for 2 years, an observation when it
connects it might find that it has out-of-date software, hence need to 
update
itself before proceeding.
Might want to get a notification that an old device is being turned on.
But there could also be deployment keys in that old device that have 
been compromised
while it was in the drawer.

Research/hard questions:
  - What do we want to use the cert or credentials to be used for?
  - How many certs/credentials you need?
    Manufacturer vs "User" certificates.
  - Privacy issues? Long term certs? Can I track the device across owners?
  - Trade-off for disconnected devices whether in drawer or not?

===