Subject: [Ace] Charter Update

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 14 Jan 2014 09:34:53 +0100

Hi everyone,

We updated the draft charter according to helpful input from Ludwig
Seitz and Göran Selander. I hope this improves the readability of the
charter and clarifies the scope of ACE.

We also added an item to the task list for documenting the applicability
of various security mechanisms to address for example symmetric vs
public key approaches.

Please feel free to provide further comment.

Best regards,
Steffi

Draft Charter V0.1- 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.

There are certain, necessary security functions that constrained
devices cannot readily perform due to resource constraints. In
particular, constrained devices often have no or very limited user
interfaces. While authentication is well understood, at least for
communication security, there are only unsufficient means for
authenticated authorization. Especially cases where pre-provisioned
ACLs scale badly or where more sophisticated identity and access
management is needed are not covered. This includes the case where it
is infeasible for a constrained server to perform the authorization
decision and thus needs access to externally generated authorization
information to be able to enforce the decision. Authentication is
considered in this context as it is needed as a prerequisite to
performing authorization, including the authorization to change the
authorization state.

The ACE WG aims to enable authorized access to resources in constrained
environments, using CoAP and leveraging DTLS security where possible.
Constrained devices will thus be enabled to authenticate operations 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
additional less-constrained devices in order to relieve the constrained
nodes from complex security related tasks (e.g. managing authorization
policies and a large number of keys).

The ACE WG has the following tasks:

    Document the use cases and high-level requirements for secured
communication between constrained devices. (This task is pursued as a
means to the other ends, not as an end in itself.)
   Flesh out profiles for certificates used for authenticated authorization.
   Document the applicability of the various security mechanisms with
respect to resource usage (RAM, message round trips, power consumption
etc.).
   Define a mechanism for authenticated and protected transfer of
authorization information suitable for constrained device to constrained
device communication.
   Define formats for access tokens and for authorization information
that are suitable for constrained devices.
   Define bootstrapping for authorization information using the Resource
