Subject: [Ace] Scope of the ACE Charter

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 05 Mar 2014 15:32:27 +0100

Hi all,

I would like to thank you all for the great discussion today at the BOF.
There was good feedback and the following scoping aspect showed up.

In a nutshell there was some disagreement to purely focus on CoAP/DTLS
as part of a future working group.

There was not enough time to go down to the details during the session
due to lack of time. Hence, I will try to clarify this aspect on the
mailing list.

Let us have a look at the high level architecture:

                                          +---------------+
                                          | Authorization |
             +--------------------------->|  Server       |
             |        (I)                 +---------------+
             |                                  ^
             |                                  |
             |                                  |
             |                                  | III
             |                                  |
             |                                  |
             |                                  |
             v                                  v
        +-----------+                     +-----+-----+
        |           |      II             | Resource  |
        |   Client  | <..................>| Server    |
        +-----------+                     +-----------+

I: This is the interaction where keying and authorization information is
provided to the client.

II: This is the resource access.

III: This is a potential exchange necessary for having the resource
server interacting with the authorization server for authenticating the
client and for authorizing the client.

(The exact details of the interaction depend on the specific solution,
of course.)

As you can see in the figure, there are various places where DTLS and
CoAP should or shouldn't be used.

A few persons said that they want to use other protocols besides CoAP
and DTLS.

Please explain me where you would like to other protocols being taken
into consideration. What protocols are you considering in which of these
interfaces?

Ciao
Hannes

---

From: Göran Selander <[email-masked]>
Date: Wed, 5 Mar 2014 18:23:00 +0000

Hi Hannes,

Just looking at interface (I): If the client is not constrained I think
HTTP/TLS should be an option to COAP/DTLS.

Adding to the discussion about HTTP/COAP proxies in the meeting: If both
the authorisation information and the keying information is object secure
(JWT, CMS, Š) there is no need to trust the proxy.

Göran

---

From: Zach Shelby <[email-masked]>
Date: Wed, 5 Mar 2014 10:35:08 -0800

Hi,

One of the "other" things mentioned was SMS, but that was just a misunderstanding. They were looking for DTLS support for SMS, which would be something for the TLS working group and not ACE. And with such support, of course that is CoAP/DTLS. So no issues on that one.

I think that on any one of those interfaces either CoAP/DTLS or HTTP/TLS could be used depending on the node and network. (ii) will typically be CoAP/DTLS as this is the whole point of the working group. (i) and possibly (iii) could be either.

Being the one that brought up the "proxy" issue, I probably used a really poor choice of words there. What I really meant was this duality of an HTTP/TLS based solution (OAuth) or a CoAP/DTLS solution on those interfaces, but choose one and run it end-to-end.

Zach

On Mar 5, 2014, at 6:23 PM, Göran Selander <[email-masked]> wrote:

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

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Likepeng <[email-masked]>
Date: Fri, 7 Mar 2014 10:42:28 +0000

Hi Zach,

>I think that on any one of those interfaces either CoAP/DTLS or HTTP/TLS could be used depending on the node and network. (ii) will typically be CoAP/DTLS as this is the whole point of the working g…

I am not sure why (ii) and (iii) are treated differently. I would assume that Resource Server is constrained, then (iii) should also typically be CoAP/DTLS too.

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Zach Shelby
发送时间: 2014年3月5日 18:35
收件人: Göran Selander
抄送: Hannes Tschofenig; [email-masked]
主题: Re: [Ace] Scope of the ACE Charter

Hi,

Zach

On Mar 5, 2014, at 6:23 PM, Göran Selander <[email-masked]> wrote:

