Re: Google Docs as capabilities as data

Hi Alan,
I agree that the credential sharing risk exists; in contexts like the ones we address 
with the Event Notification Service there are formal constraints (company policies) 
that come into play and reduce that risk (or at least have the guy sharing is 
credentials liable for infringing the company rules).

In other contexts a "plese don't delegate flag" could be more effective.
Reagrding the revocation procedure we follow the check is not so "simple"; indeed 
don't forget that our mechanism is completely distributed and there could be 
situaitons in which the PDP doesn't have all the information required to check if the 
revocation request is acceptable or not.
Suppose for example that Alice has granted Bob the right X on resource Y and also 
the right to further grant right X. Then that Bob has granted Carol rights creating a 
token for Carol based on his capability token, ...
Alice doesn't have visibility (unless Bob, Carol, ... don't inform her) of the capability 
tokens beneath the Bob's one, nor she has copies of these tokens.
Now Alice wants to revoke Bob's token and all the ones descendent from this one; 
she knows the ID of Bob's token only and a copy Bob's token (if she has maintained 
copy of it). She creates a revocation request specifying she wants to revoke Bob's 
token and all its descenndents.
On the PDP side (let's treat the Revocation Service just as an additional service of 
the PDP!) if Bob's token and descented ones have never been used to access the 
resource Y, the PDP doesn't have the possibility to ascertain if Alice's request must 
be accepted or not and must defer the processing until it receives resoruce access 
requests from Bob or one of the descendent subjects.
At that time the PDP receives all information to complete the revocation process.
We implemented the Revocation Service has a distinct service for convenience (so to 
reduce the load on the PDP), but logically it can be considered as exposing a further 
API/service of the PDP.
Ciao
   Domenico



On 31 Jan 2014 at 5:28, Karp, Alan H wrote:

    Domenico Rotondi wrote:
     
èAttemptingto prevent re-delegation is both futile and counterproductive.  It is futile 
    because people can and do share credentials.  It is counterproductive because when 
    they share credentials, you lose accountability.  Further, you force them to give up 
    all their permissions in order to share a few of them.  I am now proposing that the 
    Do Not Delegate flag be treated as a warning to indicate “Please do not delegate.” 
      In an enterprise setting, the employee will be informed that continuing with the 
    delegation would violate policy and be given the chance to provide a justification for 
    management.
     
    Our delegation system doesn't force a subject to delegate all his/her rights. When 
    you create a new token based on the one you own you can select which of the 
    rights hou have (and for which you are also allowed to delegate) you actually 
    grant to the other subject. Therefore if, for example, I have both read and write 
    rights for resource X and I have the delegate right only for the read operation I 
    can only grant you the read right to you creating a new token (actually the 
    schema file we use supports also a delegation depth attribute, but this attribute is 
    not currently accessible via the UI of our tool).
     
    Sorry.  I didn’t make myself very clear.  Of course, any properly designed capability 
    system, such as yours, will allow fine-grained, attenuated re-delegation.  However, if 
    you  block re-delegation, people will share credentials.  That’s when they end up 
    sharing all their rights.
     
    Therefore we have a "can delegate" flag for each granted right. If you don't want 
    a subject delegates received rights, simply don't set this flag in his/her capability 
    token.
    Regarding the sharing of credentials. We use X509 certificates and digital 
    signatures to protect the tokens (and as a proof of ownership when submitting an 
    access request). So users have to share their private keys if they want to share a 
    capability.
    We know this issue exists, but: first the owner of the X509 in any case remains 
    accountable for his/her private key, and he/she's violating company policies 
    (don't forget that the context of our system is to do access control to shop floor 
    events in manufacturing).
     
    If you do set that flag, people may not be able to get their jobs done.  When that happens, 
    they will share their private keys, company policy notwithstanding.  Credential sharing in 
    systems that make (re-)delegation hard is such a problem that Ping Identity runs a webinar 
    on it.
     
èWehave a PDP (Policy Decision Point) and a PEP (which actually is the 
    Authorization Service of the pub/sub system). So each request is first locally 
    checked by the Authorization Service (e.g., if the capability token is 
    acceptable, the request is compliant to the capability token, ...); then the 
    Authorizaiton Server asks the PDP for further checks (currently only if the 
    capability token is reported as revoked or not).
    We designed the Revocation Service to manage revocation requests and, if 
    the revocation has to be performed, report this to the PDP and to the subject 
    that reuqested the revocation (this "report" could be deferred in time due the 
    decentralised nature of our system; so the Revocaiton Serivce/PDP could not 
    have all the info for immediately taking a decision if a capability token must 
    be revoked or not).
     
    I just think it’s simpler to send the revocation request directly to the PDP.  (Actually,  the 
    check is simple enough, you can even do it in the PEP.)
     
    ________________________
    Alan Karp
    Principal Scientist
    Enterprise Services, Office of the CTO
    Hewlett-Packard Company
    1501 Page Mill Road
    Palo Alto, CA 94304
    (650) 857-3967, fax (650) 857-7029
    http://www.hpl.hp.com/personal/Alan_Karp

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk