Subject: [Ace] Summary of the Proxy Discussion

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Mar 2014 00:06:15 +0100

Hi all,

based on the feedback at the BOF we concluded that proxies should be
part of the WG investigation. What wasn't clear was when an
investigation should be conducted.

I am not sure how to interpret the lack of feedback.

I was hoping to get feedback from folks working in the CORE working
group on how they thought proxies work in combination with DTLS but no
feedback was provided.

I hope that Akbar and Phil provide a more detailed contribution as part
of the use case/requirements discussion.

I am currently inclined not to include text that states explicitly when
the proxy topic will be decided.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Mar 2014 22:00:08 -0400

> investigation should be conducted.

When you say proxies, I think you are talking about things which the
end points are aware of (and may have to trust).  It would include, but not
be limited to, CoAP/HTTP translators. (Well. CoAP-DTLS/HTTPS!)

Would we agree that the proxies are not transparent?

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Mar 2014 06:52:18 +0100

> On 24.03.2014, at 00:06, Hannes Tschofenig <[email-masked]> wrote:
> 
> the proxy topic

I don't know what that is. There are proxy-like instances in the Berlin model. Various kinds of Proxies with various security roles could also be inserted at various places.  Inserting proxies with no defined security everywhere just means that DTLS becomes less useful or has to be transported over the proxies.  

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Mar 2014 01:21:36 +0100

Hi Michael,

> be limited to, CoAP/HTTP translators. (Well. CoAP-DTLS/HTTPS!)

During the discussions on the list I had to noticed that folks had
different use cases in mind. One was about protocol translation but
there are also cases that have nothing to do with protocol translation
but rather with the use of CoAP itself and how some seem to have assumed
how it works.

> Would we agree that the proxies are not transparent?

Transparency is a fuzzy term here.

Is a protocol translator transparent of not and the question is to whom
is it transparent?

I believe I am saying that we all have not thought about the proxy topic
enough to make a conclusion that could go into the charter and for that
reason I am trying to encourage those who have expertise in this field
to make contributions as early as possible.

Ciao
Hannes

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

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 24 Mar 2014 09:27:36 +0100

> Would we agree that the proxies are not transparent?

Yes! They break end-to-end security, if authentication is based on DTLS.

/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: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Mar 2014 01:27:31 +0100

Hi Carsten,

at the BOF we had suggestions to investigate the ability to have proxies
for protocol translation (as documented in
http://www.ietf.org/proceedings/89/minutes/minutes-89-ace).

Then, following the meeting we had discussions on the list about how
plain CoAP proxies fit into the DTLS security model (see
http://www.ietf.org/mail-archive/web/ace/current/msg00153.html).

I was hoping that you and other CORE WG persons would provide input on
the latter aspect.

As I mentioned in my other mail I believe we need further input from
those who care about various forms of proxies as early as possible.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Mar 2014 12:11:32 +0100

Hi Ludwig,

> Yes! They break end-to-end security, if authentication is based on DTLS.

The question for me is whether the CORE working group had thought about
the use of DTLS with CoAP proxies where the DTLS exchange intentionally
terminates at the proxy. Of course, the term "end-to-end" has a
different meaning there since the end in that case is the proxy rather
than the final destination, such as a Web server.

Maybe we will come to the conclusion that proxies are not inline with
the desired security properties. More investigation will be needed but
from a charter point of view I think we shouldn't add text to the
charter about it; it appears to be premature and at a too detailed level.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Mar 2014 08:25:47 -0400

> Is a protocol translator transparent of not and the question is to whom

Absent security, one can build a MITM translator that turns CoAP into HTTP,
maintaining what is essentially a 1:1 NAT (not NAPT).   That's a transparent
proxy: one which only end to end security will notice.

SIP proxies are not transparent.

    > to make contributions as early as possible.

We have to include
  1) non-transparent proxies in the model, for the same reasons it useful
     for SIP.  We need to define how to trust them, and what they do with
     the authorization tokens.  It must be possible to observe the presence
     of the proxy for audit purposes, and I would not have to give them
     superuser.

  2) a mechanism for what would otherwise appear to be a MITM transparent
     proxy to make itself known.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Mar 2014 16:46:16 +0100

Hi Michael,

I agree that someone should look at this and I am curious who would be
doing that.

Maybe the CORE working group would be a good place since they are
dealing with proxies in general already (e.g., mirror server, sleeping
proxy).

Maybe it is best done in this group (since there is this security focus).

What is your take? Would you want to work on this topic?

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Mar 2014 13:47:03 -0400

> What is your take? Would you want to work on this topic?

I believe that it must be done in ACE, because, when providing any kind of
auhorization token, it may be necessary to provide pieces of it to the proxy
as well.

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 24 Mar 2014 20:50:06 +0100

CoAP provides two (syntactically different) ways for a client (or
intermediary in the role of a client) to perform a request:
(I'm using representation retrieval as example WOLOG.)

A.) the client requests a remote endpoint to return a representation
of a resource located _in that endpoint's namespace_.

B.) the client requests a remote endpoint to return a representation
of a resource located _in another endpoint's namespace_.

In both cases, it's generally up to the remote endpoint how it obtains
the representation of the target resource, as long as the result *is*
a representation of the target resource.
For example, in A., the remote endpoint can serve a local file (the
endpoint is then typically called a "server"), return the output of a
CGI script ("CGI gateway"), obtain the representation from an HTTP
server ("cross-protocol proxy"), or obtain the representation from
another CoAP remote endpoint ("reverse proxy"). In B., the remote
endpoint is generally expected to obtain the representation by
requesting it from the endpoint specified in the request URI ("forward
proxy").

In both cases, the client has no way to verify that the obtained
result is indeed a representation of the target resource. It must
trust the remote endpoint that it returns the correct representation.
DTLS just secures the transmission of the representation from the
remote endpoint to the client.

(AFAIK, HTTP works exactly the same way.)

So, I would say that

- ACE should consider forward proxies, reverse proxies and potentially
cross-protocol proxies such that one of these can obtain a
representation of a resource that a client is authorized to access on
behalf of that client; and

- ACE should not consider remote endpoints that cannot be trusted to
correctly return a representation of a target resource (as this
concerns the general security of CoAP which should be addressed in
CoRE).

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 24 Mar 2014 22:41:13 +0100

> (AFAIK, HTTP works exactly the same way.)

I forgot that HTTP has tunnels [1]. CoAP doesn't have tunnels.

Klaus

[1]  http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#page-10

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Mar 2014 06:52:01 +0100

... But it would not be hard to add them if there is a point.

https://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-A.6 shows a stateful way. 
Or http://tools.ietf.org/html/draft-schmertmann-dice-codtls-00 could be extended to also carry data. 

For coap-to-coap, we didn't add these as so far nobody saw a point. Maybe there is one for cross-proxying. But, as Hannes said, we need to understand the use cases first.

Grüße, Carsten 

> On 24.03.2014, at 22:41, Klaus Hartke <[email-masked]> wrote:
> 
> CoAP doesn't have tunnels.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Mar 2014 09:47:38 +0100

Hi Klaus,

thanks for the description. Since I am not sure I understood it
correctly I have a couple of basic questions.

> of a resource located _in another endpoint's namespace_.

The client device will start with a specific FQDN and will start a DTLS
handshake with that server. Where does the "requests a remote endpoint
to return ...." come into the play?

> (AFAIK, HTTP works exactly the same way.)

In the HTTPS case the story is as follows:

* The client contacts the server behind a https://www.ietf.org (after
doing a DNS look-up) using TLS.

* It gets the cert from the server.

* The client compares the content of the cert with what it had initially
requested to ensure it talks to the right server.

The TLS will prevent any proxy along the path to cache the data (since
it is encrypted).

So, I am not sure how this compares to CoAP based on your description.

Ciao
Hannes

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 25 Mar 2014 15:48:07 +0100

Hi Hannes,

here are a few examples. In each example, the client wants to obtain a
representation of {coaps,https}://example.org/path/to/resource. All
examples work for both CoAP and HTTP, except for the last which only
works for HTTP.

Example 1: Client---Origin Server[example.org]

1. The client resolves and establishes a secure connection to example.org
2. The client requests a representation of the resource
    /path/to/resource by sending a GET request message
3. The origin server satisfies the request by serving a local file to the client

Example 2: Client---Reverse Proxy[example.org]---Origin Server[example.net]

1. The client resolves and establishes a secure connection to example.org
2. The client requests a representation of the resource /path/to/resource
3. The reverse proxy chooses to satisfy the request by obtaining the
    representation of {coaps,https}://example.net/some/other/resource
    a. The reverse proxy resolves and establishes a secure connection
        to example.net
    b. The reverse proxy requests a representation of the resource
        /some/other/resource
    c. The origin server satisfies the request by serving a local file
        to the reverse proxy
4. The reverse proxies serves the representation to the client

Example 3: Client---Forward Proxy[proxy.example]---Origin Server[example.org]

1. The client resolves and establishes a secure connection to proxy.example
2. The client requests a representation of the resource
    {coaps,https}://example.org/path/to/resource
3. The forward proxy satisfies the request by obtaining the
    representation of {coaps,https}://example.org/path/to/resource
    a. The forward proxy resolves and establishes a secure connection
        to example.org
    b. The forward proxy requests a representation of the resource
        /path/to/resource
    c. The origin server satisfies the request by serving a local file
        to the forward proxy
4. The forward proxy serves the representation to the client

Example 4: Client---Tunnel[tunnel.example]---Origin Server[example.org]

1. The client resolves and establishes an unsecured connection to tunnel.example
2. The client requests the tunnel to establish an unsecured connection
    to example.org and to act as a blind relay between the two connections
3. The tunnel satisfies the request by resolving and establishing an
    unsecured connection to example.org
4. The client establishes a secure connection to the origin server
    through the tunnel
5. The client requests a representation of the resource /path/to/resource
6. The origin server satisfies the request by serving a local file to the client

Does that answer your questions?

Klaus

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Mar 2014 16:11:44 -0400

I'm going to keep just the step two, because it's where the differences are.

    >         to example.org and to act as a blind relay between the two

There is a fifth situation which we try never to talk about:

Example 5: Client---TransparentProxy[proxy.example]--Origin Server[example.org]

1. client opens a connection to example.org.
   TCP connection is intercepted (think NAPT, not perpass) by proxy.example.
2. client requests a representation of the resource /path/to/resource
3. proxy.example, connects to real example.org (by IP, which it observed in
   the TCP getsockname()), requests resource, returns it to client.

This is not a blind relay tunnel.  This is how hundreds of firewalls
that do virus scanning whether as a bump in the stack, bump in the cord,
or network device work (for good or bad!)

The relevant situation that I understand, and which I think might want to
support is:

Example 6: Client---HTTP/CoAPProxy[proxy.example]--Origin Server[example.org]

1. client opens a connection to example.org.
   TCP/HTTPS connection is intercepted (think NAPT, not perpass) by
   proxy.example.

2. client requests a representation of the resource /path/to/resource

3. proxy.example, connects to real example.org by CoAP/DTLS
   (by IP, which it observed in the TCP getsockname()),
   requests resource, returns it to client, possibly caching the result.

Note that if assume the real address of example.org is not the same
as the address that the client saw, (which given that v6 has many more
addresses to play with...) then this is really closer to example 2.
It just might be that the reverse proxy has been given an algorithm
to map blahblah::1234 -> hahaha::1234, rather than having every single
one of them preconfigured.

I want to be able to do this securely such that the this man-in-the-middle
is clearly authorized to be in the middle, and with an audit trail that
becomes visible to both client and origin servers.

It's also clear to me that the authorization on the left probably has to
play nicely with OAuth2.

---

