Subject: [core] Towards authc/authz user cases

From: Adam Roach <[email-masked]>
Date: Mon, 08 Nov 2010 16:17:32 +0800

In today's meeting, Carsten brought up the topic of the kinds of 
authentication and authorization models we want to consider for CoRE, in 
particular when you start using proxies. I'm think of this mostly in 
terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the 
middle:

+--------+ +-------+ +--------+
| Client |------| Proxy |------| Server |
+--------+ HTTP +-------+ CoRE +--------+

In this context, Carsten spoke of the "big friend" model. Under this 
model, the Proxy would use normal HTTP authentication mechanisms (e.g., 
Basic over TLS, or Digest). It then checks its own local ACLs for 
authorization purposes, and provides access only to those resources on 
the server that the authenticated user is allowed to access. The use 
cases for this model are pretty obvious: very simple servers that can't 
reasonably be provisioned with user information (e.g., light switches), 
where the nature of what can be done (e.g., turning lights on and off) 
is reasonable to trust the proxy with.

For the sake of concreteness, let's nail down the nature of the proxy. 
Let's assume that this proxy is inside my electric meter, and is 
administered by my power utility company. But let's assume they're 
pretty progressive, and let me access the proxy so that I can remotely 
monitor and control my various CoAP-attached devices.

Now, with that in place, let's consider something other than light 
switches. Let's think about my CoAP-attached alarm system, and my 
CoAP-controllable deadbolt lock.

If we pursue only the model under which the proxy authenticates the user 
and then has free reign over the various home-area-network devices, this 
would potentially give a set of power utility employees the ability to 
monitor and control my alarm system and my front-door deadbolt.

This gives me pause.

So, in addition to the "big friend" model, I think it's clear that we 
need the ability for the client to authenticate end-to-end, through the 
proxy. And, since the proxy can only marginally be trusted in this case, 
we need to make sure it can't lift the credentials from, say, HTTP basic 
auth it receives over TLS connections.

Without defining a new model for HTTP, it seems that this situation kind 
of requires the ability to interwork HTTP digest parameters with 
semantically equivalent CoAP parameters.

/a

---

From: "Stok, Peter van der" <[email-masked]>
Date: Mon, 8 Nov 2010 10:21:02 +0100

Dear Adam,

There are a lot of assumptions in your solution.
For me it is not even clear that we need authorization for small devices. And when we need it in a CoAP environment, the security technology burden may be such that we have to resort to other techniques. These other techniques will be very application dependent.

My suggestion is to first get more insight in the security needs which exist in various scenarios and applications. Then look at consequences of existing technologies, and probably continue with coap solutions where needed.

Peter van der stok

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Monday 8 November 2010 9:18
To: CORE (Constrained RESTful Environments) WG
Subject: [core] Towards authc/authz user cases

This gives me pause.

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

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Nov 2010 01:36:49 -0800

On Mon, Nov 8, 2010 at 1:21 AM, Stok, Peter van der <
[email-masked]> wrote:

> For me it is not even clear that we need authorization for small devices.

Well, this is precisely why I asked the question about threat models.

Naively, if the light switches or locks in my house are controlled by IP,
I'd like some authentication,
I would think.

-Ekr

> And when we need it in a CoAP environment, the security technology burden
> may be such that we have to resort to other techniques. These other
> techniques will be very application dependent.
>
> My suggestion is to first get more insight in the security needs which
> exist in various scenarios and applications. Then look at consequences of
> existing technologies, and probably continue with coap solutions where
> needed.
>
> Peter van der stok
>
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby notified
> that any use, forwarding, dissemination, or reproduction of this message is
> strictly prohibited and may be unlawful. If you are not the intended
> recipient, please contact the sender by return e-mail and destroy all copies
> of the original message.
>

---

From: Robert Cragie <[email-masked]>
Date: Mon, 08 Nov 2010 09:56:57 +0000

Hi Adam,

Comments below, bracketed by <RCC></RCC>

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 08/11/2010 8:17 AM, Adam Roach wrote:
> authentication and authorization models we want to consider for CoRE, 
> in particular when you start using proxies. I'm think of this mostly 
> in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in 
> the middle:
>
> model, the Proxy would use normal HTTP authentication mechanisms 
> (e.g., Basic over TLS, or Digest). It then checks its own local ACLs 
> for authorization purposes, and provides access only to those 
> resources on the server that the authenticated user is allowed to 
> access. The use cases for this model are pretty obvious: very simple 
> servers that can't reasonably be provisioned with user information 
> (e.g., light switches), where the nature of what can be done (e.g., 
> turning lights on and off) is reasonable to trust the proxy with.
>
<RCC>CoAP-attached to what and CoAP-controllable by what? These may be 
part of the same home network but that doesn't necessary imply 
attachment or controllability in an application domain.</RCC>
>
> If we pursue only the model under which the proxy authenticates the 
> user and then has free reign over the various home-area-network 
> devices, this would potentially give a set of power utility employees 
> the ability to monitor and control my alarm system and my front-door 
> deadbolt.
<RCC>So why would we pursue that model? There is the notion of an 
authentication server from the point of view of network access but there 
is also a distinct notion of different authentication servers in the 
application domain separating the application domains (or indeed 
combining them at a node if it makes sense). These are Carsten's big 
friend, or indeed, friends; plural implies multiple service providers so 
the utility may be one of those but there is provision for other service 
providers too.</RCC>
> need the ability for the client to authenticate end-to-end, through 
> the proxy. And, since the proxy can only marginally be trusted in this 
> case, we need to make sure it can't lift the credentials from, say, 
> HTTP basic auth it receives over TLS connections.
<RCC>Why would the proxy only be marginally trusted? End to end is 
preferable as it provides a secure association between peer. However if 
a peer (client/server) and proxy is authenticated independently in both 
federated domains, it can be trusted across those domains even if there 
is no secure association. Authentication can be delegated to the proxy 
'big friend',which can grant authorization tokens to the application 
peers it is friendly with (including itself). The application peers can 
then mutually authenticate they both know the big friend.</RCC>
>
> Without defining a new model for HTTP, it seems that this situation 
> kind of requires the ability to interwork HTTP digest parameters with

---

From: Linyi Tian <[email-masked]>
Date: Mon, 08 Nov 2010 17:57:34 +0800

Hi, Adam and Peter

Adam did raised some interesting issue regarding security. For example who
will be authorized to control the door lock. Whether the device should trust
the control message from the proxy?

I think Peter made a good point that we need to get more insight in the
scenarios/enrionment. In the electric meter scenario it makes sense that the
power utility company takes the full control of the electric meter. In this
case the big friend model will work. In the door lock case, the proxy most
likely will be operated by the house owner, e.g. home gateway. The
application who is allowed to control the door lock should be under control
by the user as well. For example, the application can be installed in the
mobile phone and interacts with the proxy over internet. In this case the
application has to be authenticated and authorized by the proxy first. If
the proxy and device are in trusted environment the
authentication/authorization may not needed. otherwise it MUST be provided
to avoid security holes.

Cheers,
Linyi

On 10-11-8 下午5:36, "Eric Rescorla" <[email-masked]> wrote:

> 
> 
> On Mon, Nov 8, 2010 at 1:21 AM, Stok, Peter van der
> <[email-masked]> wrote:
>> Dear Adam,
>> 
> Naively, if the light switches or locks in my house are controlled by IP, I'd
> like some authentication,
> I would think.
> 
> -Ekr
>  
>> And when we need it in a CoAP environment, the security technology burden may
>> be such that we have to resort to other techniques. These other techniques
>> will be very application dependent.
>> 
>> My suggestion is to first get more insight in the security needs which exist
>> in various scenarios and applications. Then look at consequences of existing
>> technologies, and probably continue with coap solutions where needed.
>> 
>> Peter van der stok
>>

