Hello SCAP-Devvers,
We have a member who has done some assessments and generated Asset Reporting Format files, but those files aren’t validating correctly due to a restriction in the Asset Identification schema.
The member is generating <ai:connection> elements which contain
<ai:mac_address> values that are longer than 12 digits (they are 40 digits). This causes an issue verifying against the AI schema as MAC addresses are defined as:
<xs:simpleType name="mac-address-type">
<xs:restriction base="xs:token">
<xs:pattern value="([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}"/>
</xs:restriction>
</xs:simpleType>
This restriction only allows for 12 digit MAC addresses. I am not sure of the process to request an official modification to this schema. If anyone has thoughts, ideas, feedback; it’s all welcome. I’d simply want to add a comma to the regex:
<xs:pattern value="([0-9a-fA-F]{2}:){5,}[0-9a-fA-F]{2}"/>
To allow for at least 5 groups of values followed by a :
Cheers,
-Bill M.
Bill Munyan
Solutions/Software Architect; Security Best Practices
31 Tech Valley Drive
East Greenbush, NY 12061
(518) 516-6128 (w)
(518) 281-1233 (c)
On Jan 15, 2021, at 4:26 PM, 'William Munyan' via SCAP Discussion and Development <scap...@list.nist.gov> wrote:
Hello SCAP-Devvers,We have a member who has done some assessments and generated Asset Reporting Format files, but those files aren’t validating correctly due to a restriction in the Asset Identification schema. The member is generating <ai:connection> elements which contain <ai:mac_address> values that are longer than 12 digits (they are 40 digits). This causes an issue verifying against the AI schema as MAC addresses are defined as:
<xs:simpleType name="mac-address-type">
<xs:restriction base="xs:token">
<xs:pattern value="([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}"/>
</xs:restriction>
</xs:simpleType>This restriction only allows for 12 digit MAC addresses. I am not sure of the process to request an official modification to this schema. If anyone has thoughts, ideas, feedback; it’s all welcome. I’d simply want to add a comma to the regex:<xs:pattern value="([0-9a-fA-F]{2}:){5,}[0-9a-fA-F]{2}"/>To allow for at least 5 groups of values followed by a :Cheers,-Bill M.Bill MunyanSolutions/Software Architect; Security Best Practices31 Tech Valley DriveEast Greenbush, NY 12061(518) 516-6128 (w)(518) 281-1233 (c)
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
. . . . .
--
To post to this group, send email to scap...@list.nist.gov
To unsubscribe from this group, send email to scap-dev+u...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev
---
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev+u...@list.nist.gov.
David,
Thanks for the quick reply. What we are seeing are 20 byte MAC addresses, apparently coming from Infiniband devices. A quick search found me this in regards to “IP over Infiniband” (IPoIB):
Every such IPoIB network interface has a 20 bytes MAC address. This may cause problems since the "standard" Ethernet MAC address is 6 bytes (48 bits) and there are applications, services and operating systems which don't support a network device with a different size of MAC address than 6 bytes.
In the ARF we’re looking at, we’re collecting the IPv4 address along with these 20-byte MAC addresses. I obviously won’t rule out a collection issue on the CIS-CAT side, but if these 20-byte MAC addresses are possible, I wonder if it’s worth a schema adjustment.
Cheers,
-Bill M.
.....
Well, my original proposal was to update the schema restriction for the ai:mac-address-type. That seemed the easiest solution. I am not opposed to a new ai:ib-mac-address-type either, but that would be pretty much the same schema with the updated restriction. My thought was that updating the existing mac-address-type restriction would be good as it wouldn’t have any effect on existing mac address validations. Are there other MAC addresses out there that would have more than 6 bytes? Could there be some with 14 or 22 or something else weird?
I don’t think I’d want to jerry-rig use of the <url> element as that would be a fair amount of documentation as to how and why that element is used for this specific data, and probably hurt interoperability.
Yeah I guess I was hoping someone from overlapping communities might have some advice on that process (or lack thereof) and if there’s a NIST contact to whom I can reach out for advice.
This restriction only allows for 12 digit MAC addresses. I am not sure of the process to request an official modification to this schema. If anyone has thoughts, ideas, feedback; it’s all welcome.
More precisely, EUI-48 addresses. There are also EUI-64 addresses. And, as you have found, others.
(IEEE has an EUI guideline document here.)
It appears that the asset identification schema cannot currently
express <connection>s (i.e., network connections)
other than the routinely encountered 802.3 and 802.11 types. To
accommodate other types, ai:network-interface-type must
be re-factored to allow other types of network interfaces (with
variant addressing schemes). Such a change would enable <connection>s
to be typified (which might aid topology inference).
Separately, I found that the schema at https://csrc.nist.gov/schema/asset-identification/1.1/asset-identification_1.1.0.xsd
references a non-existent https://scap.nist.gov/schema/reporting-core/1.1/reporting-core_1.1.0.xsd.
That absence similarly afflicts https://csrc.nist.gov/schema/asset-reporting-format/1.1/asset-reporting-format_1.1.0.xsd.
Regards,
Gary