Subject: [Ace] Access Control Lists in CoAP

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Dec 2013 19:32:18 +0100 (CET)

Hi all,

in a couple of drafts I see these pointers to access control lists being described in CoAP. However, the CoAP specification does not really say that much about access control lists and by no means describes how they are supposed to be used in any level of detail.

I am curious what folks on the list think they do.

Ciao

Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Dec 2013 00:03:03 +0100

> in a couple of drafts I see these pointers to access control lists being described in CoAP. However, the CoAP specification does not really say that much about access control lists and by no means…

The CoAP base protocol (draft-ietf-core-coap) does not define ACLs.
It just says you need to have some, because the authentication that we get with DTLS is not the complete answer to the security requirements.

The current ACE charter proposal says ACE should define the ACLs for CoAP.
(My slide 105 from the CoRE WG at IETF88 says CoRE should define the ACLs for CoAP.
Let’s decide which WG does what *after* deciding what needs to be done.)

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 13 Dec 2013 09:22:53 +0100

> Let’s decide which WG does what *after* deciding what needs to be done.)
+1

-- 
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: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 13 Dec 2013 16:31:10 +0100 (CET)

Hi Carsten,

you are bypassing my question.

I am reading through the list of drafts that Kepeng had distributed.

For example, when I look at draft-seitz-core-sec-usecases-00.txt I read:

"

Currently CoAP proposes to use DTLS

[RFC6347] for authentication, and access control lists on the

devices, that specify which clients may initiate a DTLS connection.

One goal of this document is to point out use cases where this

approach is not satisfactory.

"

I have not closely followed all the CORE work but there seems to be a view of what CoAP does.

When I look at CoAP I don't see this discussion about access control lists.

So, I want to hear what folks think it does.

Alternatively, you could just write:

"CoAP does not specify how access control is accomplished and therefore this work introduces these mechanisms."

Ciao

Hannes

Gesendet: Donnerstag, 12. Dezember 2013 um 23:03 Uhr

Von: "Carsten Bormann" <[email-masked]>

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

Cc: [email-masked]

Betreff: Re: [Ace] Access Control Lists in CoAP

Grüße, Carsten

_______________________________________________

Ace mailing list

[email-masked]

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

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 13 Dec 2013 16:51:45 +0100

> So, I want to hear what folks think it does.

What CoAP does (and I don't just think it does, it actually says so in 
the draft) is that is suggests the use of lists of identifiers that are 
allowed to start DTLS sessions with the CoAP server.
That makes them access control lists for an "all-or-nothing" access 
control approach, and currently that's all access control that is in the 
CoAP draft.

Btw. it even says "access control list" for RawPublicKey mode in section 
9.1.3.2.1.:

"During (initial and ongoing) provisioning, an access control list of 
identifiers the device may start DTLS sessions with SHOULD also be 
installed and maintained."

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: Fri, 13 Dec 2013 17:03:05 +0100

Apparently, I'm not understanding the question, because I thought I  
had answered it.

On Dec 13 2013, at 16:31, Hannes Tschofenig wrote:

> "CoAP does not specify how access control is accomplished and  
> therefore this work introduces these mechanisms."

Well, it says that access control is to be performed at the server,  
using the authentication provided by DTLS.
It does not say
-- what the structure of an ACL or a similar data structure would be,  
and, in particular, 
-- what granularity the access matrix should have, neither on the  
object nor on the subject side, nor with respect to permissions.
It does not define operations on such a access control matrix.

So my naive expectation of the work here (shared somehow between CoRE  
and ACE) is:
-- we are going to define resources ("a Web API") that enable the  
server to build ACL-like information
-- the subject side can bind to DTLS authentication mechanisms and/or  
some object security
-- authorization includes authorization for operations on the  
information leading to the ACL-like data structure
-- we are using existing CoRE mechanisms (CoAP's REST methods, Web  
linking, RD, ...) wherever that helps

The combination of all this with existing mechanisms such as DLTS,  
certs, etc. will be "how access control is accomplished".

Closer to your question?

Grüße, Carsten

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 13 Dec 2013 18:10:20 +0100 (CET)

Hi Ludwig,

thanks for the response.

I think the concept of access control had gotten wrong there a bit.

Many devices may need to have some information (like an IP address, FQDN, or URIs) for the services they have to interact with.

I would have not called this an access control list. The access control list is either on the server side or on a third party that makes the decision about accessing the server.

For the use of raw public keys from the server to the client you actually have to do some out-of-band validation of the public key of the server. The specification is explicit about the need for it. There is no identifier that comes along with the public key as such since the idea was to stripped off everything from a certificate except for the public key.

Does this make sense?

Ciao

Hannes

Gesendet: Freitag, 13. Dezember 2013 um 15:51 Uhr

Von: "Ludwig Seitz" <[email-masked]>

An: [email-masked]

> I have not closely followed all the CORE work but there seems to be a

> view of what CoAP does.

CoAP draft.

9.1.3.2.1.:

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

Ace mailing list

[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 15 Dec 2013 16:34:19 +0100

Hi Hannes,

device identifiers aren’t access control lists, but they can be used to index an ACL (i.e., as the subject key into an access matrix).
This works well when you have a way to authenticate a claim that a requested operation comes from the device with a given device identifier (“speaks for” the identifier).
Associating a device identifier with an RPK is a way to authorize the holder of the associated private key to speak for the identifier, i.e., to make use of all ACL entries that give the identifier some permission.
You might as well use the RPK as a device identifier, removing the need for maintaining that association, but there may also be benefits to an indirection through the device identifier.

One important thing to remember here is that the “servers” in CoAP are the most constrained devices.
They also can’t reasonably talk to a big brother (cf. EAP’s authentication server) for each enforcement decision.
So the constrained devices really need a (simple form) of ACL/C-list, one which is set up to enable authenticated authorization.  We already have the authentication part for using that ACL/C-list via DTLS.

Delegating the onus of communication with the big brother to the client is one of the ideas behind several of the proposals here, including DCAF.
Now that needs a way to authenticate the input from the big brother to the server via multiple DTLS hops (item 3 on slide 105 from core@IETF88).
It also would benefit from some standardized form of ACL/C-list (item 2 on that slide).

Göran is right that there is a lot of work that still needs to be done, and I want to thank you for asking good questions here.  There are often three phases of dealing with complexity:
1) when you don’t understand things, everything seems simple;
2) when you start to understand things, everything appears to become more and more complex;
3) when you really understand things, you discover the structure relevant to making things simple again.
We are in the middle of phase 2, and your input will help us get to phase 3; I’m confident that this will all be much simpler when we are done with that.

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 16 Dec 2013 10:38:52 +0100

On 12/13/2013 06:10 PM, Hannes Tschofenig wrote:
> Many devices may need to have some information (like an IP address,
> FQDN, or URIs) for the services they have to interact with.
> I would have not called this an access control list. The access control
> list is either on the server side or on a third party that makes the
> decision about accessing the server.

Just to make sure we don't misunderstand each other: when I say 
(resource) server I mean the device. So yes, the list is on the server 
side according to my understanding of the CoAP spec.

Furthermore: It's a list that is used to decide who gets to make a DTLS 
connection to the device. With no other access controls present I'd call 
this an "access control list", and apparently so does the CoAP spec.

Could you elaborate on why you think this gets the concept of access 
control wrong?

> For the use of raw public keys from the server to the client you
> actually have to do some out-of-band validation of the public key of the
> server. The specification is explicit about the need for it. There is no
> identifier that comes along with the public key as such since the idea
> was to stripped off everything from a certificate except for the public
> key.

Right, isn't that exactly what the CoAP spec says? I hope I didn't give 
the impression I was questioning that.

 From the CoAP spec:

    RawPublicKey:  DTLS is enabled and the device has an asymmetric key
       pair without a certificate (a raw public key) that is validated
       using an out-of-band mechanism [I-D.ietf-tls-oob-pubkey] as
       described in Section 9.1.3.2.  The device also has an identity
       calculated from the public key and a list of identities of the
       nodes it can communicate with.

