Subject: Re: [KEYPROV] DeviceBinding ?

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 26 Jan 2009 14:56:09 +0100

Hannes,
Salah and Anders said that the current sub elements of DeviceInfo were
not enough to satisfy Mobile provisioning use cases hence we added this
element.

Anders and Salah could you please clarify this and see if this is the
best way or maybe we should add more explicit sub-elements to device
info such as IMEI or ....

Thanks,
Philip 

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo)
[mailto:[email-masked]] 
Sent: Saturday, January 24, 2009 11:42 AM
To: ext Pei, Mingliang; Salah Machani; Philip Hoyer;
[email-masked]
Subject: FW: [KEYPROV] DeviceBinding ?

I did not receive a response to my question. Can someone help me to
close this issue? 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Tschofenig, 
>Hannes (NSN - FI/Espoo)
>Sent: 05 January, 2009 22:07
>To: [email-masked]; [email-masked]
>Subject: Re: [KEYPROV] DeviceBinding ?
>
>Hi Rob, 
>
>Thanks for your response and for finding that mail. 
>
>I read through the mail and also looked again at the -06 draft version.
>It says: 
>
>   o  <DeviceBinding> (OPTIONAL), the identifier that can be used to
>      bind keys to the device or class of device.  When loading keys
>      into a device, this identifier can be checked against information
>      obtained from the device to ensure that the correct device or
>      class of device is being used. 
>
>Just to make sure that I correctly understand the idea: 
>
>The <DeviceInfo> element contains a number of child elements 
>that allow to uniquely identify an entity for which the key 
>carried in <Key><Data><Secret> is going to be used. 
>
>There are many different devices and many different usages of PSKC.
>Different devices have different ways to identify them. 
>Ideally, we want to use information elements that allow the 
>key (and additional data) to be associated with the device 
>>>without human interaction<<. (If we assume human 
>interaction, which we don't say in the document, then things 
>are much easier.) Currently, we have a number of elements that 
>can be used: <Manufacturer>, <SerialNo>, <Model>, <IssueNo>, 
><StartDate>, <ExpiryDate>
>
>We don't discuss specific devices in the PSKC document and 
>therefore we don't say that certain elements have to be used 
>with a specific device.
>Different elements may also need to be populated in a specific 
>way (call it encoding).
>
><DeviceBinding> is another element that contains an opaque 
>identifier that fulfills a similar role as, for example, 
><Manufacturer> and <SerialNo>. 
>
>In trying to understand it better may I try to compare it with 
>operating system concepts where software components are 
>registered using a unique identifier, such as a UUID (a 
>128-bit number). When establishing communication to a specific 
>software compontent the UUID is presented. 
>
>Is this roughly the idea you had in mind? 
>
>Do you think that all child elements of <DeviceInfo> should be 
>optional, i.e., one cannot assume one of them to be always 
>present for the sum of the devices we are looking at? (Still, 
>something has to be present to know to what the key is 
>associated with.)
>
>From the current wording you don't assume a specific encoding 
>for the content of the <DeviceBinding> element. Right?
>
>I am trying to figure out whether we can add additional text 
>that allows the reader to understand in what circumstances 
>this element is used and, for the implementer, with what the 
>value in this element should be compared with. Maybe we have a 
>concrete example we could add. 
>
>Does my question make any sense? 
>
>Ciao
>Hannes
>
>>-----Original Message-----
>>From: ext [email-masked] [mailto:[email-masked]]
>>Sent: 05 January, 2009 19:09
>>To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
>>Subject: RE: [KEYPROV] DeviceBinding ?
>>
>>Sorry for the delay in responding to this.  There was a discussion on 
>>the list back in July describing the need for this element and why 
>>existing functionality is inadequate.
>>
>>Rob Philpott
>>RSA, the Security Division of EMC
>>Senior Technologist | e-Mail: [email-masked] | Office: (781)
>>515-7115 | Mobile: (617) 510-0893
>>
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>Behalf Of
>>> Tschofenig, Hannes (NSN - FI/Espoo)
>>> Sent: Friday, December 19, 2008 6:34 AM
>>> To: [email-masked]
>>> Subject: [KEYPROV] DeviceBinding ?
>>> 
>>> I have a question regarding the following element:
>>> 
>>> "
>>> <DeviceBinding>
>>> 
>>> This element carries the identifier that can be used to bind keys to
>>the
>>> device or class of device. When loading keys into a device, this 
>>> identifier can be checked against information obtained from
>>the device
>>> to ensure that the correct device or class of device is being used.
>>> "
>>> 
>>> I am not sure about the purpose of the element and what is
>>actually in
>>> there that makes it different from the already provided PSKC 
>>> functionality.
>>> 
>>> Ciao
>>> Hannes
>>> 
>>> _______________________________________________
>>> KEYPROV mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyprov
>>
>>
>_______________________________________________
>KEYPROV mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyprov
>

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: <[email-masked]>
Date: Mon, 26 Jan 2009 09:39:42 -0500

