Subject: Re: [core] RawPublicKeys

From: Alper Yegin <[email-masked]>
Date: Mon, 19 Dec 2011 12:25:42 +0200

This issue and what Rene brought up appear to be still open…
Any thoughts, folks?

On Nov 18, 2011, at 3:21 AM, Alper Yegin wrote:

> Hi Carsten,
> 
> On Nov 17, 2011, at 7:15 PM, Carsten Bormann wrote:
> 
>> On Nov 17, 2011, at 23:22, Alper Yegin wrote:
>> 
>>> The above text explains how the network node authenticates/authorizes the device.
>>> But, how does the device authenticate/authorize the network node? For that, the "identity" of the network node's public key needs to be known to the device. But how?
>> 
>> Hi Alper,
>> 
>> what is a "network node" in the context of CoAP?
>> (I read "device" to include both the client and server roles, so from the point of CoAP, there is nothing else.  But maybe I'm missing something here.)
>> 
> 
> 
> In the context of a "home deployment" for example, the network node is the home gateway that one needs to configure when bringing in a new device to home. ACL on the home gateway needs to be updated with the device ID for access control. But this is just one side of the story. The other side is, how does the new device identify the network (the home gateway)?
> 
> 
> 
>> Grüße, Carsten
>> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Rene Struik <[email-masked]>
Date: Mon, 19 Dec 2011 12:15:53 -0500

Dear colleagues:

For your convenience,  I copied below the issue that Alper Yegin
attributed to me and that I brought up originally during IETF-82 (Thu
Nov 17th).

Perhaps, we can reflect on this after the New Year. Meanwhile, I wish
you all a Happy Christmas and an inspirational and creative 2012.

Best regards, Rene

-------- Original Message --------
Subject: 	Re: [core] RawPublicKeys
Date: 	Thu, 17 Nov 2011 10:50:40 -0500
From: 	Rene Struik <[email-masked]>
To: 	Alper Yegin <[email-masked]>
CC: 	core WG <[email-masked]>

Dear colleagues:

Alper's question definitely has merit. I have another one, though:

Having public-key derived identities printed on a device presumes that a
device's public key will never change over its lifecycle. Moreover, it
assumes that the public key is available prior to printing the bar code.

Could you please explain how this would work from a lifecycle
perspective? (chip production, module manuacturing, public key
"registration", "certification", "revocation", etc.)
[Note - even if public keys are not certified by a CA using a
certificate, one should still consider
registration/certification/revocation, aspects]

These devices are assumed to have no trusted platform on board. What if
someone else clones a device, produces a million copies, and pollutes
the market place this way (one of the scenarios described in
draft-garcia-core-security-03 (Section 3.1)). It seems that one is just
out of luck then.

>From the text in Appendix D.1 it seems one just hashes bare public keys,
without any policy oriented info or time validity period. How does this
relate to security policies? What are those policies?

Rene

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 20 Dec 2011 12:33:27 +0200

Hi Rene, Hi Alper, 

Thank you for the question. 

You both are asking of how the trust infrastructure for smart objects could work. 

There are a few independent aspects, namely: 

1.      How to bind a name to a key

2.      What are the policies associated with a key (such as lifetime)

3.      What to use the key for

4.      How to create an access control list

One possible design that some of you had mentioned to me is to print the fingerprint of the public key on the device(sensor) and to then, when you introduce the device into your network, to verify the fingerprint on the device with the value shown on the server for inclusion in the access control list. This works nicely in a smaller environment, such as a home network. 

In such a scenario the fingerprint is the name of the key, it may not be anticipated to change the key (because it is "hardwired" into the device), the usage is limited to the functionality of the device and the key is added to the ACL based on human involvement. 

For other scenarios this may not be good enough. If you have additional requirements then you those will lead to more complexity, more code, and additional performance requirements. There is no free lunch. 

When it comes to documenting some of these aspects I doubt that there is a desire to develop a one-size-fits-all solution. Leaving everything open may not be useful either.

So, what could you do? 

I believe it makes sense to 

·        Develop some building blocks, as we are already doing. For those it will be difficult to specify a mandatory-to-implement security solution. 

·        Document at least one architectural description to see how the different building blocks actually work together and that there are no gaps. Jari had made one attempt with http://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01. Maybe there is a possibility to do better?! 

Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Rene Struik
Sent: Monday, December 19, 2011 7:16 PM
To: Alper Yegin
Cc: core WG
Subject: Re: [core] RawPublicKeys

Dear colleagues:

For your convenience,  I copied below the issue that Alper Yegin attributed to me and that I brought up originally during IETF-82 (Thu Nov 17th).

Perhaps, we can reflect on this after the New Year. Meanwhile, I wish you all a Happy Christmas and an inspirational and creative 2012.

Best regards, Rene

 
This issue and what Rene brought up appear to be still open...
Any thoughts, folks?

-------- Original Message -------- 

Subject: 

Re: [core] RawPublicKeys

Date: 

Thu, 17 Nov 2011 10:50:40 -0500

From: 

Rene Struik <[email-masked]> <mailto:[email-masked]> 

To: 

Alper Yegin <[email-masked]> <mailto:[email-masked]> 

CC: 

core WG <[email-masked]> <mailto:[email-masked]> 

Dear colleagues:

Having public-key derived identities printed on a device presumes that a device's public key will never change over its lifecycle. Moreover, it assumes that the public key is available prior to printing the bar code. 

Could you please explain how this would work from a lifecycle perspective? (chip production, module manuacturing, public key "registration", "certification", "revocation", etc.) 
[Note - even if public keys are not certified by a CA using a certificate, one should still consider registration/certification/revocation, aspects]

These devices are assumed to have no trusted platform on board. What if someone else clones a device, produces a million copies, and pollutes the market place this way (one of the scenarios described in draft-garcia-core-security-03 (Section 3.1)). It seems that one is just out of luck then.

>From the text in Appendix D.1 it seems one just hashes bare public keys, without any policy oriented info or time validity period. How does this relate to security policies? What are those policies?

Rene

 

	Hi Carsten,

		Hi Alper,

	 

	 

		Grüße, Carsten

---

From: Alper Yegin <[email-masked]>
Date: Wed, 21 Dec 2011 11:29:45 +0200

Hi Hannes,

On Dec 20, 2011, at 12:33 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> In such a scenario the fingerprint is the name of the key, it may not be anticipated to change the key (because it is “hardwired” into the device), the usage is limited to the functionality of the device and the key is added to the ACL based on human involvement.

The issue I'm raising is that, there story has two sides. We gotta be talking about not only how the network authorizes the device, but also how the device authorizes the network. What you describe above is the former, latter one is missing.

It's not like the device will/shall be OK to talk to anyone who wants to talk to itself. Device needs to authenticate and authorize the other end as well, using ACLs etc. 

How do we introduce the ACL into such devices? There's gotta be an interface for that.

Note that this is an issue for asymmetric-crypto. With the symmetric crypto, device can assume whoever holds the same PSK is already authorized hence I don't also need to maintain an ACL. Symmetric crypto has other issues though (e.g., how did you get the PSK here and there?)

Alper

> ·        Document at least one architectural description to see how the different building blocks actually work together and that there are no gaps. Jari had made one attempt withhttp://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01. Maybe there is a possibility to do better?!
>  
>  
> Ciao
> Hannes
>  
> Rene Struik <[email-masked]>
> To:
> Alper Yegin <[email-masked]>
> CC:
> core WG <[email-masked]>
> 
> 
> Dear colleagues:
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 21 Dec 2011 11:58:16 +0200

Hi Alper, 

Thanks for the quick feedback. See my comments below. 

~snip~

With the work on TLS raw public key and the cached information extension I was actually more focusing on the communication between two applications rather than security for network access authentication. 

But your issue is also valid for an application scenario and the answer depends a bit on the device capabilities itself and the expected behavior. 

For example, with a picture frame you have a UI and with a temperature sensor you probably don't have one. With an Internet radio you have a small UI and actually, for more elaborate configuration, you can also connect to the device via a Web browser. Some devices have certain parameters pre-configured (like my Internet radio fetches a list of available Internet radio stations from a pre-configured URL). 

So, there is no single answer. It really varies a lot but maybe you can cluster the different scenarios in some form to offer a meaningful description.  

It depends. When I look at Jari's draft then I believe his model is more than the device just blasts the info out into the network using a multicast address. That may not be desirable for every scenario but could be OK for his use case. 

There are quite likely these cases: 

·        No ACL needed (Jari's case)

·        ACL based on pre-configuation (device talks only to some servers in the service provider's network)

·        Configurable ACLs using a user interface (via a display)

·        Indirect configuration via some protocols (think of software update mechanisms, device configuration) 

Well. Even with asymmetric crypto (like the raw public keys) you could, if you want to, treat them like symmetric keys. 

Ciao

Hannes

Alper

 

So, what could you do?

 

Ciao
Hannes

Dear colleagues:

Best regards, Rene

 

-------- Original Message --------

Subject:

Re: [core] RawPublicKeys

Date:

From:

To:

CC:

Dear colleagues:

Rene

 

	Hi Carsten,

		Hi Alper,

	 

	 

		Grüße, Carsten

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Dec 2011 10:02:02 +0200

Hi Hannes,

> With the work on TLS raw public key and the cached information extension I was actually more focusing on the communication between two applications rather than security for network access authentic…

Alper> I was not talking about "network access authentication". I was just walking over a physical example where people bring in a new device to home and it needs to start talking CoAP to the gateway at home. This is the scenario where people talk about "reading an ID from a stickier on the device and typing it in an ACL (on the gateway)". Or reading that ID over the phone to the service provider who enters it into the ACL database, etc.

Alper> Note: Same credential is likely to be used for both network access and app auth, but we can ignore that aspect for this discussion.

> For example, with a picture frame you have a UI and with a temperature sensor you probably don’t have one. With an Internet radio you have a small UI and actually, for more elaborate configuration, you can also connect to the device via a Web browser. Some devices have certain parameters pre-configured (like my Internet radio fetches a list of available Internet radio stations from a pre-configured URL).
>  
> So, there is no single answer.

Alper> I thought we were trying to solve the problem of "dealing with interface-less devices". 
Alper> Maybe we shall re-state the problem statement, if that's not it.

> It really varies a lot but maybe you can cluster the different scenarios in some form to offer a meaningful description.  
>  
> It depends. When I look at Jari’s draft then I believe his model is more than the device just blasts the info out into the network using a multicast address. That may not be desirable for every scenario but could be OK for his use case.
>  
>  
> ·        No ACL needed (Jari’s case)

Alper> Is that the case where device is just a sensor (not controlled), and whatever it senses/delivers is not confidential? Only in that case we are OK with the one-sided authentication/authorization.

> ·        ACL based on pre-configuation (device talks only to some servers in the service provider’s network)

Alper> Yes, this is an enumeration of numerous scenarios. I think our difference is in the understanding of the problem statement. 

> Well. Even with asymmetric crypto (like the raw public keys) you could, if you want to, treat them like symmetric keys.

Alper> Only if you install an ACL on the device… 
Alper> Unless the device knows the list of authorized IDs, it can only authenticate the other end-points but it cannot authorize them.
Alper> With the PSK, device can say "oh, OK, whoever has a copy of my PSK is inherently authorized to talk with me"

Alper