Re: [Ace] Terms to avoid

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Fri, 13 December 2013 12:14 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCB01A1F7D for <ace@ietfa.amsl.com>; Fri, 13 Dec 2013 04:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.177
X-Spam-Level:
X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 e5CsUAXqElZW for <ace@ietfa.amsl.com>; Fri, 13 Dec 2013 04:14:50 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 370161A1F5E for <ace@ietf.org>; Fri, 13 Dec 2013 04:14:50 -0800 (PST)
Received: from 3capp-gmx-bs24.server.lan ([172.19.170.76]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LbfGf-1V6n960Q15-00lEb3 for <ace@ietf.org>; Fri, 13 Dec 2013 13:14:43 +0100
Received: from [217.140.96.21] by 3capp-gmx-bs24.server.lan with HTTP; Fri Dec 13 13:14:43 CET 2013
MIME-Version: 1.0
Message-ID: <trinity-9d582751-d593-4ef3-a062-e03bdf2a63de-1386936882917@3capp-gmx-bs24>
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: sarikaya@ieee.org
Content-Type: text/html; charset="UTF-8"
Date: Fri, 13 Dec 2013 13:14:43 +0100
Importance: normal
Sensitivity: Normal
In-Reply-To: <CAC8QAcfbYjBrWO8pitHUYr=oq9WD6vkkjJ69vfiK+1oTjW7Uig@mail.gmail.com>
References: <trinity-8553dce2-e064-4ed4-8774-fe3a04fc2bb7-1386874286879@3capp-gmx-bs21> <B9A7B5DA-ED8E-4507-8424-FC093C029D19@tzi.org>, <CAC8QAcfbYjBrWO8pitHUYr=oq9WD6vkkjJ69vfiK+1oTjW7Uig@mail.gmail.com>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K0:mnz5SbTIKDFzLxCt8Bo2EYqCsv6+/q/gWUd4bHbaS2Q Bxk4skTw3t4rayD4gHlKPUDcy3lth08LDEX77cZTeDBHXqjA31 cINUOToiEdkWdC1tjZVewStBNGZQONMAho8vzo7LyfqAHzHNgo qTiDdqgSR27E1YpfkUJOiVQkj+dSjF/N/iAuc0OnBNvUtQ6Fhv A3BdQGFsP1JN/jxo2bx7dT44IPtXCDX4osUZxOUE1fyjPM5ori RUmS+a1/65gnL+BDFDADPWLvkkLki0U4sgaXaIIfI8VIaWr/jS gv6TmI=
Cc: Carsten Bormann <cabo@tzi.org>, ace@ietf.org
Subject: Re: [Ace] Terms to avoid
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 12:14:53 -0000

The response I get from both of you shows me already that there is a problem. 
 
Behcet responded that it is "Bootstrapping is any processing required before the network can operate." 
This is obviously incredibly broad although his draft only says that we should leverage the AAA architecture (which is a perfectly fine thing to say as a solution). The AAA framework does not speak about bootstrapping and so one might one why it was possible to get away without that term back on those days. 
 
Carsten says: "Bootstrapping is not a method, it is an objective, which can be pinpointed pretty precisely in the lifecycle of a device.
More specifically, it relates to achieving the transition from a sparse or minimal, pre-operational set of authenticated authorizations to a set that can be used operationally."
 
Carsten, you are pointing to a lifecycle that seems to be universally agreed. Where is that lifecycle? The definition you offer is also vague and IMHO does not help to guide the work in the group. 
 
Let me try a different approach. There are two basic approaches that I have seen so far in context of security relevant to this debate: 
 
1) You already have a secret pre-provisioned on the device. You want to leverage that existing secret to access new services. This is what this key distribution / key establishment stuff is all about. This is the typical three party protocol (that some of the referenced documents use). Examples I have seen are Behcet's AAA proposal, or the OAuth flavor of draft-selander-core-access-control. Kerberos belongs to that category as well and so would models with certificates (where the trusted third party is the CA that issues the certificates). 
 
2) You have no secret pre-provisioned. The approaches here are sometimes referred as imprinting or pairing.  The solutions often make use promitity techniques that require user involvement and their approach varies hugely depending on the hardware capability of the device. You can find a short summary at the smart object security workshop (see http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop-02#section-3.4) and obviously a lot of literature on that subject. 
 
It seems that the charter focuses on (1). If that's the case you should say that. 
 
Assuming the group wants to go for #1 then the aim of the group is to look at existing key distribution protocols and see which one fits best to the IoT environment. Maybe there are some additional requirements that require extensions (or even a completely new protocol?!?). 
 
One important implication of going for (1) is that there is obviously this key distribution center (KDC)/AAA server/CA/authorization server that needs to be somewhere (although it does not need to be in the local network). I was wonder whether folks have become aware of that since it may feel a bit foreign in some of the scenarios (just think about having a KDC or a AAA server in your home, for example). 
 
Ciao
Hannes
 
Gesendet: Donnerstag, 12. Dezember 2013 um 22:22 Uhr
Von: "Behcet Sarikaya" <sarikaya2012@gmail.com>
An: "Carsten Bormann" <cabo@tzi.org>
Cc: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, ace@ietf.org
Betreff: Re: [Ace] Terms to avoid
Hi Carsten,
 
Thanks for the clarification.
 
I completely agree with you.
I was having nightmares on how to replace bootstrapping.
 
Regards,
 
Behcet
 
On Thu, Dec 12, 2013 at 4:17 PM, Carsten Bormann <cabo@tzi.org" target="_parent" rel="nofollow">cabo@tzi.org> wrote:
On 12 Dec 2013, at 19:51, Hannes Tschofenig <Hannes.Tschofenig@gmx.net" target="_parent" rel="nofollow">Hannes.Tschofenig@gmx.net> wrote:

> Could you guys do me a favor and avoid two terms in your drafts:
>
> 1) Bootstrapping
> 2) Trust
 
I completely agree about the term “Trust”.  This is neither an objective nor a method.
When people talk about “trust” they usually either talk about the ability to authenticate something and/or an authorization relationship, but it is rarely fully fleshed out what specifically is meant.
(Some, but not all, of the uses of the term “certificate” are of the same kind.)
Device B doesn’t “trust” device A, but device A is authorized to perform certain, well-defined operations on or relevant for device B, and that authorization (as well as the origin of the operation and/or communication channels) can be authenticated in the course of performing the operation.

I don’t agree about not using bootstrapping.  Bootstrapping is not a method, it is an objective, which can be pinpointed pretty precisely in the lifecycle of a device.
More specifically, it relates to achieving the transition from a sparse or minimal, pre-operational set of authenticated authorizations to a set that can be used operationally.
(Key establishment is usually part of what needs to be done there, but the keys just serve to authenticate the authorizations, so I’m not even sure they are very important for defining bootstrapping.)

I’m sorry for this dense terminology attack, but I agree that we need to work on some of the terminology now to generate a credible charter.

Grüße, Carsten

_______________________________________________
Ace mailing list
Ace@ietf.org" target="_parent" rel="nofollow">Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/ace