[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? ===
- [T2TRG] Report from breakout on certificate lifet… Erik Nordmark