---

From: Don Sturek <[email-masked]>
Date: Mon, 8 Nov 2010 02:24:43 -0800 (PST)

Hi Adam,

I think your note below is a bad example.   No electric company I know of will 
allow you access homeowner to a proxy in the meter and none (at least the US 
based utilities I know of) will allow un-enrolled access to anything other than 
meter usage data and information on price (and this access is authenticated for 
privacy reasons).  If you enroll your devices in a utility program then you 
could also receive demand response messages.  Really that is it in terms of 
services provided by the meter.........

Now it is true that the meter usage data, price and other information can be 
used in the HAN for energy savings.  The utility is not involved in this and 
does not host homeowner applications within the meter.  The utility only 
supplies the requested data to the HAN devices to support that application.

Don 

________________________________
From: Adam Roach <[email-masked]>
To: CORE (Constrained RESTful Environments) WG <[email-masked]>
Sent: Mon, November 8, 2010 12:17:32 AM
Subject: [core] Towards authc/authz user cases

In today's meeting, Carsten brought up the topic of the kinds of authentication 
and authorization models we want to consider for CoRE, in particular when you 
start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP 
client, and an HTTP/CoRE proxy in the middle:

In this context, Carsten spoke of the "big friend" model. Under this model, the 
Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or 
Digest). It then checks its own local ACLs for authorization purposes, and 
provides access only to those resources on the server that the authenticated 
user is allowed to access. The use cases for this model are pretty obvious: very 
simple servers that can't reasonably be provisioned with user information (e.g., 
light switches), where the nature of what can be done (e.g., turning lights on 
and off) is reasonable to trust the proxy with.

For the sake of concreteness, let's nail down the nature of the proxy. Let's 
assume that this proxy is inside my electric meter, and is administered by my 
power utility company. But let's assume they're pretty progressive, and let me 
access the proxy so that I can remotely monitor and control my various 
CoAP-attached devices.

Now, with that in place, let's consider something other than light switches. 
Let's think about my CoAP-attached alarm system, and my CoAP-controllable 
deadbolt lock.

If we pursue only the model under which the proxy authenticates the user and 
then has free reign over the various home-area-network devices, this would 
potentially give a set of power utility employees the ability to monitor and 
control my alarm system and my front-door deadbolt.

This gives me pause.

So, in addition to the "big friend" model, I think it's clear that we need the 
ability for the client to authenticate end-to-end, through the proxy. And, since 
the proxy can only marginally be trusted in this case, we need to make sure it 
can't lift the credentials from, say, HTTP basic auth it receives over TLS 
connections.

Without defining a new model for HTTP, it seems that this situation kind of 
requires the ability to interwork HTTP digest parameters with semantically 
equivalent CoAP parameters.

/a

---

From: "Stok, Peter van der" <[email-masked]>
Date: Mon, 8 Nov 2010 11:29:35 +0100

Hi Don,

This is a good example of a use case. Ready to share it in a draft? (with a bit more text?)

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Don Sturek
Sent: Monday 8 November 2010 11:25
To: Adam Roach; CORE (Constrained RESTful Environments) WG
Subject: Re: [core] Towards authc/authz user cases

Hi Adam,

I think your note below is a bad example.   No electric company I know of will allow you access homeowner to a proxy in the meter and none (at least the US based utilities I know of) will allow un-enrolled access to anything other than meter usage data and information on price (and this access is authenticated for privacy reasons).  If you enroll your devices in a utility program then you could also receive demand response messages.  Really that is it in terms of services provided by the meter.........

Now it is true that the meter usage data, price and other information can be used in the HAN for energy savings.  The utility is not involved in this and does not host homeowner applications within the meter.  The utility only supplies the requested data to the HAN devices to support that application.

Don

In today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle:

In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with.

For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices.

Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock.

If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt.

This gives me pause.

