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

From: "Kepeng Li" <[email-masked]>
Date: Fri, 28 Mar 2014 22:41:12 +0800

> I don¹t think we need to come to a conclusion in this discussion to agree on the charter. 

Good!

>We don¹t even need to mention proxy in the charter as long as we agree to allow this to impact the requirements.

I think yes, this was mentioned in Hannes' summary already.

Kepeng

------------------ 原始邮件 ------------------
发件人: "G��ran Selande" <[email-masked]>;
发送时间: 2014年3月28日(星期五) 22:02
收件人: "Klaus Hartke" <[email-masked]>;"Kepeng Li" <[email-masked]>;
抄送: "[email-masked]" <[email-masked]>;
主题: Re: [Ace] Summary of the Proxy Discussion

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: 
 
>G��ran Selander wrote: 
>>>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 
>> 
>> The resource host (origin server) and the client mutually authenticates 
>> 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. 
> 
>>>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 
>> 
>> 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. 
> 
>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. 
 
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. 
 
> 
>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. 
 
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. 
 
> 
>>>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 
>> 
>> In this case, the forward proxy and client mutually authenticates and 
>> establish secure connection, as does forward proxy and resource host 
>> (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 
>> 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. 
 
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 

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

---

From: "Kepeng Li" <[email-masked]>
Date: Fri, 28 Mar 2014 22:41:12 +0800

Good!

Kepeng

------------------ 原始邮件 ------------------
发件人: "G��ran Selande" <[email-masked]>;
发送时间: 2014年3月28日(星期五) 22:02
收件人: "Klaus Hartke" <[email-masked]>;"Kepeng Li" <[email-masked]>;
抄送: "[email-masked]" <[email-masked]>;
主题: Re: [Ace] Summary of the Proxy Discussion

Hi Klaus, Keeping 

 
G��ran 

 

 

 
G��ran