From: Likepeng <[email-masked]>
Date: Thu, 27 Mar 2014 02:47:22 +0000

> reason I am trying to encourage those who have expertise in this field to make
> contributions as early as possible.

+1.

I propose that we postpone the proxy topic to the next phase. 

Currently we don’t related drafts and I can't see clear direction about this topic.

Thanks,

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Hannes Tschofenig
> 发送时间: 2014年3月24日 8:22
> 收件人: Michael Richardson
> 抄送: [email-masked]
> 主题: Re: [Ace] Summary of the Proxy Discussion
> 
> Hi Michael,
> 
> > end points are aware of (and may have to trust).  It would include,
> > but not be limited to, CoAP/HTTP translators. (Well. CoAP-DTLS/HTTPS!)
> 
> During the discussions on the list I had to noticed that folks had different use
> cases in mind. One was about protocol translation but there are also cases
> that have nothing to do with protocol translation but rather with the use of
> CoAP itself and how some seem to have assumed how it works.
> 
> >
> Is a protocol translator transparent of not and the question is to whom is it
> transparent?
> 
> reason I am trying to encourage those who have expertise in this field to make
> contributions as early as possible.
> 
> 
> Ciao
> Hannes
> 
> >
> > --

---

From: Göran Selander <[email-masked]>
Date: Thu, 27 Mar 2014 14:02:04 +0000

Hi Klaus

Thanks for these explicit examples. I believe example 3 - the forward
proxy - is different from the others with respect to end-to-end security
between client and requested resource. I think that has an impact on the
solution so we should explicitly consider these examples in the work. See
comments inline.

>3. The origin server satisfies the request by serving a local file to the

The resource host (origin server) and the client mutually authenticates
and protect the request/response using the secure connection.

>4. The reverse proxies serves the representation to the client

In this case, the requested resource, from the point of view of the
client, is hosted by the reverse proxy, between which there can be mutual
authentication and secure connection. Where the reverse proxy gets a
representation from is out of scope of the client.

>4. The forward proxy serves the representation to the client

In this case, the forward proxy and client mutually authenticates and
establish secure connection, as does forward proxy and resource host
(origin server). With the mechanisms described in this example, the
resource host does not authenticate the client, so some additional
security is needed for the origin server to enforce an access control
decision or evaluate an access control policy which is bound to a
particular client (or role of client).

There are of course solutions to this problem, but the important thing at
this stage is that forward proxies has an impact on the solution. If we
want to support forward proxies, eventually, then we should not postpone
this to a later phase, because there is a good chance that will require a
completely different solution. I therefore propose that we include support
for the mentioned proxies in the assumptions.

>6. The origin server satisfies the request by serving a local file to the

In this case client and resource host mutually authenticates and
establishes the end-to-end secure connection in step 4. Similar to
examples 1 and 2.

Göran

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 27 Mar 2014 17:00:28 +0100

> and protect the request/response using the secure connection.

And this is probably the most basic solution to authorized resource
access: The origin server can determine for each request if the
authenticated client is authorized to perform the requested action on
the target resource or not.

The important thing to note here is that the origin server is actually
performing three tasks:

(1.) authenticating of the client,
(2.) having knowledge of which actions the _authenticated_ client is
authorized to perform on which resources, and
(3.) performing the action requested by an _authorized_ client on a resource.

If the origin server is too constrained to perform all these tasks,
the idea is to off-load some of them (1. and 2.) to a less constrained
third party.

Then there must be a standard way for the client to (A.) securely
discover the third party, (B.) perform steps to first become an
authenticated client and then an authorized client, and finally (C.)
to make a request as an authorized (but not necessarily authenticated)
client.

> representation from is out of scope of the client.

It may be the origin server [example.net], though, which has the
knowledge of which actions the client (which authenticated to the
reverse proxy [example.org]) is authorized to perform on which
resources. The reverse proxy could merely act as a simple cache in
front of the origin server.

So there must be (D.) a standard way for the reverse proxy to make
requests to the origin server on behalf of an authorized client.

