Re: [xacml] URN changes for DLP-NAC

[Steven Legg <steven.legg@viewds.com>]

Hi John,

On 27/06/2014 7:15 AM, Tolbert, John W wrote:
>       Hello,
>
> Please ignore the incorrect numbering.  Based on Hal’s discussion today about the DLP-NAC profile, I changed the urn’s to be consistent with the list of identifiers in the core.  Please let me know if this is better, and we’ll incorporate it into WD-08 (still looking for help generating sample policies for section 4.2).  Thanks
>
>
>       **
>
>
>       *1.**Recipient-Subject-ID***
>
> This identifier indicates the entity that will receive the results of the request, which may include user identifiers, machine identifiers, and/or application identifiers.
>
> Subject-ID classification values shall be designated with the following attribute identifier:
>
> urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject:recipient-subject-id
>
> The DataType of this attribute is http://www.w3.org/2001/XMLSchema#string.

I take it that it is still the intention that this attribute is an attribute
of the access-subject.

I would have used the recipient-subject category instead to hold attributes
pertaining to the recipient. It saves defining new attributes that just
duplicate attributes already available to the recipient-subject category.
For instance, this attribute is just the subject-id of the recipient-subject.
Within a policy it is just as easy to designate the subject-id attribute in
the recipient-subject category as it is to designate the recipient-subject-id
attribute in the access-subject category. Users of the profile could also
make use of other attributes in the recipient-subject category that are
already defined in the core or other profiles without first needing to (or
thinking they need to) define private access-subject versions of them.

Similar considerations apply to the remaining attributes.

>       *1.1.1 **Recipient-Subject-ID-Qualifier***
>
> This identifier indicates the security domain of the recipient subject. It identifies the administrator and */policy /*that manages the name-space in which the */recipient-subject /*id is administered.
>
> Subject-ID-Qualifier classification values shall be designated with the following attribute identifier:
>
> urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject:recipient-subject-id-qualifier
>
> The DataType of this attribute is http://www.w3.org/2001/XMLSchema#string.

I'd define this as a new recipient-subject attribute under a different name,
since it doesn't appear to serve the same purpose as the subject-id-qualifier
in the core.

>       *1.1.2 **Requesting-Machine***
>
> This identifier indicates the address of the machine from which the access request originated.  Requesting-machine classification values shall be designated with the following attribute identifier.
>
> urn:oasis:names:tc:xacml:1.0:subject:requesting-machine
>
> The following DataTypes can be used with this attribute:  urn:oasis:names:tc:xacml:3.0:data-type:ipAddress-value and urn:oasis:names:tc:xacml:3.0:data-type:dnsName-value.  For Media Access Control (MAC) addresses, use http://www.w3.org/2001/XMLSchema#string.

It seems like you could use the subject-id attribute in the requesting-machine
category in place of this attribute.

>       *1.1.3 **Recipient-Machine***
>
> This identifier indicates the address of the machine(s) to which the access will be granted.  Recipient-machine classification values shall be designated with the following attribute identifier.
>
> urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine:recipient-machine
>
> The following DataTypes can be used with this attribute:  urn:oasis:names:tc:xacml:3.0:data-type:ipAddress-value and urn:oasis:names:tc:xacml:3.0:data-type:dnsName-value.  The attribute value may include full paths including volume names, where applicable.  For Media Access Control (MAC) addresses, use http://www.w3.org/2001/XMLSchema#string. The attribute may take multiple values.

I'd either use a related entity to represent a recipient machine or define
a new category for recipient machine and let it have all the same attributes
as a requesting-machine.

This attribute would be the subject-id of the recipient-machine entity/category.

>       *1.1.4 **Recipient-removable-media***
>
> This identifier indicates whether or not the destination of the action is a removable media device.  Recipient-removable-media classification values shall be designated with the following attribute identifier.
>
> urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine:recipient-removable-media
>
> The DataType of this attribute is http://www.w3.org/2001/XMLSchema#boolean.

I'd make this an attribute of the recipient-machine entity/category.

From the perspective of the entities profile, the above attributes are
examples of attribute flattening.

>     *1.2 **Codebase Attributes***
>
>
>     *2.4.1 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-category:codebase:authorized-application
>
> The DataType of this attribute is http://www.w3.org/2001/XMLSchema#boolean.

This attribute is in the right place.

Regards,
Steven