Subject: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Oct 2015 15:49:59 +0100

Hi all,

Kepeng and I are talking about the agenda and here is an interesting
case where we need to get the feedback from the working group.

We have gotten an agenda request for draft-bergmann-ace-dcaf-cose-00,
which is about using COSE to provide a object-level security for DCAF.

In previous IETF meetings we have heard about a more generic solution,
namely draft-selander-ace-object-security-03. It will be presented in
COSE/CORE (if the requests get granted).

Here is the issue:

1) Officially, we have no milestone in ACE to work on such a document at
all right now.

2) Should we have a presentation about draft-bergmann-ace-dcaf-cose-00
when we have already heard about the more generic version before hand?

Hence, the question to the group is the following:

a) Where does the COAP application layer security belong? Is ACE the
right place or is it rather CORE or COSE?

If it is ACE should we ask our AD to add another milestone?

b) What would the purpose of a presentation of
draft-bergmann-ace-dcaf-cose-00 and / or
draft-selander-ace-object-security-03 be in ACE for this meeting?

If we indeed to the work in ACE then wouldn't it be a useful goal for
the meeting be to make a decision about the solution direction? This
would of course require us to listen to both solution directions rather
than only to one. I would in particular be interested what motivated the
work on draft-bergmann-ace-dcaf-cose-00  given the existence of
draft-selander-ace-object-security-03...

Ciao
Hannes & Kepeng

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 28 Oct 2015 16:21:33 +0100

Hi Hannes,

> which is about using COSE to provide a object-level security for DCAF.

No, it's not. It is about providing authenticated authorization which is
clearly in the focus of the ACE WG. It does this by using DCAF.

At the IETF-93 meeting in Prague, several people criticized
draft-gerdes-ace-dcaf-authorize because it uses DTLS to provide secure
communication. The new draft-bergmann-ace-dcaf-cose specifies how DCAF
can be used with COSE syntax. It does *not* specify how object security
works, it just *makes use* of what is already there.

The intention of the presentation therefore is to explain how DCAF can
be used in the presence of intermediaries. I am not going to discuss in
ACE whether CoAP option X needs to be protected by mechanism Y as other
people tried to. This is clearly something that needs to be discussed in
CORE and COSE where it belongs. Once a viable object security mechanism
has been defined by these to working groups (my dcaf example shows that
COSE is close by while CORE has some work to do in this regard).

> In previous IETF meetings we have heard about a more generic solution,

Please, do not mix up things. DCAF-COSE is about authenticated
authorization, draft-selander-ace-object-security is about object
security.
 
> 1) Officially, we have no milestone in ACE to work on such a document at

We are going to standardize a solution for authenticated authorization,
aren't we? DCAF is a proposal for this, and draft-bergmann-ace-dcaf-cose
addresses on of the open issues that have been raised in the past.

> when we have already heard about the more generic version before hand?

See above. You are missing the point of draft-bergmann-ace-dcaf-cose.

> right place or is it rather CORE or COSE?

COAP application layer security belongs to CORE.

> draft-bergmann-ace-dcaf-cose-00

Addressing the issue raised at the Prague meeting: DCAF is a perfect fit
for ACE because it can be used with transport layer security and object
security and is able to handle the three communication patterns that
have been brought on the table (IIRC they have been called "push",
"pull", and "client pull").

> and / or draft-selander-ace-object-security-03 be in ACE for this
> meeting?

I am happy to discuss this I-D during COSE and CORE.

> draft-selander-ace-object-security-03...

My hope is to have explained that it bit. draft-bergmann-ace-dcaf-cose
is not in concurrency to draft-selander-ace-object-security. It just
happens to use COSE in a more REST-like way. But that is a discussion
for CORE. Let ACE focus on the authorization aspects of both drafts
where draft-bergmann-ace-dcaf-cose is a perfect amendment of
draft-gerdes-ace-dcaf-authorize.

Grüße
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Oct 2015 16:36:01 +0100

Hi Olaf,

I think you are playing with words a bit when you say it is about
"authenticated authorization rather than object security" when there is
clearly an overlap between the two solutions.

Anyway, if you believe this is special to DCAF then it should be covered
as part of the DCAF presentation rather than as a separate solution.

When I had a chat with Kepeng we noticed that you split up the solution
into separate different documents and I believe it would be a bit boring
for the working group to hear (Steffi, or Carsten) talk for 60 mins
about something that others only get 20 or 30mins only because they have
decided to put everything into one document.

I let the authors of draft-selander-ace-object-security-03 present their
views before we should decide where this topic should be covered.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Oct 2015 16:48:29 +0100

