RE: [xacml] Explanation - Capability model

Title: Explanation - Capability model

Hal - 
It sounds like we are in agreement.

 

I 
believe the thing that is defining of a "capability" policy is not 
that it is conveyed in a bearer token (otherwise, a digital certificate would 
certainly not qualify), but that it is identified with the subject (rather than 
the resource) and describes the things that the subject is "capable" 
of doing.  I have no interest in pursuing this model.  And if all in 
the group feel the same way (as you appear to), then I suggest that we not 
address the capability model in our work.

 

All 
the best.  Tim.

 

-----------------------------------------
Tim Moses
Tel: 
613.270.3183

 

    
-----Original Message-----
From: Hal Lockhart 
    [mailto:]
Sent: Tuesday, October 16, 
    2001 3:28 PM
To: 'Tim Moses'; 'XACML'
Subject: RE: 
    [xacml] Explanation - Capability model

    
 

    
        
-----Original Message-----
From: Tim 
        Moses [mailto:]
Sent: Tuesday, October 
        16, 2001 10:59 AM
To: 'XACML'
Subject: [xacml] 
        Explanation - Capability model

        
Colleagues - A decision request contains (as a minimum) 
        the subject, the resource and the action.  Job one for the PDP is 
        to locate, retrieve and verify the policy appropriate to the decision 
        request.  By "policy" I mean the complete set of rules 
        that must be considered when formulating the decision. 

    
From an XACML perspective, I think we need to first 
    determine the inputs and the model structure and then determine what items 
    must be present. Everyone is tired of hearing me say subject is not 
    required, certainly it could be argued that action is not required, for 
    example, consider a application protocol with only one operation. (http is 
    almost that way since any given page is usually only accessed with a 
    particular operation (e.g. GET) and all operations can perform reads and 
    writes.)

    
 

    
Not withstanding that, I agree with your use of the 
    term policy. 

    
 

    
Certainly the PDP must IDENTIFY the policies that 
    apply to any given decision. It seems to me that whether it must locate, 
    retrieve and verify them seems to me to be implementation specific and not 
    necessarily the concern of XACML.

    
        
We need a way of identifying policies, for two 
        reasons.  Firstly, most mechanisms for locating and retrieving 
        policy will be based on the policy's "name".  I am 
        thinking of LDAP, "The Web", ODBC, etc..  In addition, 
        for security reasons, the PDP must verify that it has retrieved the 
        correct policy for the decision request.  So, it must be 
        verifiable, by examining the policy and the decision request, that it is 
        the right policy for the request.  One way (perhaps the best way) 
        is to name the policies according to the situations to which they 
        apply.  The PDP has to assure itself that the policy was issued by 
        an authority (or authorities) that is (are) competent to set policy for 
        the situation and that it has not been altered, and (furthermore) that 
        the policy's name identifies it with some aspect of the decision 
        request. 

    
I 
    don't understand why you introduce the concept of "naming" 
    policies. My view is that XACML should say, these inputs are used to 
    determine which policies apply. If you want to (for example) concatenate the 
    values, hash the result and use that to create an LDAP query, fine. If you 
    have all the policies hard coded in your PDP, that is fine too. 
    

    
 

    
The means by which a PDP decides to trust a PRP 
    also seems outside of XACML. Certainly we could provide the optional ability 
    to sign policies using XMLdsig, but in many cases other means will be used. 
    For example, the PRP and PDP may share an address space.

    
        
When policies are identified with the subject, the model 
        is called a "capability" model.  

    
Capabilities specifically mean the use of a bearer 
    token that specifies the right to do something. See for example: http://www.garlic.com/~lynn/secure.htm which 
    cites both RFC2828 and the National Security Decision 
    Directive:

    
 

    
"(I) A token, usually an unforgeable data 
    value (sometimes called a 'ticket') that gives the bearer or holder the 
    right to access a system resource. Possession of the token is accepted by a 
    system as proof that the holder has been authorized to access the resource 
    named or indicated by the token. (C) This concept can be implemented as a 
    digital certificate. [RFC2828 ] A protected identifier that both identifies 
    the object and specifies the access rights to be allowed to the accessor who 
    possesses the capability. In a capability-based system, access to protected 
    objects such as files is granted if the would-be accessor possesses a 
    capability for the object. [AJP][NCSC/TG004"

    
I 
    consider capabilities infeasable in medium and large scale environments 
    because they create to close a coupling between the user repositories and 
    the resources protected by the PEPs. Either the capabilities must be so 
    coarse grained that they are not useful (whole web site) or the 
    administrative coodination required is impractical (if I add a single page 
    to my web application, I have to inform the capability issuing 
    point).

    
 

    
When a policy layer is interposed between the 
    "capabilities" and the actual policy decision, essentially you end 
    up with user attributes, as in the SAML/XACML domain model. If you want to 
    call a SAML Attribute Assertion a capability, then I guess we don't have any 
    fundamental disagreement, but that is different from how the term has been 
    used in the literature.

When policies are 
    identified with resource and action, the model is called an "access 
    control" model. 

    
        
At least in theory, policies could be identified with 
        ancillary parameters (e.g. time of day).  But, this doesn't seem to 
        be an especially helpful option.

        
In the capability model, policies are located and 
        retrieved based on the subject's name, and in the access control model, 
        policies are located and retrieved based on the name of the resource and 
        action.

        
We'll have to decide whether to support both capability 
        and access control models.  Personally, I would be quite happy to 
        ignore the capability model.  Perhaps, the group could consider 
        taking this position, and seeing if anyone complains.  If someone 
        were to complain, then we would have to define a general model that 
        accommodates both capability and access control approaches. 

    
 Perhaps this is only an issue of definition. 
    I believe strongly that the domain model, with potentially multiple 
    authorities is the right kind of approach. As long as your notion of 
    capabilties fits in that framework, I have no problems with it. 
    

    
 

    
Hal