Subject: [T2TRG] Device Identity

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Apr 2016 22:24:48 +0200

In his presentation Mohit used the term 'Device Identity'.

I have heard this term in various conversation over the past few years
and I have the fear that there are different interpretations what it means.

What does it mean for you, Mohit?

Ciao
Hannes

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 7 Apr 2016 17:57:57 -0300

Hi

As my slides pointed out, there are a bunch of definitions for both 
bootstrapping as well device identity. If anyone wants to point to 
different interpretations on the list, we will be happy to discuss them 
in the survey draft. The draft does not intend to select one definition 
over the other. Perhaps we don't want to get bogged down in the 
discussion on the philosophical differences between identifier and 
identity etc. and rather consider the practical use of identifiers.

Regards
Mohit

On 04/07/2016 05:24 PM, Hannes Tschofenig wrote:
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Apr 2016 23:22:10 +0200

Hi Mohit,

there is no definition of device identity (or identity) in your draft
<draft-sarikaya-t2trg-sbootstrapping>. Hence, I am asking.

Ciao
Hannes

PS: Btw, I wrote a document for the ACE working group that gives an
overview as well:
https://tools.ietf.org/html/draft-tschofenig-ace-overview-00

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 12 Apr 2016 14:34:38 -0500

Hi Hannes,

Thanks for pointing out  the ace-overview draft.
Having taken a look at it, I don't see a definition of identity there either.

I am not sure how much identity is relevant to the secure bootstrapping.

Regards,

Behcet

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Apr 2016 12:11:29 +0200

Btw, I noticed that the GBA text from
https://tools.ietf.org/html/draft-tschofenig-enroll-next-steps-00 and
the text from
https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 could help
you to get to a survey in draft-sarikaya-t2trg-sbootstrapping much quicker.

Regarding 'identity' it is hard to say whether it is relevant since it
is not defined yet. Mohit mentioned it in his presentation and hence I
have been wondering about it.

In my discussions it turns out to be useful to distinguish two types of
processes:
 (a) initial establishment of keys and configuration information
 (b) subsequent provisioning of keys and configuration information

The OIC/OCF, for example, uses the term onboarding for (a) and
bootstrapping for (b). Some specification consider (a) out of scope and
assume that this information is manufacturer provisioned.

Ciao
Hannes

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 Apr 2016 13:18:55 +0200

Hi,

I'm a bit new to T2TRG, so please forgive me if this is well trodden ground.

The notion of device identity depends on what we mean by a device or
thing, if you will.  More precisely, how does one determine whether
something is a component or a network element unto itself?  Must a thing
have an IP or 6lopan-based stack?  These are surely things this RG has
covered.

The IEEE does have a standard for device identity, which is IEEE
802.1AR.  While it may not be perfect, it is something upon which to
build.  If I might channel my friend John Strassner for a moment,
however, device identity is probably meaningless without some notion of
attributes.  802.1AR could cover that ground nicely through
constraints.  As we presented in several places last week, MUD[1]
borrows from AR to make use of constraints.

The problem with .AR of course is that it requires at least the basics
of a PKI to establish the validity of an identity.  There is work in the
ANIMA working group to do just that in a bilateral way.[2]

The network goal is quite simple:

  * Identify the element sufficiently to establish an appropriate posture.

Someone MUST take responsibility for an element's behavior in that
process.  In this sense, a possible – albeit counter-intuitive –
definition of a thing could be that it is sufficiently robust to provide
necessary identity assertion to others, and in particular the network. 
Otherwise it could be viewed as a component of a thing.

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Apr 2016 15:08:43 +0200

I am not sure about the value of IEEE 802.1AR

It says: Provision devices with X.509 certificates (either RSA or ECC)
and the spec defines a MIB for configuration.

It also lists the fields of a certificate and defines the "device
identity" in Section 7.2.8 as "This may include the unique device serial
number assigned by the manufacturer or any other suitable unique DN
value that the issuer prefers."

So, it essentially does not say what the identifier is in the certificate.

In the context of this discussion I believe it would be better to just
say use the term credential instead. Credentials contain identifiers and
attributes.

If we only want to talk about certificates (which I doubt in the IoT
context) then we should just be specific and refer to end entity
certificates and trust anchors.

Ciao
Hannes

PS: As we tried to explain in
https://tools.ietf.org/html/draft-fossati-core-server-name-id-00 the use
of certificates (and specifically the identifiers used in there) raises
challenges in some IoT deployments. For this (and other reasons) I am
arguing that X.509 certificates are not a good choice of technology for
come IoT deployments.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Apr 2016 15:12:10 -0500

> I am not sure about the value of IEEE 802.1AR

+1

Behcet

---

From: Paul Lambert <[email-masked]>
Date: Thu, 14 Apr 2016 00:55:45 +0000

I'm a bit new to T2TRG, so please forgive me if this is well trodden ground.
Yes, but new paths should be considered that are not as well traveled.

The notion of device identity depends on what we mean by a device or thing, if you will.  More precisely, how does one determine whether something is a component or a network element unto itself?  Must a thing have an IP or 6lopan-based stack?  These are surely things this RG has covered.
Addresses should be considered 'attributes'  of an entity and not the base identity.

The IEEE does have a standard for device identity, which is IEEE 802.1AR.  While it may not be perfect, it is something upon which to build.  If I might channel my friend John Strassner for a moment, however, device identity is probably meaningless without some notion of attributes.  802.1AR could cover that ground nicely through constraints.  As we presented in several places last week, MUD[1] borrows from AR to make use of constraints.

The problem with .AR of course is that it requires at least the basics of a PKI to establish the validity of an identity.  There is work in the ANIMA working group to do just that in a bilateral way.[2]

 ... 802.11AR is not the right path.

A 'key centric' architecture is a better direction (IMHO).  Public keys and ways to create a identifier for a public key are a simple and scaleable starting point.

Paul

Someone MUST take responsibility for an element's behavior in that process.  In this sense, a possible - albeit counter-intuitive - definition of a thing could be that it is sufficiently robust to provide necessary identity assertion to others, and in particular the network.  Otherwise it could be viewed as a component of a thing.

Eliot

Hi Hannes,

Regards,

Behcet

On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig
<[email-masked]><mailto:[email-masked]> wrote:

Hi Mohit,

Ciao
Hannes

Hi

Regards
Mohit

Ciao
Hannes

_______________________________________________
T2TRG mailing list
[email-masked]<mailto:[email-masked]>https://www.irtf.org/mailman/listinfo/t2trg

_______________________________________________
T2TRG mailing list
[email-masked]<mailto:[email-masked]>https://www.irtf.org/mailman/listinfo/t2trg

_______________________________________________
T2TRG mailing list
[email-masked]<mailto:[email-masked]>https://www.irtf.org/mailman/listinfo/t2trg

_______________________________________________
T2TRG mailing list
[email-masked]<mailto:[email-masked]>https://www.irtf.org/mailman/listinfo/t2trg

---

From: Hasan Derhamy <[email-masked]>
Date: Thu, 14 Apr 2016 06:23:41 +0000

Hi,

Do you have any reading material regarding 'key centric' architecture used as identity?

-Hasan

From: T2TRG [mailto:[email-masked]] On Behalf Of Paul Lambert
Sent: den 14 april 2016 02:56
To: Eliot Lear; [email-masked]; Hannes Tschofenig
Cc: Mohit Sethi; [email-masked]
Subject: Re: [T2TRG] Device Identity

Paul

Eliot

Hi Hannes,

Regards,

Behcet

Hi Mohit,

Ciao

Hannes

overview as well:

Hi

Regards

Mohit

Ciao

Hannes

T2TRG mailing list

T2TRG mailing list

T2TRG mailing list

T2TRG mailing list

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 14 Apr 2016 08:11:15 +0000

FWIW - the IEEE 802.1 Security TG is engaged in the transition of the management interface from SMIv2 MIB modules used to SNMP to YANG modules which can be used with NETCONF and RESTCONF. So the 'MIB for configuration' aspect will be sometimes probably soon Historical. 

Regards,

Dan

> -----Original Message-----
> From: T2TRG [mailto:[email-masked]] On Behalf Of Hannes
> Tschofenig
> Sent: Wednesday, April 13, 2016 4:09 PM
> To: Eliot Lear; [email-masked]
> It says: Provision devices with X.509 certificates (either RSA or ECC) and the
> spec defines a MIB for configuration.
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 14 Apr 2016 23:03:35 +0200

Hi Hannes,

> So, it essentially does not say what the identifier is in the certificate.

That's only a problem if and only if the following are true:

 1. One has a need to treat the subject contents in other than an opaque
    form; AND
 2. Anything other than a manufacturer site or tool needs to parse that
    subject.

I add that last point because the key bootstrapping draft anticipates,
but does not require, that (2) is not true.

> certificates and trust anchors.

And these are the points that are worth exploring.  If the best we can
say is that the device hold a credential, we haven't really said much. 
Credentials come in many forms.  While it is true that credentials can
be characterized as having attributes, many are highly limited.  A
credential could be of the form username/password, for instance, but as
we all know, that doesn't scale.  This may just go to use and
requirements.  But if a manufacturer wants to assert anything about the
Thing, then those assertions must be authenticated somehow.  For
admission purposes, the network needs the manufacturer to assert
probably two things: *some* form of identifier, probably unique; and
what class of thing that is.  I like a resolvable URI.  Others may differ.

> arguing that X.509 certificates are not a good choice of technology for

And I might agree, for some deployments, if something better presented
itself or it could be shown that admission could be handled in some
other way.  The draft you mention specifies a new SAN.  But perhaps you
have other ideas for that identifier?

Eliot

---

From: Mohit Sethi <[email-masked]>
Date: Wed, 27 Apr 2016 13:52:06 +0300

Hi Hannes

During the presentation of the IoT security bootstrapping survey draft 
you pointed out that the current definition of bootstrapping in the 
draft is not to your liking. You also pointed out that OIC/OCF has a 
better definition.

To help the authors prepare the next version, could you kindly provide 
this definition by OIC/OCF (and any other definitions which you deem 
relevant).

Thanks
--Mohit