Subject: Re: [Ace] Summary of the Proxy Discussion

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 02 Apr 2014 11:38:00 +0200

Hi Klaus,

thanks for the detailed response.

A few remarks below.

On 03/25/2014 03:48 PM, Klaus Hartke wrote:
> 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
> 

Here is don't see a problem since there is no proxy involved.

> 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

I don't see a problem here either since the client assumes that it is
talking to example.org. I have seen these reverse proxies in many server
deployments as load balancers and accelerators.

This, of course, assumes that the example.org and the example.net are in
the same administrative domain and that the client is indeed configured
to talk to example.org (rather than example.net).

> 
> 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

If the client assumes that it wants to talk to example.org and suddenly
it sees a certificate with proxy.example then the exchange will fail.
There is a secret sauce somewhere here.

How do you expect the security of this to work?

> 
> 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

This is not supported in CoAP, which is unfortunate.

Ciao
Hannes

> 
> Does that answer your questions?
> 
> Klaus
> 
> 
> On 25 March 2014 09:47, Hannes Tschofenig <[email-masked]> wrote:
>> Hi Klaus,
>>
>> thanks for the description. Since I am not sure I understood it
>> correctly I have a couple of basic questions.
>>
>> On 03/24/2014 08:50 PM, Klaus Hartke wrote:
>>> 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_.
>>
>> 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.
>>> 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.)
>>
>> 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
>>
>>
>>>
>>> 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
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 02 Apr 2014 11:40:04 +0200

Hi Michael,

a few remarks below.

On 03/25/2014 09:11 PM, Michael Richardson wrote:
> 
> I'm going to keep just the step two, because it's where the differences are.
> 
> Klaus Hartke <[email-masked]> wrote:
> 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!)
> 

This will not work with DTLS unless you run a man-in-the-middle attack
against it (by the CA trick or if example.org shares its long-term
credentials with proxy.example).

> 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 think that this example is indeed really similar to the reverse proxy,
particularly if the translation gateway is operated by the same party as
the actual example.com HTTP server.

> 
> 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.

For the translation gateway case to work seamlessly end-to-end across
protocol boundaries, I agree with your statement. But for the reverse
proxy case that might not even be desired since one argument for using
reverse proxies it to terminate security early at the edge.

Ciao
Hannes

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Apr 2014 08:56:17 -0400

> deployments as load balancers and accelerators.

Yes, it is common,although with the availability of wildcard
certificates, and/or useful/affordable intermediate CA certificates some
banks/etc now redirect you from the main login page to www123234.example.com.
This has significant scalability and geo-diversity advantages, and
cryptographically means one can sometimes avoid sharing private keys.

    > to talk to example.org (rather than example.net).

That was an assumption between example being the same org.
(Clearly we need a few more example domains...)

    > How do you expect the security of this to work?

local configuration override.
same as you might set $http_proxy or set you browser's proxies.

    > This is not supported in CoAP, which is unfortunate.

true. 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Apr 2014 09:03:20 -0400

see inline

    > credentials with proxy.example).

Agreed.  PHB's omnibroker idea deals with some of the trust issues that
ensue...  

    > the actual example.com HTTP server.

It is very similar, and there would have to be a relationship; but not
necessarily a close one if we do our work right.  The operator of the
interception device might be the "ISP" for the IoT service (think ISP
supplied home router), but the devices are owned by, for instance, the home
owner.  The home owner does not with to share private keys on the one hand
(they don't want to lock themselves into a single vendor!), on the other
hand, they don't want to handle all of the authorization processing
themselves.

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 3 Apr 2014 17:15:57 +0200

> deployments as load balancers and accelerators.

With respect to authorization, it might be useful to separate between
two kinds of reverse proxies: those that have knowledge of which
actions a client is authorized to perform on which resources, and
those that don't.

Example 2a: Client---Reverse Proxy *with* authorization
knowledge[example.org]---Origin Server[internal.example.org]

1. The client establishes a secure connection to example.org
2. The client requests a representation of the resource /path/to/resource
3. The reverse proxy checks if the client is authorized to obtain
    a representation of the resource /path/to/resource
4. The reverse proxy chooses to satisfy the request by obtaining the
    representation of {coaps,https}://internal.example.org/path/to/resource
    a. The reverse proxy establishes a secure connection to
        internal.example.org
    b. The reverse proxy requests a representation of the resource
        /path/to/resource
    c. The origin server satisfies the request by serving a local file
        to the reverse proxy
5. The reverse proxies serves the representation to the client

Example 2b: Client---Reverse Proxy *without* authorization
knowledge[example.org]---Origin Server[internal.example.org]

1. The client 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}://internal.example.org/path/to/resource
    on behalf of the client
    a. The reverse proxy establishes a secure connection
        to internal.example.org
    b. The reverse proxy requests a representation of the resource
        /path/to/resource, indicating that it's acting _on behalf of the
        client_
    c. The origin server checks if the _client_ is authorized to obtain
        a representation of the resource /path/to/resource (even though
        it is the reverse proxy that is requesting the representation)
    d. 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

> How do you expect the security of this to work?

If the client assumes that it wants to talk to example.org and
suddenly it sees a certificate with proxy.example, then we're talking
about an interception proxy/transparent proxy/captive portal, not a
forward proxy. A forward proxy is knowingly selected by a client,
usually via local configuration rules, to perform requests on behalf
of the client.

Let me make the example more explicit:

0. The client is configured to use the forward proxy
    coaps://proxy.example:1234/
1. Because the client is configured to use a forward proxy, instead of
    securely connecting to example.org and expecting a certificate for
    example.org, it securely connects to proxy.example:1234 and expects
    a certificate for proxy.example
2. The client requests the forward proxy to return a representation of the
    resource coaps://example.org/path/to/resource over the secure connection
    Note that this is an interaction between the client and the forward proxy,
    not between the client and the origin server through the forward proxy.
3. The forward proxy satisfies the request by obtaining the representation of
    coaps://example.org/path/to/resource
    a. The forward proxy securely connects to example.org and expects a
        certificate for example.org
    b. The forward proxy requests a representation of the resource
        /path/to/resource. Note that this is an interaction between the
        forward proxy and the origin server, not between the client and
        the origin server through the forward proxy.
    c. The origin server satisfies the request by serving a local file to
        the forward proxy
4. The forward proxy returns the representation to the client

So the interaction between the client and the forward proxy on the one
hand and the interaction between the forward proxy and the origin
server on the other hand are both secured. But there is no end-to-end
security between the client and the origin server.

Klaus