> Hi Hannes,
>
>
> Just looking at interface (I): If the client is not constrained I 
> think HTTP/TLS should be an option to COAP/DTLS.
>
> Adding to the discussion about HTTP/COAP proxies in the meeting: If 
> both the authorisation information and the keying information is 
> object secure (JWT, CMS, Š) there is no need to trust the proxy.
>
> Göran
>
>> In a nutshell there was some disagreement to purely focus on 
>> CoAP/DTLS as part of a future working group.
>>
>> There was not enough time to go down to the details during the 
>> session due to lack of time. Hence, I will try to clarify this aspect 
>> on the mailing list.
>>
>> I: This is the interaction where keying and authorization information 
>> is provided to the client.
>>
>> server interacting with the authorization server for authenticating 
>> the client and for authorizing the client.
>>
>> (The exact details of the interaction depend on the specific 
>> solution, of course.)
>>
>> into consideration. What protocols are you considering in which of 
>> these interfaces?
>>
>> Ciao
>> Hannes
>>
>

Zach Shelby
Director of Technology

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Mar 2014 10:53:48 +0000

> as part of a future working group.

Yes, and (for some reason I don’t understand) nobody said aloud why that focus might be a problem (while, e.g., Sam very clearly said why *not* having that focus might be a problem).

It seems to me there is a false choice being presented here.

If we define a solution that is good for CoAP/DTLS, we would actively have to go out of our way to make that useless for HTTP/TLS.

So the legacy SEP2.0*) support that seems to be the issue behind this disagreement can easily be accommodated without the WG losing its focus.

Grüße, Carsten

*) Smart Energy Profile 2.0, based on a custom XML vocabulary, HTTP, TLS, TCP.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 7 Mar 2014 11:00:07 +0000

> On Mar 7, 2014, at 10:53 AM, Carsten Bormann <[email-masked]> wrote:
> 

Where is that conclusion assured in the ACE charter or otherwise documented?

> So the legacy SEP2.0*) support that seems to be the issue behind this disagreement can easily be accommodated without the WG losing its focus.

By "legacy" do you mean "not part of a walled garden"?

- Ralph

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Mar 2014 11:07:06 +0000

> Where is that conclusion assured in the ACE charter or otherwise documented?

We indeed have to add that consideration.
(It was not part of the feedback that led to the current charter draft.)

> By "legacy" do you mean "not part of a walled garden”?

No, legacy as in “inherited”.
This profile is out there, so we can’t ignore it, even if we wanted to.

Grüße, Carsten

---

From: Ralph Droms <[email-masked]>
Date: Fri, 7 Mar 2014 11:24:44 +0000

Hannes - I don't think I can answer your question as you've posed it.  COAP/DTLS might or might not be used across any of these interactions.  It really depends on the specific applications and deployment scenario - including considerations like scope of intended participants, interest in reusing existing deployed code, existence of gateways, etc.

- Ralph

> On Mar 5, 2014, at 2:32 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 7 Mar 2014 11:26:44 +0000

While a 100% constrained case is foundational I think you need to consider dual protocol and mixed protocol cases. 

Eg. A web server contacting a constrained resource. That server might obtain a token from an http authz server for use against a constrained resource. Or it might obtain one from a constrained authz server too. 

All permutations seem likely to me. So much so, I think a constrained only charter would be problematic. 

Phil

> On Mar 7, 2014, at 11:00, Ralph Droms <[email-masked]> wrote:
> 
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Mar 2014 11:30:53 +0000

> Hannes - I don't think I can answer your question as you've posed it.  COAP/DTLS might or might not be used across any of these interactions.  It really depends on the specific applications and dep…

Indeed, and, again, any reasonable solution that works with CoAP/DTLS will work with HTTP/TLS here as well.

What Steffi called I.2 is different from the other arrows as it is often not involving constrained nodes at all, so it is here that we want to embrace the ecosystem around HTTP/TLS (say, OAuth) more aggressively.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Fri, 7 Mar 2014 13:30:26 +0000

Hi Phil

On 07/03/14 11:26, "Phil Hunt" <[email-masked]> wrote:

>While a 100% constrained case is foundational I think you need to
>consider dual protocol and mixed protocol cases.
>
>Eg. A web server contacting a constrained resource. That server might
>obtain a token from an http authz server for use against a constrained
>resource. Or it might obtain one from a constrained authz server too.

I agree with your statement to consider mixed protocol cases, but just
want to point out that one reason for introducing the authz server is for
offloading a constrained resource server with policy management and
decision. So I would like to to assume that at least the authz server is
less constrained.

Göran

>>> Yes, and (for some reason I don¹t understand) nobody said aloud why
>>>that focus might be a problem (while, e.g., Sam very clearly said why
>>>*not* having that focus might be a problem).
>>> 
>>> If we define a solution that is good for CoAP/DTLS, we would actively
>>>have to go out of our way to make that useless for HTTP/TLS.
>> 
>>> So the legacy SEP2.0*) support that seems to be the issue behind this
>>>disagreement can easily be accommodated without the WG losing its focus.
>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 7 Mar 2014 13:51:18 +0000

Agreed. However I can see cases where RS and authz are both constrained because they are on same server. In this case i would suspect "policy" is largely driven by basic func of the device. 

I mention this because as/rs on one server occurs frequently on web, not sure constrained would never have this. 

Phil

> On Mar 7, 2014, at 13:30, Göran Selander <[email-masked]> wrote:
> 
> Hi Phil
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 08 Mar 2014 10:38:41 -0500

This is what I understand about the concern about scope.
(Gotta love emacs picture-mode... outlook users will need a fixed font)

                                          +---------------+
                                          | Authorization |
             +------------------+-------->|  Server       |
             |        (I)      /          +---------------+
             |       authz    /                 ^
             |               /                  |
          /--------\        /                   |
    (IV)  | oauth  |       /                    | III
          |  proxy |      /                     | authz
          \--------/     /                      |
             |----------/                       |
             v                                  v
        +-----------+         (access)    +-----+-----+
        |           |     /------\  (II)  | Resource  |
        |   Client  | <...|https/|.......>| Server    |
        +-----------+     | coap |        +-----------+
                          | dtls |
                          |proxy | (V)
                          \------/

====

IV - is some kind of translator that can take/process OAUTH2 (or some
     other system!) requests into our authorization protocol.  It might
     be that teaching the authorization server itself to speak OAUTH2
     is really the only answer, and that would be fine with me.

V - this is an HTTPS(with OAUTH2 token) to COAP/DTLS (with ACE token) proxy.

It would be nice if (V) did not have to have god/superuser access to the
authorization server. I.e. it would be nice if that proxy could be untrusted
by both the client and the authorization server.  

Does this diagram match what others have been asking about?
(I have intentionally left out the SEP2.0 stuff out of this diagram, as I
have no idea what it uses for authorization)

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 08 Mar 2014 10:25:57 -0500

> resource. Or it might obtain one from a constrained authz server too.

1) can we all agree that when you write "100% constrained case", what you
   mean is that all clients and servers can speak CoAP/DTLS, not that
   all nodes are constrainted.
   (In particular that the authz server is not constrained)

2) while I need to re-read the charter (and I can not yet do that from
   the airplane), what I would like to suggest is the following:

   a) that we come up with a protocol that works for where there are no
      proxies to/from CoAP, and that OAUTH2/Kerberos/etc. interoperation
      is out of scope (initially).

   b) that before we claim the protocol is baked in any important way,
      that we, as a WG milestone, do an analysis of proxy interaction,
      and either fix the protocol (if we can), or make that scenario
      out of scope.
      We may have to add MTI pieces to make things work.
      Running code would be good to have at this point.
      
What I don't want to do is to fall into some trap where we had what
would been a simple and elegant protocol start it's life ugly.
While we might decide to make it ugly, it should be a conscious choice.

-- 
Michael Richardson
-on the road-

---

From: Göran Selander <[email-masked]>
Date: Mon, 10 Mar 2014 05:55:05 +0000

Hi Phil

On 07/03/14 14:51, "Phil Hunt" <[email-masked]> wrote:

>Agreed. However I can see cases where RS and authz are both constrained
>because they are on same server. In this case i would suspect "policy" is
>largely driven by basic func of the device.
>

I would like to see the AS as optional functionality, in cases where the
RS does not have the authz info it requires to decide on grant or deny an
access request. In use cases where it suffices with configured access
policies in the RS (corresponding to what you call “basic fund”?) there is
no need for an AS at all.

With this in mind I would like to assume that the AS, when present, is not
a constrained device. Does that make sense or are there still other
options to consider?

Thanks
Göran

---

From: Göran Selander <[email-masked]>
Date: Mon, 10 Mar 2014 09:00:42 +0000

Hi Michael

Just on untrusted intermediaries:

Since the AS needs to protect certain information end-to-end ‹  e.g.
authorisation information to be consumed by the RS, key management
information to be consumed by the Client ‹ hop-by-hop transport layer
security would not be sufficient. This case could be handled with object
secure information (some sort of ticket/access token) integrity protected
or encrypted on application layer. As the secure object can't be changed
by an intermediary, it need to be formatted for transfer to the intended
consumer already by the AS, which in particular may need to take into
account a constrained environment.

Göran

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 10 Mar 2014 07:05:08 -0400

I am thinking that we should design/select an authentication and authorization solution that is suitable for the situation where interface II is using CoAP/DTLS.  The solution should work well the Client communicates to the Resource Server using CoAP/DTLS.  It should also work well when the Resource Server is a constrained node, the Client is a constrained node, or both the Resource Server and Client are constrained nodes.

I do not think that we should assume that interface I or III will use CoAP/DTLS, just that the protocols used on those interfaces should be chosen or designed to be complementary with CoAP/DTLS.  One example might be RADIUS with a new EAP Method that uses DTLS (similar to the current TEAP method's use of TLS) and a profile that limits the required crypto algorithms to those that are already required for CoAP/DTLS.   Another example could be a constrained Kerberos profile that restricts the encryption algorithms available to the list that is required for CoAP/DTLS.  I don't know how to give the same sort of example for PKI or OAUTH solutions, but they probably exist.

I think that requiring CoAP/DTLS to be used on interface I or III overly constrains the situation and effectively requires us to create anew authorization and authentication protocol.  I think we should avoid doing that, if at all possible.

Please note that implementing CoAP/DTLS on the Client and Resource Server  DOES NOT PREVENT those nodes from ALSO implementing other protocols.  For instance an unconstrained Client, such as a building control unit, may implement CoAP/DTLS (plus whatever auth solution we choose/design) to talk to sensors and actuators AND provide a standard HTTP/TLS web server as a northbound interface for users to control the building from anywhere on the Internet.  In my thoughts, we would be expecting the Client and Server to _at least_ implement CoAP/DTLS.  They could also implement other protocols, depending on how resource constrained they are (or aren't).

Margaret

---

From: Phil Hunt <[email-masked]>
Date: Mon, 10 Mar 2014 15:33:44 +0000

I agree. Though while the AS might not actually be constrained, both the client and resource may well be.

That would mean the AS has to support CoAP/DTLS correct?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Zach Shelby <[email-masked]>
Date: Mon, 10 Mar 2014 08:48:43 -0700

> I agree. Though while the AS might not actually be constrained, both the client and resource may well be.

That is correct. And the client and resource might be deep in a challenging 6LoWPAN NAN network with 1000s of nodes sharing a 250 kbps channel (many Smart City related applications).  In those kinds of deployments communication with the AS really needs to be efficient.

> That would mean the AS has to support CoAP/DTLS correct?

Yes. Although there will be non-constrained devices and less challenging networks where HTTP/TLS would be just fine.

Zach

Zach Shelby
Director of Technology

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Mar 2014 21:02:42 -0400

Margaret Wasserman <[email-masked]> wrote:
    > I think that requiring CoAP/DTLS to be used on interface I or III
    > overly constrains the situation and effectively requires us to create
    > anew authorization and authentication protocol.  I think we should
    > avoid doing that, if at all possible.

How would you feel if CoAP/DTLS was a MAY for I/III, but that HTTP/TLS was
also a MAY?

(Perhaps both are MTI, but the I/III interaction MAY use either)

    > Please note that implementing CoAP/DTLS on the Client and Resource
    > Server  DOES NOT PREVENT those nodes from ALSO implementing other
    > protocols.  For instance an unconstrained Client, such as a building
    > control unit, may implement CoAP/DTLS (plus whatever auth solution we
    > choose/design) to talk to sensors and actuators AND provide a standard
    > HTTP/TLS web server as a northbound interface for users to control the
    > building from anywhere on the Internet.  In my thoughts, we would be
    > expecting the Client and Server to _at least_ implement CoAP/DTLS.
    > They could also implement other protocols, depending on how resource
    > constrained they are (or aren't).

Agreed...

Or to put it another way: It's okay if my coffee maker also makes toast.
As long as it makes coffee.

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

---

From: Robert Cragie <[email-masked]>
Date: Tue, 11 Mar 2014 20:06:23 +0000

My view is generally that interface II will typically be CoAP/DTLS but 
could easily be HTTP/TLS and from the point of view of provisioning 
credentials and access right information, I can't see there would be a 
huge difference.

I am ambivalent regarding I and III from a 
transfer/transaction/transport protocol point of view but I echo Göran's 
view on considering object security to achieve end-to-end security 
through proxies, plus it would of course still work if directly 
connected. An alternative approach which could be considered for proxies 
is the ability to tunnel through proxies. This might be useful for 
reusing existing auth/z protocols through proxies.

Robert

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Mar 2014 20:42:40 +0100

Goeran, Robert,

Here is the challenge (based on my experience from OAuth):

1) You need to tie the application layer security to the channel
security since otherwise you introduce attacks.

2) You need to tie the application layer security to the actual request.
Doing protocol translation in-between makes this somewhat challenging.

My fear is that while it sounds like a nice idea to do this protocol
translation it makes the entire security story brittle and more complex.

I am fine with investigating these proxy cases but we shouldn't be
astonished if they do not work in the way we had hoped.

Ciao
Hannes

PS: The term 'trusted' and 'untrusted' intermediary is somewhat fuzzy.
As I stated earlier this year on this mailing list, you have to indicate
WHO trust WHOM for WHAT.

---

From: Sandeep Kumar <[email-masked]>
Date: Wed, 12 Mar 2014 16:59:04 +0100

Hi Hannes

> security since otherwise you introduce attacks.
Are you referring to the authorization tokens being tied to the (DTLS)
channel rather than to the device identity.
Can you clarify what you mean by the above statement and what attacks are
you referring to?

regards
Sandeep

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Mar 2014 21:14:54 +0100

This might be a bit too much into the solution space but in this
specific case you might recall that some deployments either use TLS
proxies that do a MITM (enterprise networks etc.) or terminate TLS
servers at the edge of the network. Without TLS end-to-end you obviously
don't get the security benefits from it at the application layer.

Ciao
Hannes

On 03/12/2014 04:59 PM, Sandeep Kumar wrote:
> Hi Hannes
> 
> 
> On Tue, Mar 11, 2014 at 8:42 PM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Can you clarify what you mean by the above statement and what attacks
> are you referring to?
> 
> regards
> Sandeep

---

From: Robert Cragie <[email-masked]>
Date: Fri, 14 Mar 2014 10:57:40 +0000

Hi Hannes,

Comments inline.

Robert

> security since otherwise you introduce attacks.
<RCC>Yes, if you are relying on the security properties of the channel. 
A proxy is a MITM so I would imagine in that case, that reliance cannot 
be assumed therefore application layer/object security would need to 
provide its own end-to-end protection</RCC>
> Doing protocol translation in-between makes this somewhat challenging.
<RCC>Agreed; I would not expect translation to occur</RCC>
> astonished if they do not work in the way we had hoped.
<RCC>
Agreed. My understanding of Göran's concept of "object security" is that 
there is no translation at the application layer. This certainly 
complicates the model, as there are now layers within layers but I have 
come across this situation a number of times and has to find a solution 
for it.

Maybe it is not necessary to consider these cases in detail from the 
get-go but simply to bear them in mind when it comes to developing 
solutions.
</RCC>