-- 
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: Paul Madsen <[email-masked]>
Date: Mon, 16 Dec 2013 03:41:18 -0800

what does it mean to define the ACLs? define a format?

and, if so, what is the motivation for a standard format? not interchange
presumably?

paul

On Fri, Dec 13, 2013 at 12:22 AM, Ludwig Seitz <[email-masked]> wrote:

>>> in a couple of drafts I see these pointers to access control lists being
>>> described in CoAP. However, the CoAP specification does not really say that
>>> much about access control lists and by no means describes how they are
>>> supposed to be used in any level of detail.
>>>
>>
>> It just says you need to have some, because the authentication that we
>> get with DTLS is not the complete answer to the security requirements.
>>

-- 
Paul Madsen

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 16 Dec 2013 12:45:06 +0100

> what does it mean to define the ACLs? define a format?

That's how I understood it.

> and, if so, what is the motivation for a standard format? not
> interchange presumably?
>
> paul
>

If different manufacturers agree on a single ACL format, you can 
centrally manage ACLs and provision them to devices from both 
manufacturers using the same set of tools.

/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: Paul Madsen <[email-masked]>
Date: Mon, 16 Dec 2013 04:01:52 -0800

thanks Ludwig, I wasnt aware of the need for the provisioning use case

paul

On Mon, Dec 16, 2013 at 3:45 AM, Ludwig Seitz <[email-masked]> wrote:

> If different manufacturers agree on a single ACL format, you can centrally
> manage ACLs and provision them to devices from both manufacturers using the
> same set of tools.
>
> /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
>
>

-- 
Paul Madsen

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 16 Dec 2013 13:09:15 +0100

On 12/16/2013 01:01 PM, Paul Madsen wrote:
> On Mon, Dec 16, 2013 at 3:45 AM, Ludwig Seitz <[email-masked]
> <mailto:[email-masked]>> wrote:
>

BTW as was pointed out to me by Zach Shelby, a lot of work on 
provisioning in general and ACLs specifically, has been done in 
OMA-Lightweight M2M [1].

Does anyone see a compelling reason to reinvent that stuff for use cases 
where provisioning ACLs works to cover access control?

/Ludwig

[1] http://openmobilealliance.org/about-oma/work-program/m2m-enablers/

-- 
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: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Dec 2013 20:58:16 +0000

Very good question, Paul.

Historically, standardizing access control policies has not been very
successful (neither in the IETF nor in other organizations). Most
deployments either use proprietary extensions (because it provides
companies the glue they need to hold their different components together
and to provide a competitive advantage) or handle authorization at a
dedicated server (which requires a different type of standardization).
An example for the former: Kerberos authorization extension by
Microsoft. An example of the latter: AAA.

Now, the argument is that you want to have interoperability of
authorization decisions and maybe the outsourcing of the authorization
decision to a central server does not work.

Ciao
Hannes

On 12/16/2013 11:41 AM, Paul Madsen wrote:
> On Fri, Dec 13, 2013 at 12:22 AM, Ludwig Seitz <[email-masked]
>         On 12 Dec 2013, at 19:32, Hannes Tschofenig
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>             Hi all,
>
>             in a couple of drafts I see these pointers to access
>             control lists being described in CoAP. However, the CoAP
>             specification does not really say that much about access
>             control lists and by no means describes how they are
>         It just says you need to have some, because the authentication
>         that we get with DTLS is not the complete answer to the
>         security requirements.
>
>         Let's decide which WG does what *after* deciding what needs to
>         be done.)
>
>         Grüße, Carsten
>
>     +1
>
>     -- 
>     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 <tel:%2B46%280%2970-349%2092%2051>
>     http://www.sics.se
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Dec 2013 21:33:07 +0000

Hi Carsten,

> device identifiers aren’t access control lists, but they can be used to index an ACL (i.e., as the subject key into an access matrix).

This is pretty much how AAA servers work (in the simplistic case).  You
have a list of identifiers and their credentials. If authentication
works then you get network access or access to some other service.

Identity-based authorization is extremely common on the Internet in general.
> One important thing to remember here is that the “servers” in CoAP are the most constrained devices.
Let's see how the deployment reality works out. It is a bit premature to
tell that at this point in time.
> They also can’t reasonably talk to a big brother (cf. EAP’s authentication server) for each enforcement decision.

Maybe. I am also not so sure about that.

> It also would benefit from some standardized form of ACL/C-list (item 2 on that slide).

Got that for the three party model.

> We are in the middle of phase 2, and your input will help us get to phase 3; I’m confident that this will all be much simpler when we are done with that.
The challenge for me is to find the right assumptions. From the
discussions I can see that you make certain assumptions about the
expected deployment environment. From the answer about the use case
gathering we are sort of guessing a bit (and that's fine) but there is
also the risk that we get it completely wrong.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Dec 2013 21:40:02 +0000

Hi Ludwig,

thanks for the feedback and pointing me to the right places in the document

I think the following wording confused me:

"
   During the provisioning phase, a CoAP device is provided with the
   security information that it needs, including keying materials and
   access control lists.
"

I think the text should either say:

"
   During the provisioning phase, a CoAP server is provided with the
   security information that it needs, including keying materials and
   access control lists.
"

or

"
   During the provisioning phase, a CoAP client is provided with the
   security information that it needs, including keying materials and
   information about the CoAP servers it needs to interact.
"

Maybe there is still a chance to clarify this in AUTH48.

Ciao
Hannes

On 12/16/2013 09:38 AM, Ludwig Seitz wrote:
> Furthermore: It's a list that is used to decide who gets to make a
> DTLS connection to the device. With no other access controls present
> I'd call this an "access control list", and apparently so does the
> CoAP spec.
>
> Right, isn't that exactly what the CoAP spec says? I hope I didn't
> give the impression I was questioning that.
>
> From the CoAP spec:
>

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 17 Dec 2013 11:08:45 +0100

On 12/16/2013 09:58 PM, Hannes Tschofenig wrote:
> successful (neither in the IETF nor in other organizations).

Sorry, but this is just wrong.

Just have a look at XACML and the list of companies using it [1] (and 
that list is hardly up to date).
There are several companies selling XACML products (including Oracle, 
IBM, Quest, NextLabs, and Axiomatics).
If you look at e.g. the Axiomatics customer list [2] a lot of companies 
are buying these products (e.g. Bank of America, PayPal, Bell 
Helicopter, Boeing, the Swedish Public Employment Service, DATEV, Swiss Re).

Identity and Access Management is a very small market and it takes a lot 
of convincing to make companies buy anything new in that sector (since 
it doesn't affect sales immediately), but I'd claim that
XACML has been very successful as far as standardizing access control 
policies goes.

/Ludwig

[1] 
https://www.oasis-open.org/committees/download.php/42588/xacmlRefs-V1-85.html#Products

[2] https://axiomatics.com/customers.html

-- 
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, 17 Dec 2013 11:25:53 +0100

> Identity-based authorization is extremely common on the Internet in general.

Certainly.
One of the embryonic results of the Paris workshop was that maybe the importance of identity will be different for constrained devices.
So I would like to be prepared for a world where not everything needs to go through naming authorities.

> tell that at this point in time.

The deployment reality right now is dominated by IPv4 concerns.  
In IPv4, servers are useless, so everything is a client, and you need to put everything else in the cloud.
I’m not sure we want to continue to emulate this world.

But yes, we want to make sure that what we do works for both constrained clients and constrained servers.
That’s one reason why delegation is such an important function here.

> Maybe. I am also not so sure about that.

Each resource access needs an enforcement decision.  So I’m pretty sure about that :-)

[…]
> also the risk that we get it completely wrong.

Absolutely.  We may be “flexible” in some things, but will have to make assumptions in other things.
That set of assumptions is what is usually called an “architecture”…
I’d like this work to stay within the CoRE architecture instead of trying to solve all possible problems.

Grüße, Carsten