Subject: [Ace] DTLS and OSCOAP

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Mar 2016 18:59:50 +0100

Hi all,

in specifying the details for the communication between the client and
the RS we need to settle on a security mechanism.

There are four options:

* Option #1: Do not specify a solution in the WG document (1)

* Option #2: Specify a DTLS-based solution

* Option #3: Specify an application layer solution (for example using
OSCOAP)

** Option #4: option #2 + option #3

Note: We are asking for feedback about what should go into
draft-ietf-ace-oauth-authz. There is always the possibility to specify
other solutions in separate documents in parallel or later.

Here are the slides from the ACE virtual interim meeting providing
further background information:
https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-4.pdf

Deadline: 16th March 2016

Ciao
Hannes & Kepeng

PS: (1) This was the approach that was selected in OAuth where the
Bearer Token specification was published as a separate RFC.

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 2 Mar 2016 20:10:45 +0100

+1 on
/ Erik

On Wed, Mar 2, 2016 at 6:59 PM, Hannes Tschofenig <[email-masked]
> wrote:

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

---

From: Göran Selander <[email-masked]>
Date: Thu, 3 Mar 2016 09:50:03 +0000

From: Ace <[email-masked]<mailto:[email-masked]>> on behalf of Erik Wahlström <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 2 March 2016 at 20:10
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] DTLS and OSCOAP

+1 on

+1

Göran

/ Erik

On Wed, Mar 2, 2016 at 6:59 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

There are four options:

Ciao
Hannes & Kepeng

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 03 Mar 2016 11:55:01 +0100

We had a slightly different set of options when we looked at this in the
phone meeting.  What I said (and what I think received agreement in the
room) was to do the DTLS-based version in the initial WG document, and
to be ready to do an "object security" style solution once the
foundation for that becomes available -- possibly later in a separate
document or possibly right in the initial WG document.

So this would be your option 4, but with the twist that we are cognizant
the "object security" solution might not become ready at the same time.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 3 Mar 2016 12:16:34 +0100

-- chair hat off

I would go for option #1 similarly to how it was done in the OAuth WG.
The DTLS-based solution (as well as the application layer solution)
should be documented in separate documents ideally in parallel with the
ACE OAuth WG document.

---

From: Göran Selander <[email-masked]>
Date: Thu, 3 Mar 2016 13:19:36 +0000

Hi Carsten, all

On 2016-03-03 11:55, "Ace on behalf of Carsten Bormann"
<[email-masked] on behalf of [email-masked]> wrote:

>phone meeting. 

I’m sorry I missed the end of the meeting since I had to leave after one
hour (when it was scheduled to end).