So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections.

Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters.

/a
_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

---

From: Don Sturek <[email-masked]>
Date: Mon, 8 Nov 2010 02:35:04 -0800 (PST)

Hi Peter,

Both I and Tom Herbst have provided some input to 
http://datatracker.ietf.org/doc/draft-baker-ietf-core/ Appendix I.   It should 
have a decent explanation of this use case.

The main issue is the utilities do not want access from the HAN Devices to 
resources in the meter/Utility ESI nor do they want the HAN devices to have the 
ability to route back through the meter/utility ESI into the AMI.

Don

________________________________
From: "Stok, Peter van der" <[email-masked]>
To: Don Sturek <[email-masked]>; Adam Roach <[email-masked]>; CORE 
(Constrained RESTful Environments) WG <[email-masked]>
Sent: Mon, November 8, 2010 2:29:35 AM
Subject: RE: [core] Towards authc/authz user cases

Hi Don,
 
This is a good example of a use case. Ready to share it in a draft? (with a bit 
more text?)
 
Peter
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of Don 
Sturek
Sent: Monday 8 November 2010 11:25
To: Adam Roach; CORE (Constrained RESTful Environments) WG
Subject: Re: [core] Towards authc/authz user cases
 
Hi Adam,

Don 

From:Adam Roach <[email-masked]>
To: CORE (Constrained RESTful Environments) WG <[email-masked]>
Sent: Mon, November 8, 2010 12:17:32 AM
Subject: [core] Towards authc/authz user cases

This gives me pause.

/a
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core
________________________________
 The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified  
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.

---

From: Don Sturek <[email-masked]>
Date: Mon, 8 Nov 2010 02:59:36 -0800 (PST)

Hi Peter,

One more useful link would be the OpenSG OpenHAN 2.0 document.  This was a 
collaboration of utilities and vendors and is used by the Smart Energy 2.0 work 
as a requirements document.  Here is a link to the OpenHAN 2.0 document:

http://osgug.ucaiug.org/sgsystems/openhan/Shared%20Documents/OpenHAN%202.0/UCAIug%20HAN%20SRS%20-%20v2.0.pdf

It is really the OpenHAN 2.0 document that the US utilities are looking to 
support.......

Don

Hi Don,

Peter

Hi Adam,

Don 

This gives me pause.

/a

---

From: Robert Quattlebaum <[email-masked]>
Date: Mon, 8 Nov 2010 09:36:15 -0800

For what it's worth, i've implemented digest authentication on an embedded device, and it wasn't bad at all. I plan to use it for authenticating both administrative actions and automated commands between devices. The idea being that if I pair my deadbolt to a switch in the house, only the switch would have the credentials to control the lock on the deadbolt. The username/password credentials would be negotiated during the pairing process and generated automatically, perhaps using some sort of key exchange protocol. As an added bonus, this would also protect you against replay attacks*.

I like this because it protects my house even if someone were to somehow determine my HAN key. 

Imagine I have a key-fob-like device on my keychain which when I press the button it attempts to send a authenticated request to the deadbolt. If I loose the fob, I can remove the pairing with the fob from the deadbolt without losing any other pairings. 

This works quite nicely in a "callback" style system where the switch actually does a PUT or POST to a specific path on the deadbolt. Not sure how well it would work with observe. 

I think that digest authentication for CoAP can be made to be compatible with HTTP digest. Indeed, it could probably be used as-is... But i think it would be wise to encode the key-value pairs using a more dense mechanism, perhaps similar to how CoAP header options are encoded. This would be both easier to parse and take up less space. The proxy would then need to deal with converting to and from the different representations, but that doesn't seem unreasonable to me. 

* Unless the content is hashed, if someone intercepts a command that didn't make it to the intended target device, they could modify the content and resend as an authenticated packet. This would work as long as the target device hasn't received any other authenticated packets in the mean time. the key fob idea above is particularly vulnerable to this. This can be worked around by forcing the nonce count to be renegotiated after a timeout. 

