I like it. I was thinking TLS might be an option too but shorthand should handle that: Action-id: read Action-protocol: http https ftp sftp... Action-method: get b On Dec 13, 2013, at 8:27 AM, David Brossard <
david.brossard@axiomatics.com > wrote: Yes exactly. Thoughts? On Dec 13, 2013 4:02 PM, Bill Parducci <
bill@parducci.net > wrote: Hi David, So you are proposing something like the following… Action-id: read Action-protocol: http Action-method: get …or Action-id: read Action-method: http-get Thanks b On Dec 13, 2013, at 1:59 AM, David Brossard <
david.brossard@axiomatics.com > wrote: Also, John, the value HTTP for action-id is quite odd. At best an action id would be the protocol's method (GET, POST, PUT...) and HTTP would be the protocol type. That could still be expressed in the action category. Also the transport / protocol action is perhaps not what is interesting. Rather a business action (view, edit...) that reflects the original English policy seems more adequate. Thoughts? On Fri, Dec 13, 2013 at 2:58 AM, Steven Legg <
steven.legg@viewds.com > wrote: Hi John, On 13/12/2013 8:04 AM, Tolbert, John W wrote: Proposal in draft. Suggestions welcome. Use case: 1.1.1.1 Prevent sensitive data from being read/modified by unauthorized applications Policies may stipulate which applications can read or modify resources to prevent insecure applications or malware-compromised applications from contaminating or exfiltrating sensitive data. This use case assumes that the Policy Decision Point (PDP) can call an external configuration management database to determine if the application is on the approved list. Attribute: 1.1.2 Authorized-Application This identifier indicates whether or not the requesting application is approved for the actions requested. urn:oasis:names:tc:xacml:3.0:subject:authorized-application The DataType of this attribute is
http://www.w3.org/2001/XMLSchema#boolean . This is not a natural access-subject attribute. Its value does not depend on the access-subject at all and a context handler would not be looking in the same place for this attribute that it would be for other access-subject attributes. The obvious lookup key for access-subject attributes is subject-id, but that wouldn't be useful for fetching an approved applications list (the PEP could provide the attribute, but if we are concerned that the application may be compromised, then perhaps we shouldn't be taking its word that it is an authorized application). A better category would be codebase or intermediary-subject . Even environment would be a better choice than access-subject . A context handler could look up the authorized-application attribute using the subject-id attribute in the codebase category, but if the authorized applications are maintained as a list, then it would be more appropriate to have that list appear as an environment attribute and policies would test if the subject-id in the codebase category is one of the values in the list. A single list is also very coarse. An application is either approved or not regardless of the circumstances. If policies test the codebase subject-id against bags of values in their conditions, then it is possible to be more subtle. For example, an application is approved for read actions but not write actions, or is approved if it's running on a company desktop but not if it is running on a smartphone. It is worth saying in the Security Considerations that the context handler should take steps to verify the authenticity of the subject-id in the codebase category by, for example, cross-checking with the authenticated identity of the PEP, or by ignoring any provided value and generating the value itself using the authenticated identity. Regards, Steven Example: 1.1.3 Prevent sensitive data from being read/modified by unauthorized applications Acme security policy prohibits unapproved applications from reading and modifying sensitive data. Alice attempts to open a sensitive document with an unauthorized application. The request fails. Sample attributes and values are listed below. Resource Attributes Values Resource-ID
http://confidential.acme.com/eyes-only.xml Resource-location webserver1.acme.com Subject Attributes Values Subject-ID Alice Subject-ID-qualifier acme.com Authorized-application False Action Attributes Values Action-ID HTTP 1.1.3.1 Description This sample policy can be summarized as follows: Target: This policy is only applicable to Resource-location = “ webserver1.acme.com ” AND Resource-ID contains “ confidential.acme.com ” Rule: This rule is only applicable if Action-ID contains “HTTP” Then if Subject-ID-qualifier = “ acme.com ” AND Authorized-application = false DENY Obligation: On DENY log attempt to use an authorized application Sample Policy…. To be added -- David Brossard, M.Eng, SCEA, CSTP Product Manager +46(0)760 25 85 75 Axiomatics AB Skeppsbron 40 S-111 30 Stockholm, Sweden LinkedIn:
http://www.linkedin.com/companies/536082 Web:
http://www.axiomatics.com Twitter:
http://twitter.com/axiomatics Google Plus:
https://plus.google.com/u/1/109113357550030353531/