> What I said (and what I think received agreement in the

Let's distinguish between COSE and OSCOAP; COSE will be finished before
this draft.

What needs to be specified in this draft is essentially the transport of
the access token and the keys to use with transport or application layer
security, and COSE is sufficient to specify whatever keys that are needed
for an object security solution.

So if we reword option 3 as

"* Option #3: Specify a COSE-based solution"

then I don’t think there is a need to make this disclaimer, is there?

Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 3 Mar 2016 13:27:58 +0000

Hi Hannes, all

>should be documented in separate documents ideally in parallel with the

As far as I understand, with OAuth the TLS session between Client and RS
is typically independent of the key in the PoP token. That is quite
different from the setting in ACE where the key(s) in the PoP token/Client
Information is used to secure the subsequent communication between Client
and RS.

Therefore some more considerations about how transport/application layer
security is established is needed in the core document.

Göran

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 8 Mar 2016 09:37:05 +0100

> ** Option #4: option #2 + option #3

I think we need to specify at least one of the commSec approaches, 
otherwise people might just implement it without commSec.

I vote for option #3 with COSE in mind.

(I also strongly support specifying #2 in a separate document).

-- 
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 9251
http://www.sics.se

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Mar 2016 13:45:57 -0500

> ** Option #4: option #2 + option #3

I'm afraid of OSCOAP because I don't know if it will happen.
(It might be like S/MIME or SNMPv3 security...)
I'm afraid of #4, because if #3 doesn't happen, its the same as #2.

    > "* Option #3: Specify a COSE-based solution"

I feel that this will succeed.
I think that we are better to pick one method here.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 10 Mar 2016 08:06:05 +0100

Hi

I might be missing something but I don’t see how COSE in it self solves the
secure transport between C and RS. With DTLS the a secure channel is
established and then all content goes through it (we can use the PoP key to
establish the channel). COSE enables us to send secure messages with e.g.
the PoP key but it is not a secure channel that we will send everything
through i.e. we would need a way of binding it to CoAP or some other
transport.  With DTLS the full transport is wrapped in the secure channel
but I don’t think that is how you would use COSE. This is similar to the
first defined usage of PoP tokens in OAuth where JOSE is used to sign HTTP
messages, the whole HTTP message is not wrapped in JOSE messages only
specific parts of the message is included in the signature.

So I cannot se how we can do a COSE-based solution without specifying
something like OSCOAP. So to say COSE-based solution indirectly means that
we need to specify something like OSCOAP or Signed HTTP.

Even though there is difference between the use of TLS in OAuth and DTLS in
ACE I think it is similar enough. In OAuth there is no integration with the
TLS layer using PoP keys but it is transport layer security wrapping the
full content.

//Samuel

---

From: Göran Selander <[email-masked]>
Date: Thu, 10 Mar 2016 07:11:36 +0000

Hi Michael,

>(It might be like S/MIME or SNMPv3 security...)

Yes, the future is uncertain. As a co-author of OSCOAP I would of course
like to know if you can share some profound understanding or if it is just
a feeling.  Could you please be more specific by highlighting which of the
cases below you fear:

(a) the use cases addressed by OSCOAP (e.g. confirmation of GET
/alarm-status, confirmation of actuator request passing through a proxy)
are not relevant or the security issues will be ignored,

(b) no one will use CoAP for these use cases, or

(c) the method provided by OSCOAP is not the right solution to secure CoAP
for these use cases

>I think that we are better to pick one method here.

Well, OSCOAP is a COSE-based method.

Göran

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 10 Mar 2016 10:47:56 +0100

Hi,

Samuel Erdtman <[email-masked]> writes:

> I might be missing something but I don’t see how COSE in it self
> solves the secure transport between C and RS.

There are at least two proposals in ACE that show how COSE can be used
for secure transport between C and RS: OSCOAP and DCAF-COSE. The
details have to be worked on, but the direction is clear.

> Even though there is difference between the use of TLS in OAuth and
> DTLS in ACE I think it is similar enough. In OAuth there is no
> integration with the TLS layer using PoP keys but it is transport
> layer security wrapping the full content.

I would hope that the usage of DTLS in ACE will be superior than the
usage of TLS in OAuth, i.e. the authorization must be bound
intrinsically to the secured channel as has been discussed before.

Grüße
Olaf

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Mar 2016 08:43:51 -0500

>>
    >> Hannes Tschofenig <[email-masked]> wrote: > There are four
    >> options:
    >>
    >> > * Option #3: Specify an application layer solution (for example
    >> using > OSCOAP)
    >>
    >> I'm afraid of OSCOAP because I don't know if it will happen.  (It
    >> might be like S/MIME or SNMPv3 security...)

    > Yes, the future is uncertain. As a co-author of OSCOAP I would of
    > course like to know if you can share some profound understanding or if
    > it is just a feeling.  Could you please be more specific by
    > highlighting which of the cases below you fear:

    > /alarm-status, confirmation of actuator request passing through a
    > proxy) are not relevant or the security issues will be ignored,

    > (c) the method provided by OSCOAP is not the right solution to secure
    > CoAP for these use cases

My concern is that *OpenSSL* (uh, I mean:  *SSL*, or maybe I mean *TLS*) is
well understood by product marketing people, while all the other acronyms are
not.

So I'm hopeful for option #3: and I don't want #2 or #4, because means it
will be transport layer security only.