On Nov 8, 2010, at 1:57 AM, Linyi Tian <[email-masked]> wrote:

> Hi, Adam and Peter
> 
> Adam did raised some interesting issue regarding security. For example who will be authorized to control the door lock. Whether the device should trust the control message from the proxy? 
> 
> I think Peter made a good point that we need to get more insight in the scenarios/enrionment. In the electric meter scenario it makes sense that the power utility company takes the full control of the electric meter. In this case the big friend model will work. In the door lock case, the proxy most likely will be operated by the house owner, e.g. home gateway. The application who is allowed to control the door lock should be under control by the user as well. For example, the application can be installed in the mobile phone and interacts with the proxy over internet. In this case the application has to be authenticated and authorized by the proxy first. If the proxy and device are in trusted environment the authentication/authorization may not needed. otherwise it MUST be provided to avoid security holes.
> 
> Cheers,
> Linyi
> 
> 
> 
> On Mon, Nov 8, 2010 at 1:21 AM, Stok, Peter van der <[email-masked]> wrote:
> Dear Adam,
> 
> Naively, if the light switches or locks in my house are controlled by IP, I'd like some authentication,
> I would think.
> 
> -Ekr
> 
> And when we need it in a CoAP environment, the security technology burden may be such that we have to resort to other techniques. These other techniques will be very application dependent.
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Nov 2010 10:00:01 +0800

On 11/8/10 6:24 PM, Don Sturek wrote:
> I think your note below is a bad example.   No electric company I know 
> of will allow you access homeowner to a proxy in the meter and none 
> (at least the US based utilities I know of) will allow un-enrolled 
> access to anything other than meter usage data and information on 
> price (and this access is authenticated for privacy reasons).  If you 
> enroll your devices in a utility program then you could also receive 
> demand response messages.  Really that is it in terms of services 
> provided by the meter.........
>
> Now it is true that the meter usage data, price and other information 
> can be used in the HAN for energy savings.  The utility is not 
> involved in this and does not host homeowner applications within the 
> meter.  The utility only supplies the requested data to the HAN 
> devices to support that application.

Okay, so that point to having a separate home gateway for 
homeowner-controller devices. That's workable. There's still an issue of 
protecting the deadbolt from accepting messages from other devices on 
the network (which may or may not be under control of the homeowner) 
without authentication. We need to have some scheme to prevent this.

/a

---

From: Robert Cragie <[email-masked]>
Date: Wed, 10 Nov 2010 11:07:28 +0000

Comments below

RCC

