Subject: [core] draft-ietf-core-coap-06 Security

From: Cullen Jennings <[email-masked]>
Date: Wed, 4 May 2011 20:51:06 -0600

I think it will be very hard to leave keying for the security out of scope of this specification. I realize there are other drafts in progress on this and I look forward to their rapid arrival. Even when using DTLS Certificate mode, any connection can have a man in the middle attack as their is not binding of who we are trying to connect to material in the certificate. This seems like a big problem. Related to this, for many protocols the assumption that someone with a keyboard and screen will manually type something into the device as out of band security configuration is reasonable. Give the use cases this WG was formed to solve, it is not an reasonable assumption for this WG. 

Cullen <in my role as an individual contributor>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 5 May 2011 18:03:50 +0300

Hi Cullen,

I think it is essential that the protocol can be secured when there are
pre-provisioned credentials on the devices. I think we are covered on that
front.

If you are talking about specifying mechanisms about how those credentials
got on the devices, the simplest is to say they are burned in by the
manufacturer.

If you want to take one more step, i.e. specifying some dynamic over-the-air
provisioning of credentials, I think this is getting beyond Core scope. That
by itself is a large problem and not that specific to Core. It needs to be
scoped in very detail, and most possibly it already applies to non-core
scenarios as well.

My 0.02 cents.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cullen Jennings
> Sent: Thursday, May 05, 2011 5:51 AM
> To: core WG
> Subject: [core] draft-ietf-core-coap-06 Security
> 
> 
> 
> I think it will be very hard to leave keying for the security out of
> scope of this specification. I realize there are other drafts in
> progress on this and I look forward to their rapid arrival. Even when
> using DTLS Certificate mode, any connection can have a man in the
> middle attack as their is not binding of who we are trying to connect
> to material in the certificate. This seems like a big problem. Related
> to this, for many protocols the assumption that someone with a keyboard
> and screen will manually type something into the device as out of band
> security configuration is reasonable. Give the use cases this WG was
> formed to solve, it is not an reasonable assumption for this WG.
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 5 May 2011 12:13:40 -0600

> pre-provisioned credentials on the devices. I think we are covered on that

In the Certificate mode, I do not see how we are covered from on path attackers - but I could easily be missing some critical part of the draft -  I just don't see how the security works yet. For example if A wants to send a message to B and E is an on path attacker. E can MITM the DTLS and do whatever they want to the messaging. People keep telling me that solving that problem is out of scope for CoAP. Just about all the other IETF protocols I have worked on consider that problem in scope. I have a hard time imagining this draft getting past IESG with that out of scope.  

I'm not trying to push any particular solution to this - I just think we need some solution to it. Given out deployment environment, I don't see how to easily to solve without also dealing with some of the issues people wish were out of scope. 

> got on the devices, the simplest is to say they are burned in by the

I think it's worth breaking this into two cases. One where the credentials was a shared symmetric key of some sort and are the same across all devices. Then there is the case where the credential is a manufacture installed certificate. Those are pretty different. In the first case, the security is not really there and in the second case, I still don't see how CoAP solves the attack I mentioned above. 

I may have misread the current draft and I could easily be confused about the how things work. So lets start with where you have a different point of view than me. 

I guess the first is question is if we need to actually protect against attacks such as the on path MITM?

The second would be are you thinking manufacture installed certs would do this and if so how? or is there a different type of credential you were thinking of for this?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 May 2011 20:26:08 +0200

Maybe I don't fully understand this discussion.  Let me try.

> For example if A wants to send a message to B and E is an on path attacker. E can MITM the DTLS and do whatever they want to the messaging.

