Subject: [Ace] Draft ACE Charter

From: Likepeng <[email-masked]>
Date: Wed, 11 Dec 2013 10:11:17 +0000

Hello all,

Welcome to the list!

The purpose of this list is to organize interest in a group to define the charter for work on Authentication and Authorization for Constrained Environments.

Our mailing list can be found at (1), existing work can be found at (2), and draft charter can be found at (3).

We welcome your feedback!

Thanks,

Kind Regards
Kepeng & Stefanie

(1)Mailing List

https://www.ietf.org/mailman/listinfo/ace

(2)Existing work:

Use Cases:
http://tools.ietf.org/id/draft-garcia-core-security
http://tools.ietf.org/id/draft-greevenbosch-core-authreq
http://tools.ietf.org/id/draft-seitz-core-sec-usecases

Solutions
http://tools.ietf.org/id/draft-gerdes-core-dcaf-authorize
http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration
http://tools.ietf.org/id/draft-selander-core-access-control
http://tools.ietf.org/id/draft-zhu-core-groupauth
http://tools.ietf.org/id/draft-pporamba-dtls-certkey
http://tools.ietf.org/id/draft-schmitt-two-way-authentication-for-iot
http://tools.ietf.org/id/draft-seitz-core-security-modes

(3)Draft Charter - Authentication and Authorization for Constrained Environment (ACE)

The CoAP (Constrained Application Protocol) is a light-weight application layer protocol, especially suitable for applications such as smart energy, smart home, building automation, remote patient monitoring etc. Due to the nature of these applications, including a critical, unattended infrastructure and usage in the personal sphere, security and privacy protection are critical components.

Currently, a problem with constrained devices is the realization of such secure communication. The devices only have limited resources such as memory, storage and transmission capacity. These constraints severely limit the security functions and communications the device can perform. Missing functionality includes authentication, which provides trust and ensures an entity is who it says it is, and authorization, which defines and enforces access rights for different clients.

The ACE WG focuses on providing constrained devices with the necessary prerequisites to use REST operations in a secure way. Constrained devices will thus be enabled to authenticate communications from other (constrained or less-constrained) devices, to communicate securely with them and to verify their individual authorization to access specific resources. To achieve this, ACE will be able to employ an architecture with one or more trusted less-constrained devices which will relieve the constrained nodes from complex security related tasks (e.g. managing authorization policies and a large number of keys). ACE will use CoAP and employ security properties of DTLS whenever possible.

The ACE WG has the following tasks:
- Document the use cases and high-level requirements for secured communication between constrained devices.
- Define certificate profiling (what kinds of certificates and which attributes are to be used).
- Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication.
- Define an access ticket and authorization information format suitable for constrained devices.
- Define bootstrapping for authorization information using the Resource Directory.

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 11 Dec 2013 14:32:53 +0100

On 12/11/2013 11:11 AM, Likepeng wrote:
> Hello all,
>
> Welcome to the list!
>
> The purpose of this list is to organize interest in a group to define
> the charter for work on Authentication and Authorization for Constrained
> Environments.
>

Comments inline.

> (3)Draft Charter – Authentication and Authorization for Constrained
> Environment (ACE)
> [...]
> Currently, a problem with constrained devices is the realization of such
> secure communication. The devices only have limited resources such as
> memory, storage and transmission capacity. These constraints severely
> limit the security functions and communications the device can perform.
> Missing functionality includes authentication,

I would challenge this statement, there is DTLS and it can provide both 
client and server authentication depending on the mode that is used. 
Even if you claim that DTLS isn't usable on constrained devices since it 
is too heavyweight (note that I don't claim this, but someone might), 
profiling DTLS to constrained devices is clearly work that DICE is covering.

>[...]
> To achieve this, ACE will be able to employ an architecture
> with one or more trusted less-constrained devices which will relieve the
> constrained nodes from complex security related tasks (e.g. managing
> authorization policies and a large number of keys).

Why should we limit ourselves to this approach? There might very well be 
solutions, that don't require a "big brother"-third-party and that still 
cover several relevant use cases.

> [...]
> - Document the use cases and high-level requirements for secured
> communication between constrained devices.
>
It's probably just the wording, but to me this sounds like Ace would 
only look at CommSec use cases and requirements.

> attributes are to be used).
For what purpose does Ace intend to use these certs? They seem to come 
out of nowhere here.

> [...]
Do we really want to call those things 'tickets'? Everyone and their 
grandmother are going to assume Ace does something akin to Kerberos.

Steffanie Gerdes, Olaf Bergmann, Göran Selander and I had agreed to call 
those things 'tokens' or 'authorization tokens'. Would that be 
"consensusable"?

> - Define bootstrapping for authorization information using the Resource
What if there is no Resource Directory? Don't we want to define security 
bootstrapping for such cases too?

/Ludwig

PS: I would have appreciated to get an invitation to this list, and I 
guess the other people who authored the drafts listed as "Existing work" 
would do so too. It would probably also be ok to announce Ace on the 
CoRE and DICE mailinglists.

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Dec 2013 15:02:05 +0100

Hi Ludwig,

you point out a number of ways in which the proposed text could be misread, and I think that is good input.

I would like to make two specific points from a CoRE point of view:

> Why should we limit ourselves to this approach? There might very well be solutions, that don't require a "big brother"-third-party and that still cover several relevant use cases.

I read this as a requirement that the approach should *enable* the use of less-constrained devices, not to *require* their use.  If your devices are powerful enough not to need help, great.  If they aren’t, more than two parties may be needed, and ACE should be flexible enough to support that scenario.

> What if there is no Resource Directory? Don't we want to define security bootstrapping for such cases too?

If that means that ACE is essentially reinventing another Resource Directory so it doesn’t have to use the existing one, I think my answer would be no.   But if you have ways in mind to do authorization bootstrapping without such a rendezvous point, please do go ahead and tell us more about what needs to be done to make this part of this work.

Grüße, Carsten

---

From: peter van der Stok <[email-masked]>
Date: Wed, 11 Dec 2013 15:18:06 +0100

When there is no resource directory I don't see an immediate need to 
reinvent one.
There is all the work of DNSSD wg which supports service discovery over 
many network topologies.
Introducing that technology into the secure bootstrapping seems viable 
to me.

Peter

>>> 
>> What if there is no Resource Directory? Don't we want to define 
>> security bootstrapping for such cases too?
> 
> If that means that ACE is essentially reinventing another Resource
> Directory so it doesn’t have to use the existing one, I think my
> answer would be no.   But if you have ways in mind to do authorization
> bootstrapping without such a rendezvous point, please do go ahead and
> tell us more about what needs to be done to make this part of this
> work.
> 
> Grüße, Carsten
> 
> _______________________________________________
> Ace mailing list
> [email-masked]

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Wed, 11 Dec 2013 17:06:40 +0000

Hi Peter,

>Introducing that technology into the secure bootstrapping seems viable

Just to clarify: here are you hinting at credential discovery fully done
in DNS (e.g. via DANE), or at some other mechanism that is based on the
device-name associations established via DNS-SD?

Cheers

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Dec 2013 14:54:16 -0500

> (2)Existing work:

I added of the items to my reading list, to discover that half of them were
already on my reading list, and some of them were marked as read :-)
(That's good, it means that this work isn't coming out from nowhere)

    > Currently, a problem with constrained devices is the realization of
    > such secure communication. The devices only have limited resources such
    > as memory, storage and transmission capacity. These constraints
    > severely limit the security functions and communications the device can
    > perform. Missing functionality includes authentication, which provides
    > trust and ensures an entity is who it says it is, and authorization,
    > which defines and enforces access rights for different clients.

