Subject: [sacm] Next draft of Common Identifying Attributes subjection of information model

From: Clifford Kahn <[email-masked]>
Date: Fri, 19 Jun 2015 02:19:20 +0000

All,
I have endeavored to include or respond to all of the comments. If I missed any, kindly repeat them!

The referenced standards prescribe notations. A SACM-compliant data model MAY use different notations. But the notations in a data model MUST be equivalent (reversibly mappable) to what is prescribed in the referenced standards. 

4.x.1. Common Identifying Attributes 

4.x.1.1 IP Address

Range of values:  MUST be an IPv4 or IPv6 address, and optionally a scope string.

MUST NOT be a broadcast, unicast, or loopback address.

For IPv4, MUST conform to https://tools.ietf.org/html/rfc791, section 3.2. 

ISSUE (Jim Schaad): Do you need to say it is not a "preferred address" - similar to the link-local address restriction?

(Cliff): What is a preferred address? 

For IPv6, MUST conform to https://tools.ietf.org/html/rfc3587. SHOULD NOT be a link-local address.

Scope string: an administratively assigned string denoting the IP routing domain.
Implementations MUST support this. 
Administrators may use it to avoid ambiguity, for example if network address translation (NAT) is in use.

ISSUE (Jim Schaad): Scope strings are interesting.  However does this imply a potential need to create a new DHCP item so that it can be sent out to a device for reporting back?  Is there such a string already?

(Cliff): Scope strings are like administrative-domain in IF-MAP. It would solve many problems if DHCP servers could provide this string to endpoints and to observers. I am not sure whether there is a standard DHCP option that fills the bill or not. I am not sure how easily application software can get the DHCP options from the underlying OS. But this is worth exploring. 

Meaning:
At the time of observation (plus or minus epsilon) the endpoint had the right to use, or was communicating using, each specified IP address.

Source:
	Self, authority, or observation
•	Self means that software running on the endpoint provided the address.
•	Authority means that the asserter learned the address, directly or indirectly, from an authority that assigned it. For example, the asserted learned the address from a DHCP server (or was itself the DHCP server). 
•	Observation means that the asserter learned the address by directly or indirectly observing network traffic. For example, the asserter observed network packets, communicated with the endpoint, or queried ARP caches of devices that observed network traffic. 

Multiplicity:
An endpoint attribute assertion MAY contain one or more IP addresses.

An IP address can be used by only one endpoint in an IP routing domain at a time.

Conditions of inclusion:
Each endpoint attribute assertion about the endpoint MUST include all IP addresses of the endpoint that are known to the asserter.

If the asserter is the on the endpoint, it will typically know and include all of the endpoint's IP addresses.

If the asserter puts content into an endpoint attribute assertion based on a non-NATted IP communication from the endpoint, the assertion MUST include at least the IP address from that communication. (ISSUE: How can an asserter know whether it's NATted? Or, for that matter, whether an L3 proxy is in between? Maybe we'd better make this a SHOULD.) 

Data model requirements:
All SACM data models MUST support this entire subsection.

4.x.1.2 MAC Address

4.x.1.3	Hardware Serial Number

Range of values:  MUST be a vendor ID and a string. 

Meaning:
At the time of observation (plus or minus epsilon) the endpoint had a hardware component by the indicated manufacturer and having the specified serial number. 

Source:
	Self
•	Self means that software running on the endpoint provided the serial number. .

ISSUE: Is there any other important source for hardware serial numbers?

Multiplicity:
An endpoint attribute assertion MAY contain one or more serial numbers. 

A vendor SHOULD ensure that each serial number goes to only one hardware component instance. However, this is not likely to be possible if the endpoint is a virtual machine. 

Conditions of inclusion:
Each endpoint attribute assertion about the endpoint SHOULD include the serial number of the motherboard, if known to the asserter.

Data model requirements:
All SACM data models MUST support this entire subsection.

4.x.1.4 Certificate

Range of values:  MUST be X.509 certificate. (TODO: Cite the standard properly.)

Meaning:
At the time of observation (plus or minus epsilon) the endpoint had the right to use, or was using, the specified certificate. 

Source:
	Self, observation, or verification