Hi Olaf,

I took a look at draft-selander-ace-object-security-03 again and in
Section 5 the document describes how CoAP messages are protected. This
is motivated by the presence of intermediaries where DTLS terminates
prematurely.

You are proposing essentially the same but the test is written in such a
way that it talks about DCAF.

In your mail below you have said already that you believe that this work
belongs to ACE.

So, I believe you are saying that we should ask our AD to add another
milestone for this type of work item.

Another possibility is to see it as part of the overall solution and it
may well be part of the solution document itself.

Ciao
Hannes

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 28 Oct 2015 17:02:35 +0100

Hannes,

> clearly an overlap between the two solutions.

I tried to make clear that I do not think that the ACE session is the
right place to discuss the details of object security but rather to
discuss how this can be used to achieve the goals of the ACE WG. The
overlap is something that does not affect the work in the ACE WG.

> decided to put everything into one document.

First of all: I was not aware that discussing different things in
different documents is considered a bad thing. The split was made to
avoid draft-gerdes-ace-dcaf-authorize getting too complex in this
stage. If later in the process, the WG thinks that these two documents
should be merged, we will be happy to do that.

Regarding the agenda slot: We did not intend to talk 60 mins on the
DCAF-related documents or have multiple slots for DCAF. Feel free to
make it a single slot of 20--30 mins.

Grüße
Olaf

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 28 Oct 2015 17:21:37 +0100

Hannes Tschofenig <[email-masked]> writes:

> how CoAP messages are protected

> way that it talks about DCAF.

Again: We have addressed the request for transferring DCAF in a way that
allows for protecting the contents on the application layer instead of
using transport layer security. Hence it should not come as a surprise
that this document talks about DCAF.

> In your mail below you have said already that you believe that this work

DCAF belongs to ACE.

The question how CoAP messages are protected on the application layer
IMO does not belong to ACE. I think that the CoAP experts in the CoRE WG
should define how COSE can be used for that. Hence, it is a CoRE item.

> milestone for this type of work item.

I am not sure I understand what you mean whith "this type of work item".

> may well be part of the solution document itself.

My approach would be to let CoRE (possibly together with COSE folks)
standardize a mechanism to protect CoAP messages on the application
layer and then use that mechanism for the authorization solution in
ACE. We do this with DCAF-DTLS and that is also where DCAF-COSE is
heading. But since CoRE does not yet have a working group item on the
object security part I went for my own basic understanding of how COSE
messaging is designed to be used. It is pretty much a high-level summary
of which DCAF information item must go where, the details still to be
worked out.

Grüße
Olaf

---

From: Göran Selander <[email-masked]>
Date: Wed, 28 Oct 2015 21:17:14 +0000

Hi Olaf, Hannes, and all,

Last week I pointed out some flaws in the security solution of DCAF
(draft-bergmann-ace-dcaf-cose-00). Here is the mail:

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

I haven’t seen any reply to that. Meanwhile I don’t consider DCAF-COSE to
be a solution to anything.

I’m not the one setting the agenda, but in order to reserve time for a
draft at the F2F meeting, isn’t it reasonable that the authors before the
meeting at least make it plausible that their security solution can work?

Göran

On 2015-10-28 16:21, "Olaf Bergmann" <[email-masked]> wrote:

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Oct 2015 09:40:57 +0900

Göran,

maybe I didn't pay enough attention, but I thought what you pointed out
was not so much a security flaw but protecting too much:
There are some transformations that might be performed by a proxy that
are detected by the current version of DCAF-COSE (and thus would be
rejected).
The OSCOAP draft addresses this by either not protecting this
information (PAYL, now called OSCON) or by a somewhat more invasive
approach to CoAP attributes (new options, what you call OSCOAP now).

Which CoAP attributes need to be protected in what use cases (and how
the attributes might have to change to enable protecting them better) is
an important discussion to have; we had that on the CoRE agenda already
but I just allocated more time to that.

What I expect ACE to deliver is the security protocol for setting up
that protection.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Thu, 29 Oct 2015 08:06:12 +0000

Carsten and all, 

On 2015-10-29 01:40, "Carsten Bormann" <[email-masked]> wrote:

>Göran,
>
>maybe I didn't pay enough attention,
> 

[GS] Perhaps. Or maybe there are more people that hasn’t understood this.
Let me try with more words.

>but I thought what you pointed out

[GS] Security is about protecting the right thing, not too little, not too
much. If the security mechanism doesn’t work during normal operations it
is not a security solution.