I agree with all the words, but I think that many will get caught up on
authentication, and fail to read about authorization.

I suggest, going forward you write:

  The constrained devices while unable to include many sophisticated
  features, such as user interfaces and configuration files, nevertheless
  need to perform authentication and authorization operations.  Two
  items which must be sized to fit include authentication and authorization.
  Authentication is ensuring an entity is who it says it is.  Authentication
  is well understood, and the group must simply agree upon one method that fits.
  Authorization is less well understood, and this group will focus on this
  aspect first.

>  The ACE WG focuses on providing constrained devices with the necessary
>  prerequisites to use REST operations in a secure way. Constrained

I think that examples of prerequisites should be included here.

>  devices will thus be enabled to authenticate communications from other
> (constrained or less-constrained) devices, to communicate securely with
> them and to verify their individual authorization to access specific
> resources. To achieve this, ACE will be able to employ an architecture
> with one or more trusted less-constrained devices which will relieve
> the constrained nodes from complex security related tasks
> (e.g. managing authorization policies and a large number of keys). ACE
> will use CoAP and employ security properties of DTLS whenever possible.

You have made an architectural assumption here which may be appropriate, but
may also be premature.  I'm not objecting to the statement, I just want
everyone to be clear that this statement is being made.

Question:
  - is authorization to make authorization statements in scope?
    (i.e. meta operations)
  - should authorization be expressed in YANG?
  - should authorization to express authorization be expressed in YANG?

(I know little about YANG, but it seems to be what all the cool kids are doing)

    > communication between constrained devices.

Yes, we need use cases, but let's not get bogged down in them.

    > attributes are to be used).

I think it's important to understand which parts deal with certificates,
and if we are doing CAs as well as AAs.

    > - Define a mechanism for authenticated and protected transfer of
    > authorization information suitable for constrained device to
    > constrained device communication.

    > - Define bootstrapping for authorization information using the Resource

Maybe a reference on "Resource Directory" is useful here.
I think it's a CORE/CoAP thing, right?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Dec 2013 21:49:51 +0100

Hi Michael,

>  - is authorization to make authorization statements in scope?

Absolutely.  That is the cornerstone of pulling in the big brothers.

>  - should authorization to express authorization be expressed in YANG?

No.

> (I know little about YANG, but it seems to be what all the cool kids are doing)

YANG is a fine data modeling language, but it is currently focused on netconf.
I’m not sure the netconf ecosystem (with XML, SSH over TCP, …) is a good fit right now.
But I’m sure we’ll talk to the COMAN people about much of this anyway.
There is a very thin line between operations on authorization state and other configuration management.

> and if we are doing CAs as well as AAs.

My view here is that (X.509) certificates exist, and people are finding uses for them, so we should spend energy in making their use as interoperable as possible, even if they aren’t otherwise a perfect fit to the ACE architecture.  There are other cert-like structures such as JWTs we should look into.  When thinking about the CAs for the certs, we shouldn’t automatically think PKI.

> I think it's a CORE/CoAP thing, right?

Yes.

http://tools.ietf.org/html/draft-ietf-core-resource-directory

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Dec 2013 20:38:28 -0500

Carsten Bormann <[email-masked]> wrote:
    > My view here is that (X.509) certificates exist, and people are finding
    > uses for them, so we should spend energy in making their use as
    > interoperable as possible, even if they aren’t otherwise a perfect fit
    > to the ACE architecture.  There are other cert-like structures such as
    > JWTs we should look into.  When thinking about the CAs for the certs,
    > we shouldn’t automatically think PKI.

I think you mean to write "PKIX", as "PKI" is a generic term.

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 11 Dec 2013 18:36:32 -0800

Carsten,

Could you elaborate your argumentation about YANG?

When I read
"There is a very thin line between operations on authorization state and
other configuration management."
I think
"great, so a need to run only a single set of tools on my nodes to enable
both".

Sure, the netconf ecosystem (XML, SSH over TCP, etc.) does not fit, but
maybe this is a good moment to work with COMAN to produce a constrained
version, for example of RESTCONF. In a perfect world, a single protocol
could serve multiple purposes, e.g. by mapping different states to be
managed to different resources.

Thomas

---

From: Likepeng <[email-masked]>
Date: Thu, 12 Dec 2013 06:36:22 +0000

Hi Ludwig,

Thanks for your feedback.

>I would challenge this statement, there is DTLS and it can provide both client and server authentication depending on the mode that is used. Even if you claim that DTLS isn't usable on constrained devices since it is too heavyweight (note that I don't claim this, but someone might), profiling DTLS to constrained devices is clearly work that DICE is covering.

We change the statement to the following:
While authentication is well understood, at least for communication security, there are only insufficient means for authorization. Authentication is considered in this context as it is needed as a prerequisite to performing authorization, including the authorization to change the authorization state.

>Why should we limit ourselves to this approach? There might very well be solutions, that don't require a "big brother"-third-party and that still cover several relevant use cases.

As explained by Carsten, the main intention is to *enable* the use of less-constrained devices, not to *require* their use.

>For what purpose does Ace intend to use these certs? They seem to come out of nowhere here.

We change the sentence to the following, to clarify the purpose to use certificates.

Flesh out profiles for the certificates that already are part of CoAP’s security architecture as well as possibly for any ACE-specific use of certificates.

>Do we really want to call those things 'tickets'? Everyone and their grandmother are going to assume Ace does something akin to Kerberos.
>Steffanie Gerdes, Olaf Bergmann, Göran Selander and I had agreed to call those things 'tokens' or 'authorization tokens'. Would that be "consensusable"?

We change it to "access token". See the following sentence:
- Define an access token and authorization information format suitable for constrained devices.

>What if there is no Resource Directory? Don't we want to define security bootstrapping for such cases too?

See Carsten's response to this one. We add the reference to "Resource Directory". Please refer to a separate email about the updated charter.

>It would probably also be ok to announce Ace on the CoRE and DICE mailinglists.

Yes, it was done. Sorry for the delay.

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Ludwig Seitz
发送时间: 2013年12月11日 21:33
收件人: [email-masked]
主题: Re: [Ace] Draft ACE Charter

On 12/11/2013 11:11 AM, Likepeng wrote:
> the charter for work on Authentication and Authorization for 
> Constrained Environments.
>
> Our mailing list can be found at (1), existing work can be found at 
> (2), and draft charter can be found at (3).
>

Comments inline.

> Environment (ACE) [...] Currently, a problem with constrained devices 
> is the realization of such secure communication. The devices only have 
> limited resources such as memory, storage and transmission capacity. 
> These constraints severely limit the security functions and 
> communications the device can perform.

I would challenge this statement, there is DTLS and it can provide both client and server authentication depending on the mode that is used. 
Even if you claim that DTLS isn't usable on constrained devices since it is too heavyweight (note that I don't claim this, but someone might), profiling DTLS to constrained devices is clearly work that DICE is covering.

>[...]
> To achieve this, ACE will be able to employ an architecture  with one 
>or more trusted less-constrained devices which will relieve the  

> communication between constrained devices.
It's probably just the wording, but to me this sounds like Ace would only look at CommSec use cases and requirements.

> attributes are to be used).
For what purpose does Ace intend to use these certs? They seem to come out of nowhere here.

> suitable for constrained devices.
Do we really want to call those things 'tickets'? Everyone and their grandmother are going to assume Ace does something akin to Kerberos.

Steffanie Gerdes, Olaf Bergmann, Göran Selander and I had agreed to call those things 'tokens' or 'authorization tokens'. Would that be "consensusable"?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: peter van der Stok <[email-masked]>
Date: Thu, 12 Dec 2013 08:48:31 +0100

Hi Thomas,