Yes.  However, if A or B do care about B's or A's identity, they can check it.
(I'm talking about certificates.  That MITM is not possible with pairwise PSKs.)

> I guess the first is question is if we need to actually protect against attacks such as the on path MITM?

I do think we need to be able to.

> The second would be are you thinking manufacture installed certs would do this and if so how? or is there a different type of credential you were thinking of for this? 

Again, if A cares about B's identity, and that identity is in the cert, we're fine.

Of course, that doesn't help with bootstrapping communication to an entity that you don't know the identity of yet, which may be more relevant in the Home Control scenario.  So, if I buy a lightbulb, my phone can easily find out that its certificate is chained to its manufacturer, but that doesn't help against a neighbor bringing up a lightbulb from the same manufacturer at the same time.  That's where you either need leap-of-faith or identity labels or other OOB mechanisms.  (And if I use those, I might as well get rid of certificates.  But that is a separate discussion.)

Gruesse, Carsten

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 May 2011 13:27:25 +0300

> In the Certificate mode, I do not see how we are covered from on path
> attackers - but I could easily be missing some critical part of the
> draft -  I just don't see how the security works yet. For example if A
> wants to send a message to B and E is an on path attacker. E can MITM
> the DTLS and do whatever they want to the messaging. People keep
> telling me that solving that problem is out of scope for CoAP. Just
> about all the other IETF protocols I have worked on consider that
> problem in scope. I have a hard time imagining this draft getting past
> IESG with that out of scope.

Performing mutual TLS authentication leaves no room for a MitM. I don't
quite understand the threat you are mentioning. 

> I'm not trying to push any particular solution to this - I just think
> we need some solution to it. Given out deployment environment, I don't
> see how to easily to solve without also dealing with some of the issues
> people wish were out of scope.
> 
> >
> I think it's worth breaking this into two cases. One where the
> credentials was a shared symmetric key of some sort and are the same
> across all devices. 

What do you mean by "the same"? Hopefully not the same key. 

> Then there is the case where the credential is a
> manufacture installed certificate. Those are pretty different. In the
> first case, the security is not really there and in the second case, I
> still don't see how CoAP solves the attack I mentioned above.

Sorry, I don't understand why you say "security is not there." 

> I may have misread the current draft and I could easily be confused
> about the how things work. So lets start with where you have a
> different point of view than me.
> 

Yes. 

> The second would be are you thinking manufacture installed certs would
> do this and if so how? 

Sure. Why not?

OK, let me write this and see if this sheds some light to a possible
disconnect. Let's look at this scenario:

Each device comes with a certificate bound to a device identifier. If you
get a new device and want to join it to your network, you include that
device's identifier in the ACL (access control list, i.e., a white list) of
the network. Now that network knows the identifier of the device, still
needs to authenticate when a device claims that identity. How that
identifier is entered in the ACL DB can be out-of scope for this WG.

Now the device discovers the network (and its identifier). I guess this is
also out-of scope right now. (Could be in scope....)

Given that the two end-points know each other's "claimed" identifiers, they
proceed to authenticating that claim using the certificates. TLS does that.

What do you think?

Alper

> or is there a different type of credential you
> were thinking of for this?
> 
> >

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 May 2011 12:43:03 +0200

I think some of the confusion comes from looking at only part of the picture.
I'll try to get the rest filled in by asking a couple of questions.

On May 6, 2011, at 12:27, Alper Yegin wrote:

> Each device comes with a certificate bound to a device identifier.

(That is fine for a class of devices.
Let's focus on this class for now.)

Who signs this certificate?  What is the trust model?
What are our assumptions with respect to the lifecycle of roots that are common between devices?
(Note that some devices have a rather long expected service life.)

> If you
> the network.

I don't know what "the network" is other than a collection of nodes we call the Internet.
Which nodes keep this ACL?  How is the updating done securely?
How is the information disseminated securely to the other nodes?
How does my new lightbulb know all this?

> Now that network knows the identifier of the device, still

But a framework for that is the essence of security bootstrapping.

> proceed to authenticating that claim using the certificates. TLS does that.

That is the part that is relatively well-understood, I agree.

Gruesse, Carsten

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 May 2011 18:11:52 +0300

Hi Carsten,

> (Note that some devices have a rather long expected service life.)

Good questions, but not for the protocol designers.

For example, IEEE has designed IEEE 802.16e such that it can use
certificates for mutually authenticating devices (mobile terminals) and
networks to each other. The questions about who the root CA vendors are,
what properties the exact certs have, etc. are answered by the WiMAX Forum
in its own specs, not in IEEE specs.

> How is the information disseminated securely to the other nodes?

These are system and architecture questions. They are answerable only if we
start talking about specific ones... 

> But a framework for that is the essence of security bootstrapping.

But is it essential for the basic protocol design? Again, these are
system/arch issues.

These are useful to discuss and understand, but not necessarily for CoAP to
solve, IMHO.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 7 May 2011 00:09:45 +0200

> Good questions, but not for the protocol designers.

Not for the CoAP protocol proper, but according to our charter, maybe for the WG.

> For example, IEEE has designed IEEE 802.16e such that ...

That was easy: This is for use in a specific environment.
We are, however, designing a protocol for the Internet.

> start talking about specific ones... 

I'm afraid this cannot be solved if we try to discuss it at the level of generalities.
That's why I always bring up my lightbulb:  If we don't even know how to do this, we won't be able to solve more general cases.

> These are useful to discuss and understand, but not necessarily for CoAP to

I agree completely -- CoAP is not the protocol that provides the mechanics for this.
coap-06 is essentially complete from my point of view.

The question is what we write into the companion security bootstrapping document: what is our MTI (mandatory to implement) security setup that we expect every CoAP node to implement?
("MTI" is not "mandatory to use" -- specific deployments may always provide more specialized ways to set up security.)

Saying "CoAP can be used in a perfectly secure way, but we don't really know how to make it so in a realistic Internet use case" is not really going to cut it.  Let's try to go that last mile.

Gruesse, Carsten

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 7 May 2011 02:21:19 +0300

> Not for the CoAP protocol proper, but according to our charter, maybe

I think that charter statement deserves a discussion, like the one we are
having now. IMHO, it should have been put in there after such a discussion
and with good scoping. 

> We are, however, designing a protocol for the Internet.

Right. But then it will also get used in specific environments, which will
have its own characteristics that'll drive various design/use
considerations. 

> That's why I always bring up my lightbulb:  If we don't even know how
> to do this, we won't be able to solve more general cases.

OK, here we go:

Your light bulb will be compliant with "Lighting Forum (LF)" which dictates
the manufacturer the type of cert profile and the specific root CA to be
used when pre-provisioning the bulb at the time of manufacturing. Obviously,
LF also says "use CoAP with DTLS". Whatever the controller LF defines also
needs to be compliant with the same. LF will determine a mechanism for
controllers to be provisioned with ACLs (whitelist of lightbulb IDs). [In
Release 1, they'll say "by some out of scope mechanism". In Release 2,
they'll try to invent/adopt some standard mechanism for that :)]

The bulb also needs to know the ID of the controller. A discovery mechanism
is needed. Like I said before, IETF CORE WG can take a stab at this. If not
done in IETF, or if the LF does not like it or thinks they can do better, LF
will invent/adopt some other standard mechanism.

Something like that...

> The question is what we write into the companion security bootstrapping
> document: what is our MTI (mandatory to implement) security setup that
> we expect every CoAP node to implement?
> ("MTI" is not "mandatory to use" -- specific deployments may always
> provide more specialized ways to set up security.)

Honestly, it may not even be "implemented" in reality. If the SDO/Forum
defining the bulb spec decides to use something other than the CORE WG's MTI
mechanism, they'll not use up their precise memory footprint for the sake of
RFC compliance. They'll do a profiling.

> Saying "CoAP can be used in a perfectly secure way, but we don't really
> know how to make it so in a realistic Internet use case" is not really
> going to cut it.  Let's try to go that last mile.

Alper

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 7 May 2011 08:50:27 -0700

> quite understand the threat you are mentioning. 

So say A has a certificate with device identifier cert-a in SAN of the cert, E has one with cert-e, and B has one with cert-b. After the attack, A thinks they are talking to someone with a cert-e. Most other IETF protocols have a normative way to make sure that when an application is trying to form a TLS connection to B, you don't end up accepting an certificate that has cert-e in it. CoAP does not have something like that in it. You suggest an ACL solution to this which is fine, but my point is that to have a security story of how the CoAP protocol protects from given attacks, we need this defined somewhere. I do not think the IETF is likely to approve CoAP approved without a normative reference to a document that deal with these sort of issues. 

If the direction the WG wanted to take to solve this was there was an ACL list that said when trying to talk to B, expect a cert that says cert-b, and we had a secure way to distribute that ACL, then we then we could probably solve all of this without using asymmetric crypto.

I agree security design has both protocol and system implications. The overall way I am looking at the solution, is that if two different vendors read the CoAP spec and build devices from it, we should be able to deploy theses devices in some of a bunch (if not all) our use case we have the the WG and have them work together.  I realize that some other SDOs separate the security much more into the systems design but the IETF found that when they did that the protocols ended up with no security and has pushed the security design into the protocols more than some other SDOs. 

The most important part of this email is when using TLS, the integrity and authentication part of it are sort of useless to on path attacks unless you also have the authentication part of it. Other IETF protocols define how to do the authentication part of it - I believe we will also need to say how to make the authentication part of TLS work in CoAP.

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 7 May 2011 23:34:43 +0300

Cullen,

> So say A has a certificate with device identifier cert-a in SAN of the
> cert, E has one with cert-e, and B has one with cert-b. After the
> attack, A thinks they are talking to someone with a cert-e. Most other
> IETF protocols have a normative way to make sure that when an
> application is trying to form a TLS connection to B, you don't end up
> accepting an certificate that has cert-e in it. CoAP does not have
> something like that in it. You suggest an ACL solution to this which is
> fine, but my point is that to have a security story of how the CoAP
> protocol protects from given attacks, we need this defined somewhere. I
> do not think the IETF is likely to approve CoAP approved without a
> normative reference to a document that deal with these sort of issues.

There needs to be a binding between the CoAP and DTLS. Whatever identifier
is used at CoAP layer has to match the identifier that got authenticated at
the DTLS layer. Otherwise, yes, what you are describing can happen. 

> If the direction the WG wanted to take to solve this was there was an
> ACL list that said when trying to talk to B, expect a cert that says
> cert-b, and we had a secure way to distribute that ACL, then we then we
> could probably solve all of this without using asymmetric crypto.

I'm not sure the symmetric vs. asymmetric crypto is a factor here. I think
the issue is, the end-point authentication is happening at a layer other
than the one using the associated identifiers. There needs to be a binding
between the two.

> I agree security design has both protocol and system implications. The
> overall way I am looking at the solution, is that if two different
> vendors read the CoAP spec and build devices from it, we should be able
> to deploy theses devices in some of a bunch (if not all) our use case
> we have the the WG and have them work together.  I realize that some
> other SDOs separate the security much more into the systems design but
> the IETF found that when they did that the protocols ended up with no
> security and has pushed the security design into the protocols more
> than some other SDOs.
> 
> The most important part of this email is when using TLS, the integrity
> and authentication part of it are sort of useless to on path attacks
> unless you also have the authentication part of it. 

TLS provides end-point authentication, followed by creating a secure
transport that provides integrity and replay protection, data origin
authentication, and privacy for the data.

> Other IETF
> protocols define how to do the authentication part of it - I believe we
> will also need to say how to make the authentication part of TLS work
> in CoAP.

By the way, I wonder why this WG chose to use TLS. Why not define a
CoAP-layer security extension. We can do something similar to what was done
for Mobile IPv4, another UDP-based protocol. Define an option that carries a
keyed hash of the CoAP header + payloads. And you get data origin auth,
integrity and replay protection. And define another option to encrypt the
ones that require privacy. (encryption part not in Mobile IPv4). 

Alper

Alper

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 9 May 2011 12:29:15 -0700

inline ...

> than the one using the associated identifiers. There needs to be a binding

100% agree - in my mind this is probably the largest remaining issues in the draft

> ones that require privacy. (encryption part not in Mobile IPv4). 

well some protocols have a strong need for the integrity to cover a different part of the packet than the encryption.  Mobile IP and SRTP seem to be examples of that. However, CoAP seems like you can encrypt the whole CoAP packet because there is not an need for some intermediaries to be able to read some of the packet but not others parts

> Alper

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 11 May 2011 22:47:01 +0300

> well some protocols have a strong need for the integrity to cover a
> different part of the packet than the encryption.  Mobile IP and SRTP
> seem to be examples of that. However, CoAP seems like you can encrypt
> the whole CoAP packet because there is not an need for some
> intermediaries to be able to read some of the packet but not others
> parts

Sure you can encrypt the whole payload e2e. But do you have to? That's the
issue. In case you don't have to encrypt the whole packet, then there is an
unjustified overhead of doing so (when you use transport-layer security).

Alper

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 May 2011 06:44:22 -0700

> unjustified overhead of doing so (when you use transport-layer security).

TLS has cipher suites that only do integrity.

-Ekr

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 12 May 2011 21:51:14 +0300

> TLS has cipher suites that only do integrity.

I can understand that the TLS channel can be just integrity protected.

If just some of the application data needs to be encrypted, can it be done?
I think the channel is either only integrity protected, or both integrity
protected and encrypted.

If my application relies on TLS, and if some bit of data requires privacy, I
always need to be using an encrypted channel which applies to the whole
communication. 

I'm not singling out TLS here. I think this is a fundamental distinction
between channel security vs object-level security.

Alper

---

From: Robert Cragie <[email-masked]>
Date: Thu, 12 May 2011 21:40:51 +0100

> between channel security vs object-level security.
It seems fundamentally easier to encrypt on a channel basis as the same 
end-point credentials are used to derive keying information which can 
encrypt and integrity protect simultaneously, e.g. most efficiently 
using an AEAD cipher like AES-CCM or AES-GCM. If you start to make the 
encryption more granular, what do you then use as the cryptographic 
basis for secrecy between the transacting objects? Asymmetric or 
symmetric? Would you use the same granularity as the channel end points? 
Or be more granular?

All I'm saying is there is probably more to this than meets the eye.

Robert

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 13 May 2011 04:39:05 +0300

> > I'm not singling out TLS here. I think this is a fundamental
> > distinction between channel security vs object-level security.
> encrypt and integrity protect simultaneously, 

Using object-level security does not change that.

> e.g. most efficiently
> symmetric? 

Symmetric.

> Would you use the same granularity as the channel end
> points?
> Or be more granular?

Not sure I understand. Can you elaborate?

> All I'm saying is there is probably more to this than meets the eye.

Let's find out.

Alper

---

From: Robert Cragie <[email-masked]>
Date: Fri, 13 May 2011 10:04:05 +0100

> Using object-level security does not change that.
Perhaps I misunderstood what you meant by object-level security. The way 
you described it seemed to suggest that elements of data transacted 
within the channel could be individually encrypted. My questions 
surround what security material is used to perform the encryption in 
each case.
> Not sure I understand. Can you elaborate?
As above - what security material would you use to encrypt? The same 
security material as is used for channel encryption? Or something more 
granular, i.e. would each distinct element of encrypted data have its 
own security material? What is the distinction? If communicating objects 
multiplex their transactions on a single channel, this could be the case.

---

From: Zach Shelby <[email-masked]>
Date: Fri, 13 May 2011 17:10:48 +0300

This object security discussion is totally orthogonal to the DTLS security that is default in CoAP (so this really isn't relevant to core-coap-06). Object security is definitely interesting in this domain, and for example the JSON signing BOF in Prague was relevant to this. I would encourage Alper to write a draft about how to do simple object security for CoAP. Robert is right that the security model in the CoRE context should be an important part of that, as well as bootstrapping considerations. 

Zach

On May 13, 2011, at 12:04 PM, Robert Cragie wrote:

> Perhaps I misunderstood what you meant by object-level security. The way you described it seemed to suggest that elements of data transacted within the channel could be individually encrypted. My questions surround what security material is used to perform the encryption in each case.
>>> e.g. most efficiently
> As above - what security material would you use to encrypt? The same security material as is used for channel encryption? Or something more granular, i.e. would each distinct element of encrypted data have its own security material? What is the distinction? If communicating objects multiplex their transactions on a single channel, this could be the case.

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Robert Cragie <[email-masked]>
Date: Fri, 13 May 2011 15:23:10 +0100

Hi Zach,

I wouldn't say totally orthogonal - this spun off from a discussion as 
to whether DTLS was indeed the right choice for security and whether we 
could define a CoAP security (for example, like RPL did). However, my 
view is that DTLS is the right choice.

Robert

---

From: Zach Shelby <[email-masked]>
Date: Fri, 13 May 2011 17:31:32 +0300

On May 13, 2011, at 5:23 PM, Robert Cragie wrote:

> Hi Zach,
> 
> I wouldn't say totally orthogonal - this spun off from a discussion as to whether DTLS was indeed the right choice for security and whether we could define a CoAP security (for example, like RPL did). However, my view is that DTLS is the right choice.

Yes, I agree with you. As a default security scheme DTLS is the right choice, I do not want to start talking about object security in the core-coap document. But in NoSec mode you can use whatever you want to, e.g. IPsec or object security. 

Zach

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 13 May 2011 13:29:34 -0400

> I think it will be very hard to leave keying for the security out of scope of this specification. I realize there are other drafts in progress on this and I look forward to their rapid arrival. Eve…

There is also the blacklist/whitelist approach.

The first time the device fails to authenticate, and is blacklisted.  
The admin reviews the 128bit code for the device against the serial # 
stamped on the device or printed with the documentation, sees the match 
and moves the # to the whitelist.  The next authentication attempt succeeds.

Years back, I helped a company develop a product that worked like this 
and had a reasonable market success (before they were bought up for 
other value).

>
> Cullen<in my role as an individual contributor>
>

-- 
Robert Moskowitz
Senior Technical Director
ICSA Labs, an Independent Division of Verizon Business Systems
W:248-968-9809
F:248-968-2824
VoIP:248-291-0713
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit