Subject: [Ace] New Version of Proposed Charter

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 20 Jan 2014 16:49:02 +0100

Hi everybody,

Due to several complaints about the readability of the proposed charter,
we revised it and, with the assistance of Hannes, came up with a new
proposal which provides some more motivation and background to our work.

We hope that this version includes the relevant topics and reflects the
previous discussion. Please let us know if something relevant is missing.

In six weeks, at the IETF meeting, we should be able to present a
readable charter that has wide consensus in the IETF. So this is a good
time to check that we agree about the charter within the ACE community.

Best regards,
Kepeng and Steffi

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

New developments in the IETF include protocols with a specific focus on
energy-efficiency to be used e.g. in environments where network nodes
are limited in CPU, memory, and power-resources. It was observed that
Internet protocols can be applied to these constrained environments,
often only requiring minor tweaking and profiling. In other cases, new
protocols such as the Constrained Application Protocol (CoAP) have been
defined to address the specific requirements of constrained devices and
networks.

Constrained devices raise authentication and authorization questions.
For example, a door lock has to authorize the person seeking access
using a digital key. 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? These types of questions have been answered by existing
protocols for use cases outside the constrained environment. But in
constrained environment, constrained devices cannot readily handle these
issues due to resource constraints. CoAP provides a DTLS binding for
authentication but does not address authorization.

 The IETF has a long history in developing three party authentication
and authorization protocols for distributed environments. Examples
include Kerberos, the Public Key Infrastructure (PKI), the
Authentication, Authorization, and Accounting (AAA) infrastructure, and
the Web Authorization Protocol (OAuth). All these protocols enjoy
widespread deployment on the Internet. Although they all aim to solve
the same goal they offer quite different functions and utilize different
message exchanges. These differences are motivated by the main
deployment use cases they were designed for.

Requirements derived from use cases indicate the suitability of already
existing work, such as OAuth, as a solution for constrained
environments. These protocols were, however, not optimized for
constrained environments. Additional requirements that need to be taken
into account are the lack of a suitable user-interface for obtaining the
consent of the user and the inability of embedded devices to contact an
identity management/authorization server in real-time with every access
request.

This working group therefore aims for a standardized solution for
authentication and authorization 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 requests for 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).

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. Thus, existing work can be leveraged and the group
benefits from available security analysis, implementation, and
deployment experience. Moreover, a standardized solution for federated
authentication and authorization will help to stimulate the deployment
of IoT devices offering increased security.

To be successful this working group requires expertise in security,
privacy, and a good understanding of usability in the constrained
environment space. This work does not make the assumption that the party
offering application layer services is always the same party offering
network access services.

The ACE WG has the following tasks:

 Document the use cases and high-level requirements for secured
communication between constrained devices.

 Define profiles for certificates used for authenticated authorization.

 Document the applicability of the main authentication and key exchange
protocols with respect to resource usage (RAM, message round trips,
power consumption etc.) and their suitability for the use cases.

 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).

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 22 Jan 2014 11:34:27 -0500

Hi Stefanie,

This updated version of the ACE charter looks very good.  I wanted to
get your opinion on a question that came up during some author
discussions related to DICE.  The question is:

- Will ACE cover the transfer of authorization info to a CoAP forward
proxy to send unicast/multicast DTLS messages on behalf of a Client?

 (Reference:
http://tools.ietf.org/html/draft-ietf-core-coap-18#section-11.2 )

Best Regards,

Akbar

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Stefanie Gerdes
Sent: Monday, January 20, 2014 10:49 AM
To: [email-masked]
Subject: [Ace] New Version of Proposed Charter

Hi everybody,

We hope that this version includes the relevant topics and reflects the
previous discussion. Please let us know if something relevant is
missing.

Best regards,
Kepeng and Steffi

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

---

From: Likepeng <[email-masked]>
Date: Thu, 23 Jan 2014 03:21:19 +0000

>Requirements derived from use cases indicate the suitability of already existing work, such as OAuth, as a solution for constrained environments.

I received offline question about how to use OAuth as a solution for constrained environments.

I guess others who are not familiar with OAuth may have the same question.

Maybe Hannes can help here?

Thanks,

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Stefanie Gerdes
> 发送时间: 2014年1月20日 23:49
> 收件人: [email-masked]
> 主题: [Ace] New Version of Proposed Charter
> 
> Hi everybody,
> 
> Due to several complaints about the readability of the proposed charter, we
> revised it and, with the assistance of Hannes, came up with a new proposal
> which provides some more motivation and background to our work.
> 
> In six weeks, at the IETF meeting, we should be able to present a readable
> charter that has wide consensus in the IETF. So this is a good time to check
> that we agree about the charter within the ACE community.
> 
> Best regards,
> Kepeng and Steffi
> 
> energy-efficiency to be used e.g. in environments where network nodes are
> limited in CPU, memory, and power-resources. It was observed that Internet
> protocols can be applied to these constrained environments, often only
> requiring minor tweaking and profiling. In other cases, new protocols such as
> the Constrained Application Protocol (CoAP) have been defined to address the
> specific requirements of constrained devices and networks.
> 
> For example, a door lock has to authorize the person seeking access using a
> digital key. 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? These types of
> questions have been answered by existing protocols for use cases outside the
> constrained environment. But in constrained environment, constrained
> devices cannot readily handle these issues due to resource constraints. CoAP
> provides a DTLS binding for authentication but does not address
> authorization.
> 
>  The IETF has a long history in developing three party authentication and
> authorization protocols for distributed environments. Examples include
> Kerberos, the Public Key Infrastructure (PKI), the Authentication,
> Authorization, and Accounting (AAA) infrastructure, and the Web
> Authorization Protocol (OAuth). All these protocols enjoy widespread
> deployment on the Internet. Although they all aim to solve the same goal they
> offer quite different functions and utilize different message exchanges. These
> differences are motivated by the main deployment use cases they were
> designed for.
> 
> Requirements derived from use cases indicate the suitability of already existing
> work, such as OAuth, as a solution for constrained environments. These
> protocols were, however, not optimized for constrained environments.
> Additional requirements that need to be taken into account are the lack of a
> suitable user-interface for obtaining the consent of the user and the inability
> of embedded devices to contact an identity management/authorization server
> in real-time with every access request.
> 
> authentication and authorization 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 requests for
> 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).
> 
> 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. Thus, existing work can be leveraged and
> the group benefits from available security analysis, implementation, and
> authentication and authorization will help to stimulate the deployment of IoT
> devices offering increased security.
> 
> To be successful this working group requires expertise in security, privacy, and
> a good understanding of usability in the constrained environment space. This
> work does not make the assumption that the party offering application layer
> services is always the same party offering network access services.
> 
> protocols with respect to resource usage (RAM, message round trips, power
> consumption etc.) and their suitability for the use cases.
> 
>  Define formats for access tokens and for authorization information that are
> suitable for constrained devices.
> 
> Directory (see http://tools.ietf.org/html/draft-ietf-core-resource-directory).
>

---

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

I think the charter in its current version is setting the stage very well
and provides a good motivation for the work needed. Some further comments
inline. Some comments are partially answered by Kepeng in a recent email.

(Thanks for considering some of my previous comments!)

On 20/01/14 16:49, "Stefanie Gerdes" <[email-masked]> wrote:

>revoked? 

1. Yes this is good, and I think the issues around authorisation lifetime
or revocation deserves should also be listed in the tasks below

>These types of questions have been answered by existing
>issues due to resource constraints.

2. The weighing of different resource constraints against each other is
a task for this work, see 3. below.

>CoAP provides a DTLS binding for
>deployment experience.

3. Here I¹m missing the step that we need to agree on and specify design
constraints when profiling existing protocols or designing new. There are
trade-offs to make e.g. in terms of either doing crypto on a constrained
device or instead communicating with supporting less-constrained device.

>Moreover, a standardized solution for federated

4. This has been discussed before, e.g.
http://www.ietf.org/mail-archive/web/ace/current/msg00104.html

- The term ³authenticated authorization² is not defined or referenced.

- It sounds like it excludes things like Bearer Tokens (which may be OK,
but that has not been discussed at all).

- I¹m fine with including this particular optimisation of DTLS handshake,
but would like to get acknowledged that other work on optimisations of
DTLS handshake in this context is also in scope, such as trusted third
party assisted key management (e.g. draft-seitz-core-security-modes). Any
work in this space is of course is conditional on what design constraints
are relevant for this work.

>power consumption etc.) and their suitability for the use cases.

5. Referring to 3. above, it is in this context I see the need to specify
design constraints, to be able to make a comparison and to decide what to
standardise.

Göran

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 23 Jan 2014 07:10:28 -0500

Hi Stefanie/Likepeng,

I didn't see the answer to my question, so I am just resending it.

Thanks,

Akbar

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Wednesday, January 22, 2014 11:34 AM
To: Stefanie Gerdes
Cc: [email-masked]
Subject: Re: [Ace] New Version of Proposed Charter

Hi Stefanie,

 (Reference:

Best Regards,

Akbar

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Stefanie Gerdes
Sent: Monday, January 20, 2014 10:49 AM
To: [email-masked]
Subject: [Ace] New Version of Proposed Charter

Hi everybody,

Best regards,
Kepeng and Steffi

---

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

> http://tools.ietf.org/html/draft-ietf-core-coap-18#section-11.2 )

The current discussions did not address this issue, and I think that
this will not be a hot topic in the starting phase of a to-be-WG.

But I agree that this kind of authorization transfer should be taken
into consideration for solution design in the current drafts. Do you
have a description of a usage scenario that could be incorporated with
the use cases draft?

Gruesse
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 23 Jan 2014 13:36:22 +0100

> have a description of a usage scenario that could be incorporated with

Proxies are already mentioned in the use cases draft (section 2.5.1 and 
requirement U5.3). Rahman, do you think that should be more specific?
If so I'm happy to hear your suggestions.

/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: Likepeng <[email-masked]>
Date: Fri, 24 Jan 2014 09:27:37 +0000

> I think the issues around authorisation lifetime or revocation deserves should also be listed in the tasks below

Currently we have this task in the list:
•Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication.

Do you have any proposal to merge the lifetime/revocation into the sentence above? 

Or have another general task? If we have a separate bullet just for lifetime/revocation, that may be too emphasized.

Thanks,

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 G?ran Selander
> 发送时间: 2014年1月23日 19:23
> 收件人: [email-masked]
> 主题: Re: [Ace] New Version of Proposed Charter
> 
> 
> I think the charter in its current version is setting the stage very well and
> provides a good motivation for the work needed. Some further comments
> >Due to several complaints about the readability of the proposed
> >charter, we revised it and, with the assistance of Hannes, came up with
> >a new proposal which provides some more motivation and background to our
> work.
> >
> 1. Yes this is good, and I think the issues around authorisation lifetime or
> revocation deserves should also be listed in the tasks below
> 
> >These types of questions have been answered by existing protocols for
> >use cases outside the constrained environment. But in constrained
> >environment, constrained devices cannot readily handle these issues due
> >to resource constraints.
> 
> 2. The weighing of different resource constraints against each other is a task
> for this work, see 3. below.
> 
> >the same goal they offer quite different functions and utilize
> >different message exchanges. These differences are motivated by the
> >main deployment use cases they were designed for.
> >
> >into account are the lack of a suitable user-interface for obtaining
> >the consent of the user and the inability of embedded devices to
> >contact an identity management/authorization server in real-time with
> >every access request.
> >
> trade-offs to make e.g. in terms of either doing crypto on a constrained device
> or instead communicating with supporting less-constrained device.
> 
> >Moreover, a standardized solution for federated authentication and
> >authorization will help to stimulate the deployment of IoT devices
> >offering increased security.
> >
> >environment space. This work does not make the assumption that the
> >party offering application layer services is always the same party
> >offering network access services.
> >
> - It sounds like it excludes things like Bearer Tokens (which may be OK, but that
> has not been discussed at all).
> 
> - I¹m fine with including this particular optimisation of DTLS handshake, but
> would like to get acknowledged that other work on optimisations of DTLS
> handshake in this context is also in scope, such as trusted third party assisted
> key management (e.g. draft-seitz-core-security-modes). Any work in this space
> is of course is conditional on what design constraints are relevant for this
> work.
> 
> 
> >
> 5. Referring to 3. above, it is in this context I see the need to specify design
> constraints, to be able to make a comparison and to decide what to
> standardise.
> 
> 
> Göran
> 
> >
> >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.
> >

---

From: Göran Selander <[email-masked]>
Date: Fri, 24 Jan 2014 11:03:16 +0000

On 24/01/14 10:27, "Likepeng" <[email-masked]> wrote:

>€Define a mechanism for authenticated and protected transfer of
>Or have another general task? If we have a separate bullet just for
>lifetime/revocation, that may be too emphasized.

How about:

Define a mechanism for authenticated and protected transfer of
authorization information suitable for constrained environments, and
taking into account expiry/revocation.

Too short?

Göran

---

From: "鹏程万里" <[email-masked]>
Date: Fri, 24 Jan 2014 22:25:26 +0800

>taking into account expiry/revocation.

Personally I am fine with that. Let's see if others have any opinion.

BTW: I am at home, and I use another email address.

Kepeng

------------------ Original ------------------
From:  "Göran Selander";<[email-masked]>;
Date:  Fri, Jan 24, 2014 07:03 PM
To:  "Likepeng"<[email-masked]>; "[email-masked]"<[email-masked]>; 

How about:

Too short?

Göran

.

---

From: Likepeng <[email-masked]>
Date: Mon, 27 Jan 2014 09:31:28 +0000

> constraints, to be able to make a comparison and to decide what to

According to the previous discussion, it seems that you propose to change this bullet to:

Document design criteria for the required security protocols with respect to resource usage (RAM, message round trips, power consumption etc.).

Personally I am fine with either way. 

Let's see other's opinion.

Thanks,

Kind Regards
Kepeng

---

From: Göran Selander <[email-masked]>
Date: Mon, 27 Jan 2014 10:18:08 +0000

Hi Kepeng

On 27/01/14 10:31, "Likepeng" <[email-masked]> wrote:

>Document design criteria for the required security protocols with respect
>to resource usage (RAM, message round trips, power consumption etc.).

Yes, that is a good summary.

Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 27 Jan 2014 15:35:36 +0100

Hi Göran,

> Yes, that is a good summary.

The task about the applicability of main authentication and key exchange
protocols was added to the list of tasks because we need to make sure
that we don't reinvent the wheel (open issue 3).

I am not quite sure what you are aiming at with documenting the design
criteria. I can't really picture what a practical work item would be for
that task. Can you explain that in more detail?

Best regards,
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 27 Jan 2014 16:49:38 +0100

Hi Göran,

> - The term ³authenticated authorization² is not defined or referenced.

I am not really sure if we need a definition for that. As I stated
before (http://www.ietf.org/mail-archive/web/ace/current/msg00084.html),
authenticated authorization means that you know who issued the
authorization. That is pretty straight-forward, I think. And I think it
is really important to point out that we want to be able to do this.

Maybe the problem is a misunderstanding about the terms. In
http://www.ietf.org/mail-archive/web/ace/current/msg00104.html you are
citing http://www.ietf.org/mail-archive/web/core/current/msg05132.html
which stated that authorization doesn't require authentication because
you don't in all cases need an identity. Authentication is not
necessarily about verifying an identity, though (I stated that later in
the thread, too:
http://www.ietf.org/mail-archive/web/core/current/msg05136.html). It
means that it is possible to verify a certain attribute of a subject,
e.g. if it has a certain key. In the case of authorization we want to
make sure that the authorization is in the resource owner's interest and
we have to make sure that we can verify that.

Best regards,
Steffi

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 28 Jan 2014 00:46:45 +0000

Hi Steffi, Göran,

I agree about the need for "authenticated authorisation", with authentication in the sense that it should be possible to bind authorisation securely to the authorised party. This could be done by e.g. a signature or a secret only known by to parties involved in this particular authorisation process.

For example, if the authorisation server can authenticate the client, then it can provide the client with a secret known to itself and the resource server. In this way, the resource server can verify that the client was authenticated by the authorisation server. Another solution would be a signature/mac from the authorisation server over the public key of the client in the authorisation information.

Perhaps the technical details should be part of a later discussion, but for now I just want to indicate my interpretation of "authorised authentication".

Best regards,
Bert

> Sent: 27 January 2014 23:50
> To: Göran Selander; [email-masked]

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 28 Jan 2014 09:06:42 +0100

Hi,

I agree completely with Bert's interpretation of the term -- possibly
with the addition that it should be mutual (i.e. not only the resource
server relies on the client to be authenticated by the authorization
server but also the client can be sure that the authorization only works
with the right resource server).

To me, the term "authenticated authorization" seems pretty intuitive as
others already said. I do not see the need for explicitly defining it in
the charter text.

Best regards
Olaf

Bert Greevenbosch <[email-masked]> writes:

> Hi Steffi, Göran,
>
> I agree about the need for "authenticated authorisation", with
> authentication in the sense that it should be possible to bind
> authorisation securely to the authorised party. This could be done by
> e.g. a signature or a secret only known by to parties involved in this
> particular authorisation process.
>
> For example, if the authorisation server can authenticate the client,
> then it can provide the client with a secret known to itself and the
> resource server. In this way, the resource server can verify that the
> client was authenticated by the authorisation server. Another solution
> would be a signature/mac from the authorisation server over the public
> key of the client in the authorisation information.
>
> Perhaps the technical details should be part of a later discussion,
> but for now I just want to indicate my interpretation of "authorised
> authentication".
>
> Best regards,
> Bert

---

From: Göran Selander <[email-masked]>
Date: Tue, 28 Jan 2014 08:54:19 +0000

Hi Steffi, Bert, Olaf,

If I understand right it seems to me that just in is short mail thread
there are three different interpretations of this term. Let me try to
reformulate your definitions in my own words, please correct me if I¹m
wrong:

1. Authentication of authorisation server (and/or verification of
integrity of token) by the resource server (Steffi)

"authenticated authorization means that you know who issued the
authorization."

'the term "authenticated authorization" means that
you know where the authorization came from.'

2. Authentication of authorised client (and/or key confirmation) by the
resource server (Bert)

"it should be possible to bind
authorisation securely to the authorised party"

"For example, if the authorisation server can authenticate the client,
then it can provide the client with a secret known to itself and the
resource server. In this way, the resource server can verify that the
client was authenticated by the authorisation server."

3. Mutual authentication of (and/or key confirmation by) authorised client
and authorised resource server (Olaf)

"it should be mutual (i.e. not only the resource
server relies on the client to be authenticated by the authorization
server but also the client can be sure that the authorization only works
with the right resource server)"

Maybe I¹ve misunderstood something, but if not - aren¹t these differences
slightly to big to say that this term is well defined?

Now, does it have to be well defined? The current charter includes the
following task:

	"Define profiles for certificates used for authenticated authorisation"

With the range of definitions above I can read in several interpretations
of this task, for example:

1. Define profiles of authorisation server certificates used for
authenticating the authorisation server by the resource server

2. Define profiles of client certificates used for authenticating the
authorised client to the resource server

3. Define profiles of client and server certificates for mutually
authenticating authorised client and authorised resource server.

Maybe this is the devil reading the bible. But I find it slightly
disturbing that I don¹t really understand what is proposed. And I¹d rather
discuss content than terminology :-)

Göran

---

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

Hi Steffi

On 27/01/14 15:35, "Stefanie Gerdes" <[email-masked]> wrote:

>>> According to the previous discussion, it seems that you propose to
>>>change
>>> this bullet to:
>>>

I¹ll try :-)

I did not want to put ³document design criteria" against ³document
applicability². In fact I think they are complementing each other: How do
you determine ³applicability²?  For this you need an understanding and/or
make certain assumptions of the various Œcosts' in constrained devices
associated to certain security protocol constructions. The intention with
³document design criteria² is to describe some of these aspects. In this
sense, deciding on relevant ³design criteria² is a pre-requisite to
determine ³applicability².

The former may also be useful in comparing different constructions. As a
concrete example, let¹s say that in one protocol you have reduced crypto
in constrained device to a bare minimum, and in another protocol you
instead reduce the number of round trips at the cost of performing a large
amount of symmetric key crypto. Which protocol is preferred from the point
of view of e.g. energy consumption in a wireless device?

In some cases this may be easy to state, in other cases this may depend on
certain conditions and you need to make assumptions. Another objective of
this task could be to document such assumptions. The practical work would
be to put together this kind of information regarding "costs² in an
informational document to be used as rationale when profiling an existing
protocol or designing a new. I imagine this not so much new results as a
compilation of knowledge in CoRE, LWIG, etc. set in the context of
security protocols.

Does that make more sense?

Göran

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 28 Jan 2014 11:05:23 +0100

Göran,

> reformulate your definitions in my own words, please correct me if I¹m

This is not my understanding. I think that these three just highlight
different aspects of the same thing (that is why I have explicitly said
that I agree with Bert's statement and tried to add the missing point
that came up in several discussions in Vancouver).

> you know where the authorization came from.'

And these two statements fit into what Bert said. I do not get why this
should be different -- to me, it sounds just like another technical
detail of the same thing.

Gruesse
Olaf

---

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 29 Jan 2014 00:57:37 +0000

Hi Göran, Olaf, Steffi,

Indeed authorisation needs some credibility, and as such authorisation is granted by the trusted authorisation server, there should be some proof of this. I don't think this means you need to authenticate the authorisation server each time you receive an authorisation proof for a resource server / client, you just need to verify that the authorisation was issued by a trusted authorisation server.

Having said that, I wonder whether the possible broad interpretation of the sentence

is really that troublesome. The sentence does however assume a certificate based solution. That may be too early, as I could also imagine solutions with some pre-shared secrets between AS and Resource Server/Client, and everything built on that.

B.T.W., I'll be celebrating coming of the year of the horse starting tomorrow, so please forgive the delay of my future response(s). :-)

Best regards,
Bert

> From: Göran Selander [mailto:[email-masked]]
> Sent: 28 January 2014 16:54
> To: Olaf Bergmann; Bert Greevenbosch
> Cc: Stefanie Gerdes; [email-masked]

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 29 Jan 2014 11:32:46 +0100

Hi Bert,

> is really that troublesome. The sentence does however assume a certificate based solution. That may be too early, as I could also imagine solutions with some pre-shared secrets between AS and Resou…