Bert and I started on RESTCONF draft with the subject core management 
interfaces (CoMI).
draft-vanderstok-core-comi-01.
  if I understand you correctly, the draft proposal is a first step to 
your single protocol serving multiple purposes.
After comments by Juergen, we are preparing a second more CBOR, JSON 
focussed version.

Looking forward to your comments,

Peter

Thomas Watteyne schreef op 2013-12-12 03:36:
> "There is a very thin line between operations on authorization state
> and other configuration management."
> I think
> "great, so a need to run only a single set of tools on my nodes to
> enable both".
> 
> Sure, the netconf ecosystem (XML, SSH over TCP, etc.) does not fit,
> but maybe this is a good moment to work with COMAN to produce a
> constrained version, for example of RESTCONF. In a perfect world, a
> single protocol could serve multiple purposes, e.g. by mapping
> different states to be managed to different resources.
> 
> Thomas
>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 11 Dec 2013 23:54:06 -0800

Peter, Bert,
Thanks for the pointer, this does look exactly like what I was describing.
I will follow-up with comments.
Thomas

On Wed, Dec 11, 2013 at 11:48 PM, peter van der Stok <[email-masked]>wrote:

>  if I understand you correctly, the draft proposal is a first step to your
> single protocol serving multiple purposes.

---

From: Likepeng <[email-masked]>
Date: Thu, 12 Dec 2013 08:22:17 +0000

Hi Michael,

Thanks, now the new text is:

Currently, a problem with constrained devices is the realization of such secure operation. Constrained devices are unable to include many sophisticated features, such as user interfaces and configuration files, but nevertheless need to perform authentication and authorization operations. While authentication is well understood, at least for communication security, there are only insufficient means for authorization. Authentication is considered in this context as it is needed as a prerequisite to performing authorization, including the authorization to change the authorization state.

>I think that examples of prerequisites should be included here.

OK, we include some examples. Here is the new text:
The ACE WG focuses on providing constrained devices with the necessary prerequisites to use REST operations in a secure way such as authorization information and the related keying material.

I believe other comments are covered by another email from Carsten.

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Michael Richardson
发送时间: 2013年12月12日 3:54
收件人: [email-masked]
主题: Re: [Ace] Draft ACE Charter

    > (2)Existing work:

I added of the items to my reading list, to discover that half of them were already on my reading list, and some of them were marked as read :-) (That's good, it means that this work isn't coming out from nowhere)

    > which defines and enforces access rights for different clients.

I agree with all the words, but I think that many will get caught up on authentication, and fail to read about authorization.

>  The ACE WG focuses on providing constrained devices with the 
> necessary  prerequisites to use REST operations in a secure way. 
> Constrained

>  devices will thus be enabled to authenticate communications from 
> other (constrained or less-constrained) devices, to communicate 
> securely with them and to verify their individual authorization to 
> access specific resources. To achieve this, ACE will be able to employ 
> an architecture with one or more trusted less-constrained devices 
> which will relieve the constrained nodes from complex security related 
> tasks (e.g. managing authorization policies and a large number of 
> keys). ACE will use CoAP and employ security properties of DTLS whenever possible.

You have made an architectural assumption here which may be appropriate, but may also be premature. I'm not objecting to the statement, I just want everyone to be clear that this statement is being made.

Question:

    > attributes are to be used).

I think it's important to understand which parts deal with certificates, and if we are doing CAs as well as AAs.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting for hire =-

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 13 Dec 2013 10:05:36 +0100

> "great, so a need to run only a single set of tools on my nodes to

Reusing the same tool for some other means is mostly frowned upon by 
crytpo people ;-)

Earnestly: YANG is about data modelling, so you could use it to model 
authorization data. Has that been done before outside of Netconf?

My preference would be to use the same notation as in relevant other 
security RFCs e.g. TLS (or perhaps JWT/JWE/JWS if we use JSON) to 
describe our data structures.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se