Directory (see ​
http://tools.ietf.org/html/draft-ietf-core-resource-directory).

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
    ​http://tools.ietf.org/html/draft-sarikaya-ace-secure-bootstrapping

---

From: Göran Selander <[email-masked]>
Date: Tue, 14 Jan 2014 13:15:35 +0000

Hi Stefanie

Thanks for considering our input, below are some more detailed comments.
Sorry for iterating some things that has already been discussed on the list.

On 1/14/14 9:34 AM, "Stefanie Gerdes" <[email-masked]<mailto:[email-masked]>> wrote:

Hi everyone,

Best regards,
Steffi

interfaces.

I can't see that this property of constrained devices that you single out
(limited user interface) is specifically relevant to the work proposed for ACE.
How about instead mentioning properties like limited processing and power
capabilities or just refer to LWIG terminology?

While authentication is well understood, at least for
communication security,

I agree that CoRE has decided for DTLS, but as we know DTLS was not
designed for constrained environments and there are improvements to be
made, e.g. the ongoing work in DICE. There are also potential improvements
to the DTLS handshake. Considering this, I would say that authentication
is not yet "well understood".

there are only unsufficient means for
authenticated authorization.

"authenticated authorization" has been discussed on this list, but those
who did not follow that thread may interpret this concept in different
ways. I think it would be good to stick to the word "authorization" in the
charter. More below.

I propose to replace the previous sentence with something spelling out
what the problem is, like:

"The CoRE WG has selected DTLS as the preferred protocol for
authentication and communication security in constrained devices. For
authorization, however, it may be infeasible for a constrained device to
make authorization decisions and manage authorization policies."

Especially cases where pre-provisioned
ACLs scale badly or where more sophisticated identity and access
management is needed are not covered. This includes the case where it
is infeasible for a constrained server to perform the authorization
decision and thus needs access to externally generated authorization
information to be able to enforce the decision.

To harmonize with previous proposed text replace last sentence with:

"This includes the case where a constrained device enforces an
externally made authorization decision."

Authentication is
considered in this context as it is needed as a prerequisite to
performing authorization,

I guess this is intended as explanation of "authenticated authorization".

I have two comments (this is in part continuing the thread of
http://www.ietf.org/mail-archive/web/core/current/msg05132.html):

1. I agree that some sort of verification of access token is needed for
authorization, but do we exclude the case of (OAuth) Bearer Tokens? I.e. that
there is no information binding the entity making the request to the
access token besides being in possession of the token. In the case
of Bearer Tokens I'm not sure the term "authentication" is correct as
it is just a matter of verifying a digital signature or a MAC (RFC4949 "authenticate").

2. What I think this all boils down to is that the consumer of the
authorization decision is:
(a) verifying the integrity of the authorization information, and
(b) verifying that the source of the authorization information is allowed
by local policy ("trusted") to issue authorization decisions, and
(c) verifying that the subject of the authorization decision coincides with
the requesting entity.
If we accept Bearer Tokens then (c) is optional, else mandatory.

Maybe (some parts of) this what you refer to as "authenticated authorization"?
I don't think we need go into such details in the charter, just to see if we agree
on the lower level.

including the authorization to change the
authorization state.

This latter part is important, but IMHO is not specifically associated to the
discussion about the need for authentication. How about:

"The authorization solution needs to consider the ability to change
authorization state in an authorized way, including expiry or revocation
of authorization decisions."?

Replace "authenticate operations" with "authenticate requests for
operations"

Proposal: remove "a large number of". The number of keys per constrained
device is not necessarily a problem, but it may benefit from support with
key management, e.g. derivation of session keys.

I think the second sentence can be left out. Use cases and requirements is
commonly understood as an initial activity to set the scope and
constraints for the work.

   Flesh out profiles for certificates used for authenticated
authorization.

If I understand this right, this is about the X.509 certificates used in
CoAP/DTLS for the certificate security mode. What about security modes
that do not make use of certificates (e.g. as in draft-seitz-security-modes)?
How about generalizing slightly to

"Optimize existing and design new security modes for CoAP, e.g. profiles
for X.509 certificates used in the CoAP/DTLS certificate security mode"

I think this is valuable, I'm just reflecting of the scope of the current text.

Say that you can save one round trip by making a some symmetric crypto
operation on the constrained resource server. Now we need to decide if we
should make that trade off, i.e. introduce crypto to save on communication
needs and thus reduce power consumption. This is wider than just
"applicability of security mechanisms"?

Another naive example: say you have the option to have a security protocol
with either a few large messages or several small messages, what is
preferred?

How about formulating this as "design criteria for security protocol"  or
something similar instead of "applicability of security mechanisms"?
Maybe there is already a good reference to use as a starting point? LWIG?

In a recent ACE thread, we discussed the option of either client or server
being non-constrained. How about replacing "constrained device to constrained
device communication" with "constrained environments"?

Best regards,
Göran

Existing work:

Use Cases:

Solutions:

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 14 Jan 2014 14:16:19 +0100 (CET)

Thanks for the update, Stefanie.

One aspect I do not yet find covered in the document is about the assumptions that serve as a starting point, as I tried to explain in this email:

http://www.ietf.org/mail-archive/web/ace/current/msg00043.html

#1) You already have a secret pre-provisioned on the device. You want to leverage that existing secret to access new services.

#2) You have no secret pre-provisioned. The approaches here are sometimes referred as imprinting or pairing.

In the response to my mail Carsten said that both cases have to be covered in the scope of the group. I have not heard other folks providing their views but I was wondering whether this topic deserves to get mentioned. Currently, there is no solution draft for #2 (at least not that I can see it).

Another important aspect that got mentioned in discussions and also in the drafts is that there is the desire to have an offline authorization operation. This has quite some implications for the protocol designs and rules out techniques likes AAA or some OAuth extensions. The resource server has to support an authorization mode where any request it receives can be processed locally without having to consult with an identity management server. I was not quite sure whether this is captured in the current text version (one of the paragraphs sounded a bit fuzzy to me).

The text about authentication and authorization is still a bit confusing in the charter and so is the dependency on CoAP.

For authentication there are actually several types of authentication, namely (a) from the device to the identity provider / authorization server and (b) authentication information about the device that is provided by the authorization server/ identity provider to the resource server / relying party. While the authentication of the device to the identity provider is needed authentication of the device to the resource server is not necessary (only key confirmation is).

I actually believe that the charter text could be even more specific. For category #1 solutions I believe we are talking about applying existing solutions to the IoT environment. The only solutions that IMHO fit the requirements so far are Kerberos, OAuth, and (attribute) certificates. Why not to start the entire write-up with the though process some of us went through, namely

a) There are existing federated authentication, authorization and key establishment protocols (Kerberos, OAuth, ...)

b) We want to apply those to the IoT environment but there are problems when meeting the constraint nature of these devices (no UI, no ability for the device to interact with an identity management server in real-time).

c) We want to select a mechanism and profile it so that it can be used in the IoT context.

What do you think?

Ciao