The issue with trying to rely on more specific sub-elements is that
(primarily in the mobile world) coming up with a small complete set of
elements that can be inquired programmatically from a device is nearly
impossible.

As was mentioned in an earlier email, we require this element in order
to bind a specific provisioning response to a specific request from a
user for a provisioned key. If a policy dictates that a user can
provision a key only to a specific device, the approval process may
require the user to provide a device binding identifier with their
request before it can be approved.  Then the DSKPP/PSKC implementation
can verify that the id's match before completing the request and
installing the key on the device. 

Things such as IMEI or phone # or device serial number are not
consistently available for API access.  Thus it is felt that the general
<DeviceBinding> element could be used to hold the information to be
matched.  The current structure of elements are insufficient.

Rob Philpott 

Behalf Of
> Philip Hoyer
> Sent: Monday, January 26, 2009 8:56 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked];
Salah
> Machani
> Cc: [email-masked]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 26 Jan 2009 18:03:28 +0200

Thank you Rob for your response. 

In your scenario would the user perform this comparison between the
DeviceBinding from the PSKC document and the info the user has
previously received using some out-of-band mechanisms? 

>Sent: 26 January, 2009 16:40
>To: [email-masked]; Tschofenig, Hannes (NSN - 
>FI/Espoo); [email-masked]; [email-masked]
>Cc: [email-masked]
>The issue with trying to rely on more specific sub-elements is 
>that (primarily in the mobile world) coming up with a small 
>complete set of elements that can be inquired programmatically 
>from a device is nearly impossible.
>
>As was mentioned in an earlier email, we require this element 
>in order to bind a specific provisioning response to a 
>specific request from a user for a provisioned key. If a 
>policy dictates that a user can provision a key only to a 
>specific device, the approval process may require the user to 
>provide a device binding identifier with their request before 
>it can be approved.  Then the DSKPP/PSKC implementation can 
>verify that the id's match before completing the request and 
>consistently available for API access.  Thus it is felt that 
>the general <DeviceBinding> element could be used to hold the 
>information to be matched.  The current structure of elements 
>are insufficient.
>
>Rob Philpott
>> >[mailto:[email-masked]] On Behalf Of ext 
>Tschofenig, Hannes 
>> >(NSN - FI/Espoo)
>> >The <DeviceInfo> element contains a number of child elements that 
>> >allow to uniquely identify an entity for which the key carried in 
>> ><Key><Data><Secret> is going to be used.
>> >
>key (and 
>> >additional data) to be associated with the device
>> >interaction, which we don't say in the document, then 
>things are much 
>> >easier.) Currently, we have a number of elements that can be used: 
>> ><Manufacturer>, <SerialNo>, <Model>, <IssueNo>, <StartDate>, 
>> ><ExpiryDate>
>> >
>therefore 
>> >we don't say that certain elements have to be used with a specific 
>> >device.
>> >Different elements may also need to be populated in a specific way 
>> >(call it encoding).
>> >
>identifier 
>> >that fulfills a similar role as, for example, <Manufacturer> and 
>> ><SerialNo>.
>> >
>> >operating system concepts where software components are registered 
>> >using a unique identifier, such as a UUID (a 128-bit number). When 
>> >establishing communication to a specific software 
>compontent the UUID 
>> >is presented.
>> >
>> >optional, i.e., one cannot assume one of them to be always present 
>> >for the sum of the devices we are looking at? (Still, something has 
>> >to be present to know to what the key is associated with.)
>> >
>> >From the current wording you don't assume a specific 
>encoding for the 
>> >content of the <DeviceBinding> element. Right?
>> >
>> >I am trying to figure out whether we can add additional text that 
>> >allows the reader to understand in what circumstances this 
>element is 
>> >used and, for the implementer, with what the value in this element 
>> >should be compared with. Maybe we have a concrete example we could 
>> >add.
>> >

---

From: <[email-masked]>
Date: Mon, 26 Jan 2009 11:27:36 -0500

It isn't typically a user that would verify the info.  In our scenario,
we want to ensure that the user isn't trying to load the key into a
device that it was not approved to be loaded into.  For example, I may
allow loading the key into a laptop that is storing it into a TPM, but
not allow loading into one that is storing it on disk. So it is the
application that is loading the key into the client that would verify
that the DeviceBinding info that came in the package matches the
identifier the identifier on the device.

This scenario might apply more to non-DSKPP distribution mechanisms for
the PSKC package (e.g. file xfer or email attachment. But it is also
important in the DSKPP case as well.

Make sense?

Rob Philpott 

> Sent: Monday, January 26, 2009 11:03 AM
> To: Philpott, Robert; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> >> >>Sorry for the delay in responding to this.  There was a
discussion
> >on
[mailto:[email-masked]]
> >On
> >> >>> This element carries the identifier that can be used to bind
keys
> >to