•	Self means that software running on the endpoint provided the certificate.
•	Observation means that the asserter learned the address by directly or indirectly observing network traffic. For example, the asserter saw the endpoint provide the certificate in a TLS exchange. 
•	Verification means that the asserter has verified that the endpoint holds the private key or other secret that corresponds to the certificate. Alternately, a party that the asserter trusts (not the endpoint) has done so.

Multiplicity:
An endpoint attribute assertion MAY contain one or more certificates. 

Conditions of inclusion:
Each endpoint attribute assertion about the endpoint MUST include all certificates for which the asserter knows that the endpoint holds the private key or other secret. 

If the asserter is the on the endpoint, it will typically know and include all of the endpoint's certificates. 

If the asserter puts content into an endpoint attribute assertion based on cryptographically protected communication with the endpoint, and in this communication the endpoint presents a certificate which the asserter verifies, the assertion MUST include at least that certificate. 

Data model requirements:
All SACM data models MUST support this entire subsection.

4.x.1.5 Public Key

4.x.1.6 Tool-Specific Identifier

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 19 Jun 2015 10:32:20 +0200

Hi,

comments are inline.

Best,
Henk

> MUST NOT be a broadcast, unicast, or loopback address.

[HB] thats probably supposed to "be a broadcast, multicast, or loopback 
address".

> ISSUE (Jim Schaad): Do you need to say it is not a "preferred address" - similar to the link-local address restriction?

[HB] if the preferred address is selected automatically (e.g. always the 
lowest address of any given subnet that is assigned to the layer 3 
interfaces of the devices, or automatic election), it could change every 
time the set of layer 3 addresses assigned to the set of layer 3 
interfaces of the endpoint changes. This potential behavior makes 
preferred address less useful for the SACM identifying task, I think.

> (Cliff): What is a preferred address?

[HB] Typically, this term is used to define the address the endpoint is 
consistently using (egress) to communicated with a local subnet in the 
case it has multiple addresses in a subnet.

> •	Observation means that the asserter learned the address by directly or indirectly observing network traffic. For example, the asserter observed network packets, communicated with the endpoint, or…

[HB] Is an asserter the same thing as an collector? If so, please 
disregard my next comment!

> An endpoint attribute assertion MAY contain one or more IP addresses.

[HB] At this point it might be useful to highlight again that the 
"endpoint attribute assertion" is currently defined as the Result of a 
Collection (from an Endpoint).

> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 28 Jun 2015 19:28:25 -0700

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Henk Birkholz
> Sent: Friday, June 19, 2015 1:32 AM
> To: [email-masked]
> Subject: Re: [sacm] Next draft of Common Identifying Attributes subjection
> of information model
> 
> Hi,
> 
> comments are inline.
> 
> Best,
> Henk
> 
> > The referenced standards prescribe notations. A SACM-compliant data
> model MAY use different notations. But the notations in a data model
> MUST be equivalent (reversibly mappable) to what is prescribed in the
> referenced standards.
> >
> > ISSUE (Jim Schaad): Do you need to say it is not a "preferred address" -
> similar to the link-local address restriction?

[JLS] I don't know off the bat what my OS means by this.  I  am on a connection (usually wireless) and want to get a DHCP address, but cannot connect to the DHCP server then windows will say that my address is XXX.YYY.ZZZ.AAA (preferred).  Since my system has multiple network connections it might report some odd addresses where I think I am on a network, but it may not be a very usable address.

> lowest address of any given subnet that is assigned to the layer 3 interfaces
> of the devices, or automatic election), it could change every time the set of
> layer 3 addresses assigned to the set of layer 3 interfaces of the endpoint
> changes. This potential behavior makes preferred address less useful for the
> SACM identifying task, I think.
> 
> consistently using (egress) to communicated with a local subnet in the case
> it has multiple addresses in a subnet.
> 
> >
> > ISSUE (Jim Schaad): Scope strings are interesting.  However does this
> imply a potential need to create a new DHCP item so that it can be sent out
> to a device for reporting back?  Is there such a string already?
> >
> > (Cliff): Scope strings are like administrative-domain in IF-MAP. It would
> solve many problems if DHCP servers could provide this string to endpoints
> and to observers. I am not sure whether there is a standard DHCP option
> that fills the bill or not. I am not sure how easily application software can
> get the DHCP options from the underlying OS. But this is worth exploring.