Hannes

Gesendet: Dienstag, 14. Januar 2014 um 08:34 Uhr

Von: "Stefanie Gerdes" <[email-masked]>

An: [email-masked]

Cc: "Bert Greevenbosch" <[email-masked]>, "Göran Selander" <[email-masked]>, "Ludwig Seitz" <[email-masked]>, Likepeng <[email-masked]>

Betreff: [Ace] Charter Update

Hi everyone,

public key approaches.

Best regards,

Steffi

Environment (ACE)

authorization state.

etc.).

device communication.

Directory (see ​

Existing work:

Use Cases:

Solutions:

_______________________________________________

Ace mailing list

[email-masked]

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

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 16 Jan 2014 13:40:56 +0100

Hannes,

"Hannes Tschofenig" <[email-masked]> writes:

> One aspect I do not yet find covered in the document is about the
> assumptions that serve as a starting point, as I tried to explain in
> this email: 
> #1) You already have a secret pre-provisioned on the device. You want
> to leverage that existing secret to access new services. 
>  
> #2) You have no secret pre-provisioned. The approaches here are
> sometimes referred as imprinting or pairing.
>  
> In the response to my mail Carsten said that both cases have to be
> covered in the scope of the group. I have not heard other folks
> providing their views but I was wondering whether this topic deserves
> to get mentioned. Currently, there is no solution draft for #2 (at
> least not that I can see it).  

we did write up a proposal for #2 some time ago, with a couple of
proof-of-concept implementations. The corresponding I-D from Carsten has
expired, meanwhile.

