I have a very basic fear that this working group is getting chartered
with a bunch of aims added by people who will not take on the
task of doing the work. After private discussion with folks
involved, my sense is that the very core of this work is a
perceived
need to be able to pass opaque strings between a host and the
network
prior to the host attaching. Those opaque strings are, essentially,
the vendor-specific strings currently associated with posture
assessment.The standard protocol carrying these strings would
connect on the network
side to a system that has plug-ins which understand the vendor-
specificstrings.
With a charter that clarified that this was intended to assist the end
systems with vulnerabilities prior to attachment because the
network they are attaching to might be filled with danger, I
think this work would get done reasonably quickly. (As a control
mechanism to protect the network, I agree with the point made
clearly by others that this is not appropriate).
I am less sure of the task of standardizing attributes.
I am not sure that the number of attributes which can be standardized
will ever be high enough to be truly useful, and I am pretty sure
that all of these will be already covered by vendor-specific
attributes.Since there must be an assessor in place on the client
for those few
standardized attributes to be assessed and that assessor will
likely already
have these covered by vendor-specific attributes, in other words,
we seem to be standardizing redundancy. On the network attachment
side, it is possible, of course, that an offer of remediation
could be made
based on just the standard attributes, but it seems far more
likely that
it would be a two step process (assess standard attributes, then pass
vendor-specific attributes to vendor plug-in). Again, if the vendor's
attributes cover the standard attributes, then this is largely
redundantand may add measurable latency; it seems far more likely
that
step one would simply be skipped if there were a vendor-specific
stringand an available plug-in. Since there has to be an assessor,
the first
seems very likely to me. If you don't have a vendor's plug-in, then
I suppose there is some chance that you will trust and act based
on the standard
attributes, but the chance of getting the right remediation seems
pretty slight in those circumstances. Especially when many
vulnerabilitiesare a combination of conditions, (Browser version
Foo on OS patch level Bar)
that you could remediate by upgrading either one, checking for and
acting on the attributes which could be standardized seems of
very, very
limited utility.
I think that most function should be completed through vendor-specific
attributes and
standard attributes are only basic information.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf