Re: [Ace] Charter Update

[Göran Selander <[e-mail]>]

Hi Hannes

On your two missing aspects.

Starting point:
As far as I understand there are in this discussion (at least/so far) two different scopes of granularity of authorization, and different mechanisms associated to these.

  1.  One scope is about the authorization of access to resources in constrained environments, where the granularity of the authorization decision is on the level of RESTful requests, e.g. a client may be allowed to GET but not allowed to PUT or POST to that resource. This may be specified in an ACL or more flexibly using "access tokens" created by a third node.
  2.  Another scope is on the authorization on the granularity of nodes, e.g. a client is allowed or not to request anything from that constrained server. For this CoAP has defined different "security modes" specifying which credentials (symmetric keys, raw public keys, trust anchor for public key certificate) that allow a client to run DTLS with this server.

(These are named "resource authorization" and "protocol authorization" in draft-selander-core-access-control.) As far as I understand ACE includes work on both these mechanisms, e.g. on the mechanics of access tokens in constrained environments and on improvements of CoAP security modes.

The two mechanisms can/should be combined, so that you first ensure only authorized clients run DTLS and then match request against ACL or access token.

So what is the starting point? Looking only at the work on improving security modes, there is clearly not only the case of pre-provisioned secrets, as it could be public keys or trust anchors. Looking only at the work on a constrained node verifying an access token I agree that something like #1 makes sense - a secret key established between the device and the node creating the access token - at least at in some intermediate step. If someone wants to specify a default protocol between a constrained device and a non-constrained authorization server to establish this shared secret from, say, raw public keys in the device, I would not object to that be in scope too. But since this would typically be part of deployment and not run for each client request,  I could also consider draw the line at the point when the shared secret is established.

Now looking at the the whole picture with both protocol authorization and resource authorization, there is a clear advantage if it is not required to pre-provision credentials for both these cases, but use a security association provisioned for one case to the other ("bootstrapping" ;-). Considering the case of a resource server associated to an authorization server and multiple clients accessing resources on the resource server, it is most favorable that the single security association with the authorization server is starting point, since that anyway needs to be established for access tokens to be verified and since that is only one association. From this shared secret,  between resource server and authorization server (and using the required communication between client and authorization server)
other shared secrets or authorized public keys can be transported to the client and used between client and resource server.

So, restricting to normal (post deployment) operations I think assumption #1 makes sense, but I don't object to work on deployment as well.


Profiling existing solutions:
Yes that is of course the natural approach and is to some extent what is already going on. The important thing here is to agree on the design criteria, so that we can compare different proposed profiles.

Göran


From: Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, January 14, 2014 2:16 PM
To: Stefanie Gerdes <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Bert Greevenbosch <[e-mail]<mailto:[e-mail]>>, Göran Selander <[e-mail]<mailto:[e-mail]>>, Ludwig Seitz <[e-mail]<mailto:[e-mail]>>, Likepeng <[e-mail]<mailto:[e-mail]>>
Subject: Aw: [Ace] Charter Update

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" <[e-mail]<mailto:[e-mail]>>
An: [e-mail]<mailto:[e-mail]>
Cc: "Bert Greevenbosch" <[e-mail]<mailto:[e-mail]>>, "Göran Selander" <[e-mail]<mailto:[e-mail]>>, "Ludwig Seitz" <[e-mail]<mailto:[e-mail]>>, Likepeng <[e-mail]<mailto:[e-mail]>>
Betreff: [Ace] Charter Update
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

_______________________________________________
Ace mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ace