For ACE, I would prefer the view that there is already a secret on the
device, either pre=provisioned or generated by means of
imprinting/pairing. I had the impression that this group has agreed on
this as well (and leaving the "bootstrapping" of keying material to,
e.g., solace. Do you think that ACE should address this instead?

> Another important aspect that got mentioned in discussions and also in
> the drafts is that there is the desire to have an offline
> authorization operation. This has quite some implications for the
> protocol designs and rules out techniques likes AAA or some OAuth
> extensions. The resource server has to support an authorization mode
> where any request it receives can be processed locally without having
> to consult with an identity management server. I was not quite sure
> whether this is captured in the current text version (one of the
> paragraphs sounded a bit fuzzy to me). 

At least there should be a sound default state so that the resource
server can work properly in case its identity management server (I
understand this as the entity that issues authorization tokens in this
context, right?) is unreachable. Isn't this addressed implicitely by the
usual goal of robust design?

Gruesse
Olaf

---

From: Likepeng <[email-masked]>
Date: Thu, 23 Jan 2014 10:58:53 +0000

Hi Goran,

Thanks for the feedback. They are very useful. Please see my responses.

>capabilities or just refer to LWIG terminology?

Limited user interface is relevant because the user can’t grant permissions from the user interface. That makes authorization more difficult. About limited processing and power capabilities, they are mentioned in the first paragraph.

>is not yet "well understood".

“Well understood” was removed.

>ways.

“Authenticated authorization” was changed in the paragraphs, but it is still in the task list. To be changed in the next version.

>make authorization decisions and manage authorization policies."

We changed it as the following:
CoAP provides a DTLS binding for authentication but does not address authorization.

>of authorization decisions."?

Now, it is listed as examples in the second paragraph:

Where are the authorization decisions stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be granted to other persons temporarily? How can access be revoked?

>operations".

Yes, changed.

>for X.509 certificates used in the CoAP/DTLS certificate security mode"

This is one of the open issues that sent out by Stefanie. Keep it open for now.

>key management, e.g. derivation of session keys.

We keep it because we can't really argue that the constrained devices won't need to manage any keys at all.

>constraints for the work.

Yes, removed.

>Maybe there is already a good reference to use as a starting point? LWIG?

In fact, for the task list, it is the key part. We didn’t change much about this, because we hope to get more discussions and do it later.

>device communication" with "constrained environments"?

Agree with the changes. To be changed.

Kind Regards
Kepeng

发件人: Ace [mailto:[email-masked]] 代表 G?ran Selander
发送时间: 2014年1月14日 21:16
收件人: Stefanie Gerdes; [email-masked]
抄送: Bert Greevenbosch; Ludwig Seitz; Likepeng
主题: Re: [Ace] Charter Update

Hi Stefanie

Hi everyone,

Best regards,
Steffi

Authentication is

Best regards,
Göran

Existing work:

Use Cases:

Solutions:

---

From: Göran Selander <[email-masked]>
Date: Thu, 23 Jan 2014 11:03:43 +0000

Hi Kepeng,

Thanks for looking back at the comments made. Meanwhile I’ve been putting the still relevant comments in the context the current draft charter so we have done some double work here. I’ll post that soon.

Göran

From: Likepeng <[email-masked]<mailto:[email-masked]>>
Date: Thursday 23 January 2014 11:58
To: Göran Selander <[email-masked]<mailto:[email-masked]>>, Stefanie Gerdes <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Bert Greevenbosch <[email-masked]<mailto:[email-masked]>>, Ludwig Seitz <[email-masked]<mailto:[email-masked]>>
Subject: Re: Charter Update

Hi Goran,

Yes, changed.

Yes, removed.

Kind Regards
Kepeng

发件人: Ace [mailto:[email-masked]] 代表 G?ran Selander
发送时间: 2014年1月14日 21:16
收件人: Stefanie Gerdes; [email-masked]<mailto:[email-masked]>
抄送: Bert Greevenbosch; Ludwig Seitz; Likepeng
主题: Re: [Ace] Charter Update

Hi Stefanie

Hi everyone,

Best regards,
Steffi

Authentication is

Best regards,
Göran

Existing work:

Use Cases:

Solutions:

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 23 Jan 2014 12:21:45 +0100

> Hi Goran,

[...]

> This is one of the open issues that sent out by Stefanie. Keep it open

To my understanding, both, v0.2 and v0.3, cover this already ("Define
profiles for certificates used for authenticated authorization."). I do
not see why X.509 is special here.

During the core meeting in Vancouver, this topic has been discussed a
lot, and there was at least some consent to address "the low hanging
fruit", including X.509 profiling hence I suppose there will be no doubt
that the cited task description includes the question on how X.509
certificates should be used.

Gruesse
Olaf

---

From: Göran Selander <[email-masked]>
Date: Thu, 23 Jan 2014 11:28:26 +0000

OK, see further discussion in recent mail. / Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 23 Jan 2014 11:40:43 +0000

Hi Olaf

>certificates should be used.

OK, thanks. The point I was trying to make is not about X.509
certificates, but that the charter v0.3 makes one single statement about
making the DTLS handshake lighter:

"Define profiles for certificates used for authenticated authorisation."

I find that a well founded but still special case. And item 4 on the list
of open issues is another. I would like to understand why item 4 would not
be in scope if this is.

Göran

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 23 Jan 2014 15:30:30 +0100

> making the DTLS handshake lighter:

I'd be very careful saying "making theDTLS handshake lighter" because
most people who read that will think of changing the DTLS handshake
protocol. This is not what you propose here, I guess.

> of open issues is another. I would like to understand why item 4 would not

I don't say that item 4 is out of scope. In fact, I think it is not only
in scope but it is already covered by the existing charter proposal.

Gruesse
Olaf

---

From: Göran Selander <[email-masked]>
Date: Thu, 23 Jan 2014 15:13:05 +0000

>protocol. This is not what you propose here, I guess.

No. OK, let¹s be more careful. This is about applying DTLS with certain
keys, PSK identities, certificate formats etc. to reduce processing etc.
in constrained devices.
What shall we call that? ³Profiling DTLS handshake²?

>in scope but it is already covered by the existing charter proposal.

I agree that it is covered in

"Existing authentication and authorization protocols are used and
re-applied for use with constrained devices, where applicable. This
requires relevant specifications to be reviewed for suitability,
selecting a subset of them, restricting the options within each of the
specifications. Some functionalities  may, however, not be available in
existing protocols and for those cases new functionality has to be
standardized.²

However, it is not explicit in any task, which I guess is why it is
still considered an open issue.

Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 27 Jan 2014 17:13:05 +0100

Hi Göran,

> device communication" with "constrained environments"?

There was some discussion about this in Vancouver and we came to the
conclusion that although we want to cover cases where one of the devices
is unconstrained, the most interesting case is where both devices are
constrained and we want to be able to support this case. This is why we
emphasized this point.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Tue, 28 Jan 2014 09:32:41 +0000

Hi Steffi,

>constrained and we want to be able to support this case. This is why we

OK, thanks. I take it that is what you called "peer-to-peer
authorisation², right?

Assuming that there are different mechanisms for transfer of authorisation
information suitable depending on whether either client or resource server
or both are constrained, I would like to make clear that this is all in
scope. 
How about:

"Define a mechanism for authenticated and protected transfer of
authorization information suitable for constrained environments, in
particular 
when both client and server are constrained.²

Göran