>are detected by the current version of DCAF-COSE (and thus would be

[GS] If you can’t distinguish a normal operation from an attack then there
is not much security provided. Recall that this is not a corner case, it
is exactly the problem is DCAF-COSE claims to solve as is stated in
Section 1:

"In the presence of intermediaries such as, e.g., CoAP proxies, channel
security may not be applicable for all configurations.  If this is the
case, the exchanged information must be protected at the application level
to help achieving the principals' security requirements."

To summarize: CoAP defines operations that proxies can perform on
messages. If you use DTLS, that must be terminated at the proxy for it to
perform those operations. To achieve end-to-end security of sensitive
parts of the CoAP message those must therefore be protected appropriately,
but obviously not at the cost of preventing normal operations. This is
where DCAF-COSE fails and thus is not a solution.

>approach to CoAP attributes (new options, what you call OSCOAP now).

[GS] Let’s take a step back. I made a review of DCAF-COSE and presented
some issues. There is no need to discuss OSCOAP to understand the
limitations of DCAF-COSE. Olaf even claims that DCAF-COSE has nothing to
do with OSCOAP. But since you bring it up I’m happy to explain how OSCOAP
proposes to solve the security problem DCAF-COSE fails to solve. (This was
already in version -00, submitted a year ago.)

But first, yes, the terminology has changed: the terms “Mode:COAP” and
“Mode:PAYL" turned out to be misleading. It implied two different modes of
operation of a single protocol but the protocols are in fact quite
different. So instead we now distinguish between object security of CoAP
messages (OSCOAP) which protects CoAP payload and sensitive options and
header fields; and object security of “content” (OSCON) which only
protects payload and is not bound to CoAP. OSCON is a quite trivial
wrapping of message content in a certain kind of message format and is
included in appendix C of the OSCOAP draft just for comparison.

OSCOAP addresses the issue mentioned previously in this mail by defining
“invariants". A CoAP proxy may perform certain legitimate actions and
change the content of CoAP options, but the originating and destination
endpoint should both be able to establish certain invariant information
that is not supposed to be changed by a legitimate proxy, e.g. the
intended resource URI or URI scheme addressed by the request reaching the
destination server. This information is integrity protected in OSCOAP by
considering how options are legitimately changed by intermediate nodes (to
the best of our understandning from reading the CoAP draft, further
reviews would be helpful here!). Note that the invariant in itself is
*not* transported in the message. It is constructed by both client and
server, and fed into the algorithm for proving and verifying the integrity
of the message. The details are in section 6.2.1.2 of the OSCOAP draft.

I don’t understand what you mean by “invasive approach to CoAP attributes
(new options ...)”. OSCOAP used to define two new options “Enc” and “Sig”
(indicating a JWE object or JWS object, respectively), but they are now
replaced with one single option called “Object-Security” (indicating a
COSE object). As a comparison DCAF-COSE adds two new CoAP options.

>but I just allocated more time to that.

Yes, and maybe we need to allocate more time to this since there are
fundamental parts here that doesn’t seem to be understood?

>What I expect ACE to deliver is the security protocol for setting up

There are several parts to this “security protocol”.

- I agree that “Which CoAP attributes need to be protected in what use
cases (and how the attributes might have to change to enable protecting
them better)” need to be discussed and defined in CORE. This also includes
*how* the CoAP attributes are protected, and how the CoAP message
*changes* when some of its attributes are e.g. encrypted. This is in the
OSCOAP draft. DCAF-COSE doesn’t at all go into this and just notes:
“Note 1: Where confidentiality is required, a COSE_encryptData structure
will be used instead of the COSE_Mac structure."

- The invariants mentioned above must also be defined in CORE since they
are closely tied to the legitimate CoAP proxy operations. This is in the
OSCOAP draft.

- The CoAP option indicating that the CoAP message is protected by object
security is something that I suppose better be defined in CORE. This is in
the OSCOAP draft.

- How the CoAP attributes, invariants etc. are formatted as “external
authenticated data” (or external_aad as COSE renamed it) *could* be
defined in ACE but seems more relevant to define in CORE, in the same
draft as the Object-Security option, invariants etc. are defined. This is
in the OSCOAP draft.

Once this is defined, COSE does the job of protecting that CoAP message
associated data.

What I see left for ACE to provide is e.g. how the authorization server
signals what security protocol (DTLS, TLS, OSCOAP, OSCON, etc.) and what
security context to use between client and resource server, in the
particular security setting the AS is set to control. This is what we
propose as one OAuth extension for IoT.

Göran

PS With this in mind maybe OSCOAP should be resubmitted as a CORE draft?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Oct 2015 18:44:55 +0900

Well, OK, so both drafts are not security solutions by your definition,
because the work on OSCOAP invariants also appears to be unfinished (or
we wouldn't have to discuss it).

I think the more interesting observation is that we need a way for the
client to integrity-protect a view by the server about what the client
*should* have received from the proxy as the set of URI options.  For
instance, it is not clear to me that the host part that the client uses
to tell the proxy what server it wants it to talk to needs to be known
to the server (e.g., the client may be using an RD endpoint name or DNS
name as the host part, and the server may be blissfully unaware about
all that).  More generally, the operation of a reverse-proxy has even
more freedoms for the proxy, and I'm not sure that we can always treat
all reverse-proxies as having all of the authorizations of the server.

(And that is where DCAF-COSE's Authorization-Format option comes in
handy: There may be quite different ways to construct the Authorization
Option.  Of course, that information could instead be encoded into
different values of the Authorization option number for each new such
format.)

Yes, we need that time in the CoRE meeting...
(And, indeed, the interesting questions here appear to be CoRE questions.)

When we're done with the above, we can start to think about the best
ways to protect Max-Age via caching intermediaries (the spoofing of
which clearly has significant security implications).  (In parallel, we
could do a version that survives an HTTP-CoAP mapper.)

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Thu, 29 Oct 2015 10:24:10 +0000

>we wouldn't have to discuss it).

Well, in CORE I was thinking of discussing e.g. blockwise, which cannot
provide end-to-end security of individual blocks, and which does not allow
an invariant to be defined. But this is a security issue with blockwise,
not with OSCOAP. Or Observe, which is supported in OSCOAP by introducing
separate contexts for sending and receive, but which could be optimized.
In both these cases, secure block options and a secure observe option are
IMHO candidate solutions. As mentioned we welcome a review of OSCOAP; we
are not aware of any issues, in contrast to DCAF-COSE which essentially
would need to re-invent OSCOAP to address the things we have discussed so
far.

>all that). 

Yes, that is the type of discussion we want to have.

> More generally, the operation of a reverse-proxy has even

Also good topics for the CoRE meeting.

---

From: Göran Selander <[email-masked]>
Date: Thu, 29 Oct 2015 15:48:37 +0000

Hi Olaf, Hannes and all,

Coming back to the ACE discussion.

>of which DCAF information item must go where, the details still to be

[GS] I also agree that the object security of CoAP discussion belongs in
CORE and as such, there is no need to present that in ACE. Although object
security for CoAP isn’t a working group item, there is only one candidate
proposal, it has been around for a year, it has been presented in the last
two CORE F2F meetings so is clearly known to the authors.

Nevertheless, they chose to not use that but instead tries to reinvent the
wheel and it is obviously overlapping with OSCOAP: Indeed, both solutions
describe protection of CoAP messages based on wrapping CoAP header fields
Code and Version together with a selected list of delta-encoded options
(section 6) and payload as a COSE message which includes a context
identifier in the protected header and send this as payload of a CoAP
message, unless the CoAP message payload is not possible (e.g. in GET
requests) in which case a new CoAP option is introduced which then
contains the COSE message. There are of course differences in details,
e.g. DCAF-COSE turns out to miss some of the security features of OSCOAP.

Of course, everyone is entitled to submit their own proposal even though
there are candidates which has been around for a while. The interesting
point is that this is actually symptomatic of DCAF, see below.

>works, it just *makes use* of what is already there.

Actually, DCAF in general does *not* make use of what “is already there”.
OSCOAP “was already there” but instead DCAF instead tries to re-invent it.
And this is not an isolated example, here is a short list

0. DCAF does not make use of OSCOAP but tries to reinvent something
similar 
1. DCAF does not use established terminology, it invents its own names: of
nodes in the architecture, of messages, of access token, parts of access
token, “authenticated authorization”, etc.
2. DCAF does not use RFC4680 for transmitting the access token (which DCAF
calls “ticket") in the DTLS handshake, it invents its own version based on
PSK-identity
3. DCAF does not attempt to profile any existing authorization protocol,
like the established and widely deployed OAuth, but makes a clean slate.

I think this is the main question for the upcoming ACE WG meeting: Do we
want to reuse what “is already there” or do we want a clean slate?

Having said this, I would like to acknowledge that DCAF has some good
implementation considerations. Let's reuse those (instead of re-inventing
the wheel)  when we profile OAuth for IoT in ACE!

See you in Yokohama.

Göran