OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] Groups - DLP-NAC profile uploaded


I touched on this and other issues I consider open in this email last November:

 

https://lists.oasis-open.org/archives/xacml/201311/msg00011.html

 

I left the mask as an option in the –value mostly because it is allowed in the current 3.0 datatype and also because I thought it was just possible that somebody would want to insist that two identical values with different masks not be considered equal. I don’t know if there is any legitimate way for this to occur. Clearly you could have a case where the subnet had been reconfigured and there was some old data around.

 

Note also that the ipAddress-network-match function needs a mask as input. Clearly two identical addresses with different masks may not match using this function.

 

As I said in the referenced email, I am open  to making changes related to any of the 8 issues I identified.

 

Hal

 

From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Thursday, March 20, 2014 7:22 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Groups - DLP-NAC profile uploaded

 

Hi,

Why does the ipAddress-value data type have a network mask?

Maybe it was discussed on a call when I was not present, and I am not a networking expert and might not understand what the intention was, but I tried to retrace the discussion on the list. If ipAddress-value is intended to represent a specific network endpoint, then it should not contain a mask, since masks are used to represent IP address ranges, right?

Likewise, the matching functions which use a pattern, they should not be comparing the mask for straight equality, right? I read the intent of the matching functions to be used for checking whether an ipAddress-value is within the network segment denoted by the ipAddress-pattern. The value should be within the range of the pattern, so there should not be a check to see that the mask is equal, or actually, the value should not have a mask in the first place.

Also, regarding the network match function, now it is defined as a strict equality function, but it could be useful to separate between an "equals" and a "match", where the latter allows for one argument to be a subset of the other.

And, did you consider the need of an ipAddress value equal function which also checks the port? BTW, the definition of ipAddress-value-equal says that "Any portrange values in either argument SHALL be ignored", but an ipAddress-value does not have a portrange, it has a port.

Best regards,
Erik

On 2014-03-19 20:54, John Tolbert wrote:

Submitter's message
All feedback received thus far has been incorporated. Please review. Volunteers needed to generate sample XACML policies for examples 4.1.2 to 4.2.2. Thanks
-- Mr. John Tolbert

Document Name: DLP-NAC profile


Description
Working draft 05.
Download Latest Revision
Public Download Link


Submitter: Mr. John Tolbert
Group: OASIS eXtensible Access Control Markup Language (XACML) TC
Folder: Specifications and Working Drafts
Date submitted: 2014-03-19 12:54:23

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]