> (origin server).

It is noteworthy here that the client can only request the forward
proxy to make its request to the origin server securely (by specifying
the "coaps" scheme). It has no influence on acceptable cipher suits,
certificate roots, etc. The client has to trust the forward proxy that
it secures the connection to the origin server in a way that is
acceptable to the client.

> With the mechanisms described in this example, the

So there must be (E.) a standard way for the forward proxy to make
requests to the origin server on behalf of an authorized client.

Klaus

---

From: Likepeng <[email-masked]>
Date: Fri, 28 Mar 2014 06:52:36 +0000

> Then there must be a standard way for the client to
>(A.) securely discover the third party, 
>(B.) perform steps to first become an authenticated client and then an authorized client, 
>(C.) to make a request as an authorized (but not necessarily authenticated) client.

These three requirements should be already there, even without proxy.

> So there must be (D.) a standard way for the reverse proxy to make requests to the origin server on behalf of an authorized client.
> So there must be (E.) a standard way for the forward proxy to make requests to the origin server on behalf of an authorized client.

In my understanding, these two requirements should not impact our basic solution (no proxy involved). 

We can define our basic solution (no proxy involved) in the first stage, and define extended solution (with proxy involved) in the second stage.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Klaus Hartke
> 发送时间: 2014年3月28日 0:00
> 收件人: [email-masked]
> >>1. The client resolves and establishes a secure connection to
> >>example.org 2. The client requests a representation of the resource
> >>    /path/to/resource by sending a GET request message 3. The origin
> >>server satisfies the request by serving a local file to the client
> >
> > The resource host (origin server) and the client mutually
> > authenticates and protect the request/response using the secure
> connection.
> 
> access: The origin server can determine for each request if the authenticated
> client is authorized to perform the requested action on the target resource or
> not.
> 
> If the origin server is too constrained to perform all these tasks, the idea is to
> off-load some of them (1. and 2.) to a less constrained third party.
> 
> Then there must be a standard way for the client to (A.) securely discover the
> third party, (B.) perform steps to first become an authenticated client and
> then an authorized client, and finally (C.) to make a request as an authorized
> (but not necessarily authenticated) client.
> 
> >>1. The client resolves and establishes a secure connection to
> >>example.org 2. The client requests a representation of the resource
> >>/path/to/resource 3. The reverse proxy chooses to satisfy the request by
> obtaining the
> > client, is hosted by the reverse proxy, between which there can be
> > mutual authentication and secure connection. Where the reverse proxy
> > gets a representation from is out of scope of the client.
> 
> It may be the origin server [example.net], though, which has the knowledge of
> which actions the client (which authenticated to the reverse proxy
> [example.org]) is authorized to perform on which resources. The reverse proxy
> could merely act as a simple cache in front of the origin server.
> 
> So there must be (D.) a standard way for the reverse proxy to make requests to
> the origin server on behalf of an authorized client.
> 
> >>1. The client resolves and establishes a secure connection to
> >>proxy.example 2. The client requests a representation of the resource
> It is noteworthy here that the client can only request the forward proxy to
> make its request to the origin server securely (by specifying the "coaps"
> scheme). It has no influence on acceptable cipher suits, certificate roots, etc.
> The client has to trust the forward proxy that it secures the connection to the
> origin server in a way that is acceptable to the client.
> 
> > With the mechanisms described in this example, the resource host does
> > not authenticate the client, so some additional security is needed for
> > the origin server to enforce an access control decision or evaluate an
> > access control policy which is bound to a particular client (or role
> > of client).
> 
> So there must be (E.) a standard way for the forward proxy to make requests
> to the origin server on behalf of an authorized client.
> 
> Klaus
>

---

From: Likepeng <[email-masked]>
Date: Fri, 28 Mar 2014 07:29:27 +0000

> There are of course solutions to this problem, but the important thing at this
> stage is that forward proxies has an impact on the solution. If we want to
> support forward proxies, eventually, then we should not postpone this to a
> later phase, because there is a good chance that will require a completely
> different solution. I therefore propose that we include support for the
> mentioned proxies in the assumptions.

I agree that we should consider the requirements for the proxy support when we design our solution. 

But I think it is better to design our solution step by step, in different phases.

My worry is, proxy is quite complex to support, this may delay our progress to finish our basic solution.

Also we don’t have drafts available yet, I am not sure who can lead this work, and how long it will take.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 G?ran Selander
> 发送时间: 2014年3月27日 22:02
> 收件人: Klaus Hartke; [email-masked]
> Thanks for these explicit examples. I believe example 3 - the forward proxy - is
> different from the others with respect to end-to-end security between client
> and requested resource. I think that has an impact on the solution so we
> should explicitly consider these examples in the work. See comments inline.
> 
> 
> The resource host (origin server) and the client mutually authenticates and
> protect the request/response using the secure connection.
> 
> >
> In this case, the requested resource, from the point of view of the client, is
> hosted by the reverse proxy, between which there can be mutual
> In this case, the forward proxy and client mutually authenticates and establish
> secure connection, as does forward proxy and resource host (origin server).
> With the mechanisms described in this example, the resource host does not
> authenticate the client, so some additional security is needed for the origin
> server to enforce an access control decision or evaluate an access control
> policy which is bound to a particular client (or role of client).
> 
> There are of course solutions to this problem, but the important thing at this
> stage is that forward proxies has an impact on the solution. If we want to
> support forward proxies, eventually, then we should not postpone this to a
> later phase, because there is a good chance that will require a completely
> different solution. I therefore propose that we include support for the
> mentioned proxies in the assumptions.
> 
> 
> >
> >1. The client resolves and establishes an unsecured connection to
> >tunnel.example 2. The client requests the tunnel to establish an
> >unsecured connection
> >    to example.org and to act as a blind relay between the two
> >connections 3. The tunnel satisfies the request by resolving and establishing
> an
> >    unsecured connection to example.org 4. The client establishes a
> >secure connection to the origin server
> >    through the tunnel
> >5. The client requests a representation of the resource
> >/path/to/resource 6. The origin server satisfies the request by serving
> >a local file to the client
> 
> In this case client and resource host mutually authenticates and establishes
> the end-to-end secure connection in step 4. Similar to examples 1 and 2.
> 
> 
> Göran
> 
> 
> >
> >> The client device will start with a specific FQDN and will start a
> >> DTLS handshake with that server. Where does the "requests a remote
> >> endpoint to return ...." come into the play?
> >>
> >>
> >>
> >>>
> >>> In both cases, it's generally up to the remote endpoint how it
> >>> obtains the representation of the target resource, as long as the
> >>> result *is* a representation of the target resource.
> >>> endpoint is then typically called a "server"), return the output of
> >>> a CGI script ("CGI gateway"), obtain the representation from an HTTP
> >>> requesting it from the endpoint specified in the request URI
> >>> ("forward proxy").
> >>>
> >> * The client compares the content of the cert with what it had
> >> initially requested to ensure it talks to the right server.
> >>
> >> The TLS will prevent any proxy along the path to cache the data
> >> (since it is encrypted).
> >>
> >>> - ACE should consider forward proxies, reverse proxies and
> >>> potentially cross-protocol proxies such that one of these can obtain
> >>> a representation of a resource that a client is authorized to access
> >>> on behalf of that client; and
> >>>

---

From: Göran Selander <[email-masked]>
Date: Fri, 28 Mar 2014 08:29:34 +0000

Hi Kepeng

>solution (no proxy involved).

I’m afraid they do. Maybe more clear if you formulate the requirement as
"it should be possible for the origin server to authorise a client behind
a forward proxy” etc.

Note that also in DCAF (what Carsten call “the Berlin model”) the
Authentication Manager is another intermediary requesting access on behalf
of a client.

>
>We can define our basic solution (no proxy involved) in the first stage,
>and define extended solution (with proxy involved) in the second stage.

Considering that the extended solution may be a completely different I
think it would be unwise to disregard these cases in a first stage.

Göran

>>authenticated
>>discover the
>>knowledge of
>>requests to
>>proxy to
>>requests

---

From: Göran Selander <[email-masked]>
Date: Fri, 28 Mar 2014 08:32:16 +0000

>work, and how long it will take.

I think the mail exchange is a good start for a problem statement and
tentative requirements (although I don’t exactly agree with the current
formulation). Judging by the enthusiasm of volunteers popping up I don’t
think it will be difficult to find a driver for this work ;-)

Just as a note from a beginner: It is a bit puzzling to me, that on the
one hand side having a draft (as in the example of the use case and
requirements) is a problem and not having a draft (as in the current
example) is also a problem :-)

Göran

>>proxy - is
>>and
>>client, is
>>establish
>>not
>>establishes

---

From: Likepeng <[email-masked]>
Date: Fri, 28 Mar 2014 08:39:29 +0000

>having a draft (as in the example of the use case and requirements) is a problem.

Not really. 

Use cases and requirements draft is a good one. 

In fact, it got a lot of interest, has been referenced several times in the mailing list and help us a lot during the discussion.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Göran Selander [mailto:[email-masked]]
> 发送时间: 2014年3月28日 16:32
> 收件人: Likepeng; Klaus Hartke; [email-masked]
> >> There are of course solutions to this problem, but the important
> >>thing at this  stage is that forward proxies has an impact on the
> >>solution. If we want to  support forward proxies, eventually, then we
> >>should not postpone this to a  later phase, because there is a good
> >>chance that will require a completely  different solution. I therefore
> >>propose that we include support for the  mentioned proxies in the
> >>assumptions.
> >
> I think the mail exchange is a good start for a problem statement and tentative
> requirements (although I don’t exactly agree with the current formulation).
> Judging by the enthusiasm of volunteers popping up I don’t think it will be
> difficult to find a driver for this work ;-)
> 
> Just as a note from a beginner: It is a bit puzzling to me, that on the one hand
> side having a draft (as in the example of the use case and
> >>proxy - is  different from the others with respect to end-to-end
> >>security between client  and requested resource. I think that has an
> >>impact on the solution so we  should explicitly consider these
> >>examples in the work. See comments inline.
> >>
> >>
> >> >here are a few examples. In each example, the client wants to obtain
> >> >a representation of {coaps,https}://example.org/path/to/resource.
> >> >All examples work for both CoAP and HTTP, except for the last which
> >> >only works for HTTP.
> >> >
> >> >/path/to/resource 3. The reverse proxy chooses to satisfy the
> >> >request
> >>by
> >> obtaining the
> >>not  authenticate the client, so some additional security is needed
> >>for the origin  server to enforce an access control decision or
> >>evaluate an access control  policy which is bound to a particular
> >>client (or role of client).
> >>
> >> There are of course solutions to this problem, but the important
> >>thing at this  stage is that forward proxies has an impact on the
> >>solution. If we want to  support forward proxies, eventually, then we
> >>should not postpone this to a  later phase, because there is a good
> >>chance that will require a completely  different solution. I therefore
> >>propose that we include support for the  mentioned proxies in the
> >>assumptions.
> >>
> >>
> >> >
> >> >/path/to/resource 6. The origin server satisfies the request by
> >> >serving a local file to the client
> >>
> >> >On 25 March 2014 09:47, Hannes Tschofenig
> >> ><[email-masked]>
> >> >wrote:
> >> >> Hi Klaus,
> >> >>
> >> >>> A.) the client requests a remote endpoint to return a
> >> >>> representation of a resource located _in that endpoint's namespace_.
> >> >>>
> >> >>> B.) the client requests a remote endpoint to return a
> >> >>> representation of a resource located _in another endpoint's
> namespace_.
> >> >>
> >> >>> For example, in A., the remote endpoint can serve a local file
> >> >>> (the endpoint is then typically called a "server"), return the
> >> >>> output of a CGI script ("CGI gateway"), obtain the representation
> >> >>> from an HTTP server ("cross-protocol proxy"), or obtain the
> >> >>> representation from another CoAP remote endpoint ("reverse
> >> >>> proxy"). In B., the remote endpoint is generally expected to
> >> >>> obtain the representation by requesting it from the endpoint
> >> >>> specified in the request URI ("forward proxy").
> >> >>>
> >> >> * The client contacts the server behind a https://www.ietf.org
> >> >> (after doing a DNS look-up) using TLS.
> >> >>
> >> >>> potentially cross-protocol proxies such that one of these can
> >> >>> obtain a representation of a resource that a client is authorized
> >> >>> to access on behalf of that client; and
> >> >>>
> >> >>> - ACE should not consider remote endpoints that cannot be trusted
> >> >>> to correctly return a representation of a target resource (as
> >> >>> this concerns the general security of CoAP which should be
> >> >>> addressed in CoRE).
> >> >>>
> >> >>> Klaus
> >> >

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Mar 2014 10:07:13 +0100

On 28 Mar 2014, at 09:29, Göran Selander <[email-masked]> wrote:

> DCAF (what Carsten call “the Berlin model”) 

Just to avoid confusion: DCAF is a specific protocol proposal.

Among other things, it was designed to address the requirements that come from the fact that client and server may be relying on different “wiser elders” (less-constrained nodes supporting the highly-constrained nodes in a close relationship).

The model we arrived at in Berlin appears to be the simplest model that reflects this rather fundamental observation.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Fri, 28 Mar 2014 14:02:00 +0000

Hi Klaus, Keeping

Klaus: Good input, I have some comments inline. I didn¹t intend to work on
the requirements here and now, but since you started . . .  The point I
wanted to make was that the proxy cases have an impact on the ACE
requirements, so should be included in the work from the start. I guess
you agree to that?

Kepeng: I don¹t think we need to come to a conclusion in this discussion
to agree on the charter. We don¹t even need to mention proxy in the
charter as long as we agree to allow this to impact the requirements.

Göran

On 27/03/14 17:00, "Klaus Hartke" <[email-masked]> wrote:

>>>example.org
>>>3. The origin server satisfies the request by serving a local file to
>>>the
>>>client
>>
>>>example.org
>>mutual

In your example, the client is requesting access to
example.org/path/to/resource. Do you propose the client should thereby
acquire rights to access example.net/some/other/resource. Should the
clients have rights to access both these resources? Same privileges?
Should the AS keep track of the association? An alternative is that the
reverse proxy has rights to access/subscribe to
example.net/some/other/resource.

>requests to the origin server on behalf of an authorized client.

One alternative interpretation is that it is not ³on behalf², this it the
reverse proxy which in its own rights (=being a reverse proxy) have access
to the origin server. Then D would coincide with any other access request.

>>>proxy.example

Either the forward proxy is authorised to access the requested resource or
it is not. I think one requirement should be that a forward proxy may not
be authorised to access the requested resource. In that case there should
be (E.) a standard way for the origin server to authorise a client behind
a forward proxy without authorising the forward proxy.

Göran

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Mar 2014 14:34:59 -0400

> progress to finish our basic solution.

If we do not state this up-front, then we will wind up either throwing out
the basic solution, or we will hack it up horribly.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 28 Mar 2014 13:03:15 -0700

One of my concerns with a proxy requirement in the charter is that within the OAuth WG and JOSE WG we are working on MAC/HOK tokens that allow for mutual authentication at the application layer.

Not to say whether or not ACE will use OAuth, but with regards to tokens, while constrained environments might prefer to use DTLS for this authn and encryption, I wonder if similar app layer authentication requirements won't come up that block the ability to have "proxy" support.

My gut reaction has been to consider that some endpoints are "dual" TCP/UDP endpoints to allow inter-op between UDP environs and the larger web TCP world.

I would keep the charter somewhat neutral until some initial proposals have been received and the group can better evaluate the best approach.

Phil

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