Re: [Ace] Questions for the IETF#90 Meeting

[Ludwig Seitz <[e-mail]>]

On 07/11/2014 12:56 AM, Paul Lambert wrote:
>
> Hannes,
>
>> On 07/09/2014 11:52 PM, Paul Lambert wrote:
>>> Wireless (e.g. Wi-Fi ) based direct connections from one device to another.
>>> - between two smart phones
>>> - smart phone to headless device (e.g. hot water heater)
>>> Typically no Internet connection guaranteed to be available.
>>
>> As currently described in the use cases an initial interaction between
>> the client and the authorization server would be needed to get the
>> protocol interaction working.
> Thank you for the clarification … that makes sense now rereading.
>
> I do have fundamental problems with the overall server centric
> framework, for example:
>
> "    U4.3.  Devices can access resources on other devices only if a
>        rule exists in the authorization server (default deny)."
> and
> "U4.5.  Devices may cache authorization rules locally.”
>
> I do  not see why a server is required.  The authorization/policy information
> required to make the decision might better be modeled as as
> a functional element in the RS.  The authorization information
> should be available locally to the RS, but could reach out to
> one or more servers in some implementions ions.
>

Citing from draft-seitz-ace-problem-description-01:

    Finally we also assume that in a significant number of cases, the
    server and/or the client are too constrained to handle the
    authorization policies and related configuration on their own.  Many
    authorization solutions involve a centralized, trusted third party,
    supporting the client and/or resource server.  A trusted third party
    provides a more scalable way to centrally manage authorization
    policies, in order to ensure consistent authorization decisions.  The
    physical separation of policy decision and policy enforcement is an
    established principle in policy based management, e.g. [RFC2748].


To be a bit more specific:

* In many cases evaluating authorization policies (not simple ACLs) will 
require network lookups (e.g. checking client attributes in an identity 
provider database). This kind of processing is too expensive for 
constrained devices in terms of delay time and, for battery powered 
devices, energy consumption.

* You typically want to manage authorization policies centrally in order 
to keep a consistent picture of their current state.

* You also typically want to centralize authorization decisions in order 
to generate complete audit logs.

* If authorization policies change frequently you want to avoid having 
to provision each of these updates to all the affected resource servers.

Note the separation of policy decisions and policy enforcement here. The 
Authorization Server is expected to do decisions, while the RS does 
enforcement.

I hope that clarifies things a bit.

/Ludwig


-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone [phone]
http://www.sics.se