On 10/11/2010 2:00 AM, Adam Roach wrote:
>> I think your note below is a bad example.   No electric company I 
>> know of will allow you access homeowner to a proxy in the meter and 
>> none (at least the US based utilities I know of) will allow 
>> un-enrolled access to anything other than meter usage data and 
>> information on price (and this access is authenticated for privacy 
>> reasons).  If you enroll your devices in a utility program then you 
>> could also receive demand response messages.  Really that is it in 
>> terms of services provided by the meter.........
>>
> homeowner-controller devices. That's workable. There's still an issue 
> of protecting the deadbolt from accepting messages from other devices 
> on the network (which may or may not be under control of the 
> homeowner) without authentication. We need to have some scheme to 
> prevent this.
<RCC>Absolutely. The model proposed in Open HAN 2.0 
(http://osgug.ucaiug.org/sgsystems/openhan/Shared%20Documents/OpenHAN%202.0/UCAIug%20HAN%20SRS%20-%20v2.0.pdf) 
supports this and that is what I would propose</RCC>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 15 Nov 2010 12:23:36 +0100

Adam,
I share your concern about current security model supporting ONLY the
"trusted proxy". This can limit the scope of application of CoAP, if
we consider that the proxy should reside on the edge of the
constrained network.

If I understand correctly, seems that we're assuming that all CoAP
devices and the CoAP/HTTP proxy are always in the same security
"domain"..

This seems a strong assumption, because nobody cannot deploy a trusted
CoAP device on the network without deploying also a proxy THEY trust
on each local network.

The network and the proxy in my opinion should reside on the edge of
the constrained local network:
- for scalability
- early UDP/UDP conversion
- access to local multicast features
- probably many other reasons...

AND is very convenient if it exists a techique to achieve end-to-end
security using the proxy only for *translation* purposes and without
trust.

Obviously if the proxy resides on the other end there is no such
problem, but in that case CoAP<->HTTP mapping is used only for
convenience and the endpoints of security are always CoAP<->CoAP.

Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 15 Nov 2010 12:33:39 +0100

> security using the proxy only for *translation* purposes and without

I missed spell checking this paragraph.. The corrected version follows:

The CoAP/HTTP proxy in my opinion should reside on the edge of the
constrained local network:
- for scalability
- early TCP/UDP conversion
- access to local multicast features
- probably many other reasons...

AND is very convenient if it exists a technique to achieve end-to-end
security using the proxy only for *translation* purposes and without
trust.

---

From: Robert Cragie <[email-masked]>
Date: Mon, 15 Nov 2010 17:03:19 +0000

Hi Angelo,

I'm struggling to see how you can have end-to-end security which goes 
through a translation point. At the point of translation, end-to-end 
security is lost, unless we are talking essentially about session 
protocol translation only, which I don't think is the case here.

I am also confused because early on you seem to say that having a proxy 
residing on the edge limits the scope of application of CoAP but in then 
you same to say in your corrected version (as below) that it should 
reside on the edge of the network. Can you clarify where your 'ends' are?

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 15/11/2010 11:23 AM, Angelo P. Castellani wrote:
> The CoAP/HTTP proxy in my opinion should reside on the edge of
> On Mon, Nov 8, 2010 at 09:17, Adam Roach<[email-masked]>  wrote:

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 16 Nov 2010 10:37:40 +0100

I don't know if end-to-end security can be obtained with in-the-middle
untrusted translation between HTTP and CoAP (I'm not a security
expert).

I explain better my doubt: If secured CoAP requires always a trusted
proxy to be mapped to HTTP, I think that this can limit the scope of
application of CoAP.

So I was wondering if is possible to design something similar to IPsec
at the CoAP level?

I attach some notes and an example just to better explain a
(possible?) alternative.

AUTHENTICATION

An option to include a MAC or a signature of the payload and of a
selected set of relevant options
--> this can be translated to HTTP with a (new?) HTTP Header option
defined in the same way

ENCRYPTION

The payload and a selected set of options can be encrypted at CoAP
level, leaving out of the process options that the proxy needs to work
properly.
--> HTTP mapping in this way can be preserved transparently.

Toy example of secured (?) CoAP mapped to HTTP:

### Request ###
POST <encrypted 7-bit URI with query>
Option1: plain-text
Option2: <encrypted>
MAC: <MAC or signature of the message>

<encrypted payload>

### Response ###
200 OK
Option1: plain-text
Option2: <encrypted>
MAC: <MAC or signature of the message>

<encrypted payload>

Angelo

On Mon, Nov 15, 2010 at 18:03, Robert Cragie
<[email-masked]> wrote:
> security is lost, unless we are talking essentially about session protocol
> translation only, which I don't think is the case here.
>
> residing on the edge limits the scope of application of CoAP but in then you
> same to say in your corrected version (as below) that it should reside on
> the edge of the network. Can you clarify where your 'ends' are?
>
> Robert
>
> http://www.gridmerge.com

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 16 Nov 2010 10:56:11 +0100

> the edge of the network. Can you clarify where your 'ends' are?

Sorry for the misunderstanding in the initial sentence, my opinion is
that the CoAP/HTTP proxy should be deployed on the edge of the
constrained network and not on the "traditional" Internet.

Angelo