Yes, I think we should consider both symmetric and asymmetric solutions.
There was some discussion about this in Vancouver but we didn't come to
an agreement. We favor a symmetric solution in DCAF but other people
seem to assume that asymmetric crypto is better suited.

Best regards,
Steffi

---

From: Paul Lambert <[email-masked]>
Date: Wed, 29 Jan 2014 08:20:06 -0800

On Jan 29, 2014, at 2:32 AM, Stefanie Gerdes <[email-masked]> wrote:

>> "Define profiles for certificates used for authenticated authorization"

Certificates are unnecessary in constrained devices.  Simple public key authentication/establishment with ECDH or authentication with ECDSA do not need third party certificates.

> Yes, I think we should consider both symmetric and asymmetric solutions.

Symmetric solutions do not scale.  

> seem to assume that asymmetric crypto is better suited.

Ubiquitous P2P authentication is not possible with symmetric keys alone.

Paul

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 29 Jan 2014 17:21:59 +0100

> Symmetric solutions do not scale.  

Why do you think that?

Gruesse
Olaf

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jan 2014 19:37:06 +0100

> Symmetric solutions do not scale.  

That depends on what kind of scalability you are after.
For instance, they scale down really nicely.

> Ubiquitous P2P authentication is not possible with symmetric keys alone.

Can you provide more details about your definition of "Ubiquitous P2P authentication”, and what you think the important objectives are here?
(Interestingly, there are zero google hits for this combination of words.)

Grüße, Carsten

---

From: Paul Lambert <[email-masked]>
Date: Wed, 29 Jan 2014 08:45:11 -0800

>> Symmetric solutions do not scale.  
Humm .. not quite accurate without qualification.
Symmetric solutions do not scale easily in a distributed environment is a more accurate statement.

> Why do you think that?

Clearly we have a cellular system based on authentication with secrets that obviously scales.  We have web based password authentication that obviously scales.  However, these always include central servers from some provider of some variety that maintains the secret keys (often password based). 

Secure introduction in this context (one device to another) assumes some common secret based intermediary.  Secret based architectures tend to assume an always-on Internet connection to get to secret based authentication servers.  Local symmetric key authentication is possible with simple shared keys … (e.g. today’s WPA2-Personal for APs).  This appears useful or small groups and home applications - but adds the complexity of password based enrollment.  Alternatives to password based enrollment (WPS2, WPS3, etc) start to use public key exchanges to improve the user experience.  Simply starting with asymmetric based identities in devices would greatly simplify the architecture allowing better distributed/P2P interactions that are not dependant  on server or services.

So I still hold to the original statement ->  "Symmetric solutions do not scale.” ….  but. ‘scale’ needs to be viewed in the context of my view of the use cases.  My requirements/use cases are for ubiquitous P2P authentication/authorization. No authentication servers can be involved.  My thermostat should not have to talk to a CA or remote authentication server to read a new temperature sensor. 

Paul

---

From: Paul Lambert <[email-masked]>
Date: Fri, 31 Jan 2014 21:06:37 -0800

Secure introduction in this context (one device to another) assumes some common secret based intermediary.  Secret based architectur tends to assume an always-on Internet connection to get to secret based authentication servers.  

Management of ‘secrets’ is always

---

From: Göran Selander <[email-masked]>
Date: Sat, 1 Feb 2014 07:22:45 +0000

Hi Paul

On 29/01/14 17:45, "Paul Lambert" <[email-masked]> wrote:

> My requirements/use cases are for ubiquitous P2P
>authentication/authorization. No authentication servers can be involved.
>My thermostat should not have to talk to a CA or remote authentication
>server to read a new temperature sensor.

I¹m interested in your use cases.

- I assume only certain thermostats should have access to read the
temperature sensor. Do you see any benefit in being able to later modify
the access rights for who is able to request anything from the temperature
sensor? (Do you ever want to do anything with the sensor expect ask having
the same thermostats asking for temperature readings?)

- Does your deployment phase allow the involvement of third node
³establishing the ACL"?

The scope of ACE is on a generic procedure for addressing access control
in a potentially dynamic situation including e.g. changing of access
rights, new clients of existing servers, authorisation of the action to
change access rights, etc

I believe it could potentially also include ³provisioning of ACL², i.e. a
procedure that can be deployed just once to define a static operational
setting, in which case you don't need any subsequent involvement of a
third node.

Public keys can of course be very useful in a deployment setting but that
doesn¹t exclude the use of symmetric keys during an operational phase.

Göran