Subject: Re: [Ace] Relationship and difference with DICE

From: Ludwig Seitz <[email-masked]>
Date: Tue, 07 Jan 2014 10:47:24 +0100

On 12/25/2013 07:53 AM, Likepeng wrote:
> Hello all,
>
> I received offline question about how this work (ACE) relates to DICE,
> and how it's different.
>
> My answer is the following:
>
> DICE (DTLS In Constrained Environments) WG aims to define a DTLS profile
> that is suitable for constrained environment, and define how DTLS record
> layer can be used to transmit multicast messages securely. The objective
> is to secure message exchanges at the transport layer, and it does not
> address the authenticated authorization issue. ACE aims to enable
> authenticated communication between constrained devices, and enable
> authorization verification to access specific resources. ACE will employ
> security properties of DTLS whenever possible.
>
> Does this address the question?
>
>

Not quite, or rather it raises a new question for me:

What do you mean with "the authenticated authorization issue"?

Regards,

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: Carsten Bormann <[email-masked]>
Date: Tue, 7 Jan 2014 12:42:12 +0100

> What do you mean with "the authenticated authorization issue”?

I’m not Kepeng, but I read

> it does not
> address the authenticated authorization issue.

as

> it does not
> address authenticated authorization beyond the authentication functions that DTLS already provides.

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 07 Jan 2014 13:41:26 +0100

On 01/07/2014 12:42 PM, Carsten Bormann wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

Thank you Carsten, I was trying to be short in detriment of clarity.

The part on "beyond the authentication functions that DTLS already 
provides" seems obvious (even to me ;-) ).

However "authenticated authorization" is a somewhat odd term that can be 
interpreted in various ways (and that is not common among IAM and access 
control practitioners). So if we claim that ACE is going to address 
this, we should define what it means (or rephrase it in terms that are 
commonly understood by the relevant community).

/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: Stefanie Gerdes <[email-masked]>
Date: Tue, 07 Jan 2014 19:03:27 +0100

> commonly understood by the relevant community).

My understanding of the term is that the issuer of the authorization
needs to be identifyable. An authorization is worthless without knowing
who issued it (and if this entity is allowed to issue this
authorization). Thus, the term "authenticated authorization" means that
you know where the authorization came from.

Beside authenticated authorization, it must also be clear for which
entity the authorization is issued and who therefore is authorized to do
something. If you want to give access permissions to an entity you have
to be able to identify it first. And you have to be able to somehow map
the authorization to the identified entity. This is a different problem,
though.

Maybe it helps if we rephrase this part to "The objective is to secure
message exchanges at the transport layer, and it does not address
authorization. ACE aims to enable authenticated authorization to access
specific resources and thus enables constrained devices to verify the
valdity of a given authorization. ACE will employ security properties of
DTLS whenever possible."

What do you think?

Best regards,
Steffi

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jan 2014 14:56:02 -0500

> you know where the authorization came from.

Well, I agree with everything you say, but it seems to obvious that I've
never heard anyone say it.

From rfc2692:
   The SPKI team directly addressed the issue of <name,key> bindings and
   realized that such certificates are of extremely limited use for
   trust management.  A keyholder's name is one attribute of the
   keyholder, but as can be seen in the list of needs in this document,
   a person's name is rarely of security interest.  A user of a
   certificate needs to know whether a given keyholder has been granted
   some specific authorization.

One of the key things that came out of SPKI was that the zeroth step
is that verifiers trust authorizers. In the browser model, this is done by
populating PKIX "root" keys into the browser trusted store.

I am not interesting in naming motes. I just want to authorize them.
So we will be writing authorization statements about raw public keys.

Reading rfc2692/rfc2693 would be a good idea.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 08 Jan 2014 15:02:37 +0100

> So we will be writing authorization statements about raw public keys.

Assuming the motes are powerful enough to handle public key crypto I 
fully agree with you, but is that always so?
I'm guessing here, but wouldn't it be reasonable to assume a class of 
devices that can handle symmetric key crypto, but not public key crypto?

/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: Carsten Bormann <[email-masked]>
Date: Wed, 8 Jan 2014 15:19:24 +0100

>> So we will be writing authorization statements about raw public keys.

Indeed. one important takeaway from the Paris workshop was that the traditional concepts of identity may be taking more of a back seat in the Internet of Things.

> Assuming the motes are powerful enough to handle public key crypto I fully agree with you, but is that always so?

We could decide to limit ourselves to only systems that can do asymmetric crypto, but I think this is not necessary, and we would shut out the lower end of constrained devices.

So I’d say that I’d prefer to extend what Michael said to the exchange of authorization statements that involve keying material (both about raw public keys and authenticated by symmetric keys).

Grüße, Carsten

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Wed, 8 Jan 2014 14:35:05 +0000

Ludwig,

>devices that can handle symmetric key crypto, but not public key crypto?

yes, it seems totally sensible to me to design for scenarios where
authorisation assertions are done using symmetric crypto.

E.g. allowing a tiny mote to securely delegate the handling of its
resources to an always-on endpoint of choice (perhaps when it needs to
sleep to save power) should be feasible without:
a) draining all of its battery to compute/verify a signature, and
b) cramming its ROM with BIGNUM handling code.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jan 2014 16:59:02 -0500

> fully agree with you, but is that always so?  I'm guessing here, but
    > wouldn't it be reasonable to assume a class of devices that can handle
    > symmetric key crypto, but not public key crypto?

First, I have no interest in motes performing more than 1-2 public key
operations in their *lifetime*.  They should come up enough to identify
themselves and create one or two TLS sessions (such as EAP-TLS sessions over PANA
for layer-2, ZigbeeIP-style).  Then a bunch of TLS resumption blogs (see
rfc5077).
All subsequent operations would use that.  The thing is, the ACLs would still
get written for public keys, it is just that we always make sure to provision
shortcuts to those keys.

My opinion is that motes that can not do even 1 public key operation probably
can not run DTLS.

Second, if we truly want to do symmetric key stuff (including the very first
kinit), then we need to avoid re-inventing kerberos.

---

From: Likepeng <[email-masked]>
Date: Thu, 9 Jan 2014 02:49:01 +0000

>Maybe it helps if we rephrase this part to "The objective is to secure message exchanges at the transport layer, and it does not address authorization. ACE aims to enable authenticated authorization to access specific resources and thus enables constrained devices to verify the validity of a given authorization. ACE will employ security properties of DTLS whenever possible."

+1. 

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Stefanie Gerdes
发送时间: 2014年1月8日 2:03
收件人: [email-masked]
主题: Re: [Ace] Relationship and difference with DICE

On 01/07/2014 01:41 PM, Ludwig Seitz wrote:
> However "authenticated authorization" is a somewhat odd term that can 
> be interpreted in various ways (and that is not common among IAM and 
> access control practitioners). So if we claim that ACE is going to 
> address this, we should define what it means (or rephrase it in terms 
> that are commonly understood by the relevant community).

My understanding of the term is that the issuer of the authorization needs to be identifyable. An authorization is worthless without knowing who issued it (and if this entity is allowed to issue this authorization). Thus, the term "authenticated authorization" means that you know where the authorization came from.

Beside authenticated authorization, it must also be clear for which entity the authorization is issued and who therefore is authorized to do something. If you want to give access permissions to an entity you have to be able to identify it first. And you have to be able to somehow map the authorization to the identified entity. This is a different problem, though.

Maybe it helps if we rephrase this part to "The objective is to secure message exchanges at the transport layer, and it does not address authorization. ACE aims to enable authenticated authorization to access specific resources and thus enables constrained devices to verify the valdity of a given authorization. ACE will employ security properties of DTLS whenever possible."

What do you think?

Best regards,
Steffi

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 9 Jan 2014 12:28:33 +0100 (CET)

Hi Kepeng,

the relationship between DICE and ACE is quite simple when we look at the way how TLS/DTLS is designed. TLS/DTLS does not provide authorization within the protocol itself. Instead it outsources this function to the application layer. As an example, if you look at RFC 2818 http://www.rfc-editor.org/rfc/rfc2818.txt or better at http://tools.ietf.org/html/rfc6125 then you will see that different application layer protocols performed the authorization check differently.

RFC 2818 ("HTTP over TLS") says:

If the hostname does not match the identity in the certificate, user
oriented clients MUST either notify the user (clients MAY give the
user the opportunity to continue with the connection in any case) or
terminate the connection with a bad certificate error.

The document describes how the match between the certificate and the URL looks like. RFC 6125 goes into more details about how to perform this match.

This is the authorization check executed by the client. The authorization of the client (by the server) is not described in RFC 2818 and it is much more complex. Luckily, the ACE group does not need to specify the authorization check executed by the client since it is already defined in CoAP draft. Here is the relevant text:

When a new connection is formed, the certificate from the remote
device needs to be verified. [....snip...] If the

certificate contains a SubjectAltName, then the Authority Name MUST
match at least one of the authority names of any CoAP URI found in a
field of URI type in the SubjectAltName set. If there is no
SubjectAltName in the certificate, then the Authoritative Name MUST
match the CN found in the certificate using the matching rules
defined in [RFC2818] with the exception that certificates with
wildcards are not allowed.

Of course, the work in ACE shouldn't only be applicable to CoAP but when you use HTTPS with a constrained device then RFC 2818 would kick in.

The focus of ACE is therefore on the authorization of the client by the server. The server hosts the resource and so the access to the resource must be protected against unauthorized access. This does not necessarily require the client to be authenticated to the server if you make use of a trusted third party that mediates the exchange, as we see with a number of protocol designs. Having read the input drafts for ACE I see this observation being confirmed. There are obviously various possible solution designs. For example, one can imagine to convey additional information in the DTLS exchange itself but it could also mean to carry information at the application layer. This is largely a design decision a yet-to-be-formed working group has to decide and I wouldn't write that into the charter text itself. I would go as far as saying that ACE might be independent of DTLS; it might use DTLS as a building block (depending on the design of the solution).

When folks work in DICE to create a profile of DTLS for use by constrained devices it makes sense to stick with the current model of DTLS. As such, the authorization is not part of the actual DTLS protocol itself.

I hope my description makes some sense.

Ciao

Hannes

PS: Btw, I would keep the main description of the ACE group as simple as "ACE aims to enable authorized access to resources by constrained devices.".

Gesendet: Donnerstag, 09. Januar 2014 um 02:49 Uhr

Von: Likepeng <[email-masked]>

An: "Stefanie Gerdes" <[email-masked]>, "[email-masked]" <[email-masked]>

Betreff: Re: [Ace] Relationship and difference with DICE

+1.

Kind Regards

Kepeng

-----邮件原件-----

发送时间: 2014年1月8日 2:03

收件人: [email-masked]

>>> address authenticated authorization beyond the authentication

>>> functions that DTLS already provides.

What do you think?

Best regards,

Steffi

Ace mailing list

[email-masked]

Ace mailing list

[email-masked]

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 09 Jan 2014 13:19:24 +0100

Hannes,

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

>  
> This is the authorization check executed by the client. The
> authorization of the client (by the server) is not described in RFC
> 2818 and it is much more complex. Luckily, the ACE group does not need
> to specify the authorization check executed by the client since it is
> already defined in CoAP draft. Here is the relevant text: 

[...]

You are citing section 9.1.3.3 of the draft coap-18 which is about
Certificate mode. I presume that ACE will address RawPublicKey mode and
PreSharedKey mode as well. Thus, there is obvously a need to define the
authorization check executed by the client.

> Of course, the work in ACE shouldn't only be applicable to CoAP but
> when you use HTTPS with a constrained device then RFC 2818 would kick
> in.

My understanding was that ACE targets at authorization for the
constrained device space. It uses CoAP as its transfer protocol but
needs to define interworking with other mechanisms (e.g. OAuth).

> The focus of ACE is therefore on the authorization of the client by
> the server. The server hosts the resource and so the access to the
> resource must be protected against unauthorized access. This does not
> necessarily require the client to be authenticated to the server if
> you make use of a trusted third party that mediates the exchange, as
> we see with a number of protocol designs. Having read the input drafts
> for ACE I see this observation being confirmed. There are obviously
> various possible solution designs. For example, one can imagine to
> convey additional information in the DTLS exchange itself but it could
> also mean to carry information at the application layer. This is
> largely a design decision a yet-to-be-formed working group has to
> decide and I wouldn't write that into the charter text itself. I would
> go as far as saying that ACE might be independent of DTLS; it might
> use DTLS as a building block (depending on the design of the
> solution). 

I think, your understanding is correct, with the exception that
authorization of the server to the client also should be addressed.

> PS: Btw, I would keep the main description of the ACE group as simple
> as "ACE aims to enable authorized access to resources by constrained
> devices.". 

+1

Gruesse
Olaf

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Thu, 9 Jan 2014 12:38:24 +0000

On 09/01/2014 11:28, "Hannes Tschofenig" <[email-masked]> wrote:
>This is the authorization check executed by the client. The authorization
>of the client (by the server) is not described in RFC 2818 and it is much
>more complex. Luckily,
> the ACE group does not need to specify the authorization check executed
>by the client since it is already defined in CoAP draft. Here is the
>relevant text: 
> 
>   defined in [RFC2818 <http://tools.ietf.org/html/rfc2818>] with the
>exception that certificates with

BTW this still needs some more tweaking to work in non-DNS environments
(see http://tools.ietf.org/wg/core/trac/ticket/255).

> authorization check executed by the client.

+1 — We need more work (in CoRE I suppose) to cover this area.

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 09 Jan 2014 13:51:44 +0100

On 01/09/2014 12:28 PM, Hannes Tschofenig wrote:
>
> PS: Btw, I would keep the main description of the ACE group as simple as
> "ACE aims to enable authorized access to resources by constrained
> devices.".

+1

/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: Göran Selander <[email-masked]>
Date: Thu, 9 Jan 2014 13:00:53 +0000

I would say "ACE aims to enable authorized access to resources on constrained
devices." The accessing device may be constrained or not.

Göran

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 9 Jan 2014 14:17:35 +0100 (CET)

Hi Olaf,

remarks inline:

Gesendet: Donnerstag, 09. Januar 2014 um 12:19 Uhr

Von: "Olaf Bergmann" <[email-masked]>

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

Cc: [email-masked]

Hannes,

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

[...]

[hannes] That's a good point. I think that this also has to be mentioned in the charter that different types of credentials have to be supported, namely shared secrets, raw public keys, and certificates, since it will impact the design of the protocol.

Kerberos, for example, does not offer that level of flexiblity.

[hannes] This is an interesting scope question. Of course, you have various protocol interactions here, such as the client<->trusted third party as well as the client<->server. I could imagine that one would want to use CoAP on the former but would you mandate CoAP on the latter as well.

Just to give you an example what I mean: In OAuth the client<->authorization server exchange uses HTTPS. There is a specification for an HTTPS-based exchange from the client<->resource server (the OAuth Bearer Token) but we have also worked on a mapping to SASL. As such, there is nothing in OAuth that prevents you from exchanging the access token also on other protocols. It would be nice to keep that flexiblity even though the first and main use case is for CoAP. What do you think?

[hannes] I would say that this is already in the CoAP spec. Would you have to say more than that?

+1

Gruesse

Olaf

Ciao

Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 9 Jan 2014 14:21:05 +0100 (CET)

Hi Thomas,

Yes, the section would benefit from a bit more clarity in general. I noticed that it is hard to follow whether we are actually talking about the client or the server in various paragraphs since both sides can have certificates (or other credentials).

I leave that to the core working group.

As a side remark: It would be interesting to find out how likely the use of DNS is going to be since it raises the question about DNSSEC and how it interacts with various other IoT specified security mechanisms.

Ciao

Hannes

---

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

You are certainly right that there are potential cases where the client asking for resources has no constraints.

But equally likely it is that the device running the resource is not constrained but the client is.

In the worst case both devices are constrained.

From a protocol design point of view that's obviously a tricky situation. You can assume the worst case scenario or alternatively focus on specific scenarios only.

That's where the requirements document would show some real value.

I wonder what the views of others in the group are.

At least I hope we do not assume that the trusted third party / authorization server is a constrained device....

Cio

Hannes

Gesendet: Donnerstag, 09. Januar 2014 um 13:00 Uhr

Von: "Göran Selander" <[email-masked]>

An: "Hannes Tschofenig" <[email-masked]>, "[email-masked]" <[email-masked]>

devices.".

Göran

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

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 09 Jan 2014 14:46:55 +0100

On 01/09/2014 02:27 PM, Hannes Tschofenig wrote:
>  From a protocol design point of view that's obviously a tricky
> situation. You can assume the worst case scenario or alternatively focus
> on specific scenarios only.

In the use-case draft we assume that the server is constrained, and that 
the client could be constrained (i.e. your worst case).

I think we never had detailed considerations on the case where only the 
client is constrained, although Stefanie Gerdes had it listed on a slide 
at IETF 88. My hunch is that case is much easier than the reverse one.

> At least I hope we do not assume that the trusted third party /
> authorization server is a constrained device....

Nope, because then we would have to introduce a trusted fourth party ...

/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: Olaf Bergmann <[email-masked]>
Date: Thu, 09 Jan 2014 15:19:47 +0100

Hi Hannes,

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

> [hannes] This is an interesting scope question. Of course, you have
> various protocol interactions here, such as the client<->trusted third
> party as well as the client<->server. I could imagine that one would
> want to use CoAP on the former but would you mandate CoAP on the
> latter as well. 

The folks who were discussing the authorization topic during IETF-87 and
88 (including me) have started with the assumption that client<->server
is CoAP while client<->trusted third party could be CoAP or something
else (in draft-gerdes-core-dcaf, we have split this latter communication
up into two parts where the first is most likely CoAP when the client is
a constrained device, while the other could be something else,
e.g. HTTPS).

> Just to give you an example what I mean: In OAuth the
> client<->authorization server exchange uses HTTPS. There is a
> specification for an HTTPS-based exchange from the client<->resource
> server (the OAuth Bearer Token) but we have also worked on a mapping
> to SASL. As such, there is nothing in OAuth that prevents you from
> exchanging the access token also on other protocols. It would be nice
> to keep that flexiblity even though the first and main use case is for
> CoAP. What do you think? 

That's the reaason why draft-gerdes-core-dcaf use an architecture that
allows for the not-constrained parties to use e.g. OAuth while the
constrained devices need to handle nothing but some sort of bearer token
(the draft talks about tickets as an analogy to real life where tickets
are used e.g. as a proof that the holder is authorized to walk into a
concert, while the doormen can check the ticket's authenticity by some
hard-to-fake information printed on that ticket).

Gruesse
Olaf