We may need to look at what happens if a scope identifier is either not set or not available.  I am thinking of the virtual network that is NATed on my machine.  If those VMs reported the selves then the network configuring systems may not know about that VM and there would not necessarily be a reasonable scope string to report for it.

> >
> > Meaning:
> > At the time of observation (plus or minus epsilon) the endpoint had the
> right to use, or was communicating using, each specified IP address.
> >
> > Source:
> > •	Authority means that the asserter learned the address, directly or
> indirectly, from an authority that assigned it. For example, the asserted
> learned the address from a DHCP server (or was itself the DHCP server).
> > •	Observation means that the asserter learned the address by directly
> or indirectly observing network traffic. For example, the asserter observed
> network packets, communicated with the endpoint, or queried ARP caches
> of devices that observed network traffic.
> 
> > Each endpoint attribute assertion about the endpoint MUST include all IP
> addresses of the endpoint that are known to the asserter.
> >
> > If the asserter puts content into an endpoint attribute assertion based on
> a non-NATted IP communication from the endpoint, the assertion MUST
> include at least the IP address from that communication. (ISSUE: How can
> an asserter know whether it's NATted? Or, for that matter, whether an L3
> proxy is in between? Maybe we'd better make this a SHOULD.)

Given the way you stated this, if the asserter does not know it is nat-ed then it is going to put the address into the assertion.  I think this is reasonable.  The question is if we need to be talking about having ports in some instances as well - "I saw this type of packet toing to this address and this port".   This is a case where a router may publish the information:

Address X maps to address Y ports k-Z from time point start to time point end -  This type of statement is endpoint identifying while the one in the previous paragraph is not.

> > At the time of observation (plus or minus epsilon) the endpoint had a
> hardware component by the indicated manufacturer and having the
> specified serial number.
> >
> > Source:
> > 	Self

Source can also be third party - think in terms of the inventory control system.

> > An endpoint attribute assertion MAY contain one or more serial numbers.

This is not a protocol MAY - are you saying this is something that is optional to do?  I don't think so.

Can an endpoint assert contain ZERO serial numbers?  This would allow for a positive assertion that I have no hardware by vender ID foo on this system.  A statement that says I have no reportable items of hardware would be required for this.  Otherwise it may just be that no statement was made about this possibility.

> >
> > A vendor SHOULD ensure that each serial number goes to only one
> hardware component instance. However, this is not likely to be possible if
> the endpoint is a virtual machine.

I am a SACM implementer - what do I do with this SHOULD statement?  We are really saying that SACM components cannot assume that hardware serial numbers are going to be unique.  They may be incorrectly reported, reported by multiple entities and so forth.  What does the above statement buy us?

> >
> > Conditions of inclusion:
> > Each endpoint attribute assertion about the endpoint SHOULD include the
> serial number of the motherboard, if known to the asserter.
> >
> > Data model requirements:

That is a fun question - do you want to cite the IETF standard from the PKIX group or the ISO standard?  They are different but close.

> >
> > Meaning:
> > At the time of observation (plus or minus epsilon) the endpoint had the
> right to use, or was using, the specified certificate.
> >
> > Source:
> > •	Observation means that the asserter learned the address by directly
> or indirectly observing network traffic. For example, the asserter saw the
> endpoint provide the certificate in a TLS exchange.

Observation makes little to no sense at this point. However if you keep this, the first sentence needs to be cleaned up.  Note that going forward, one will not be able to observe the certificate in a TLS exchange starting with version 1.3

> > •	Verification means that the asserter has verified that the endpoint
> holds the private key or other secret that corresponds to the certificate.
> Alternately, a party that the asserter trusts (not the endpoint) has done so.
> >
> > Multiplicity:
> > Each endpoint attribute assertion about the endpoint MUST include all
> certificates for which the asserter knows that the endpoint holds the
> private key or other secret.

This requirement would seem to make observation difficult.  One has problems knowing if a certificate was used successfully.

> > If the asserter puts content into an endpoint attribute assertion based on
> cryptographically protected communication with the endpoint, and in this
> communication the endpoint presents a certificate which the asserter
> verifies, the assertion MUST include at least that certificate.
> >
> > Data model requirements: