Ted Hardie <hardie(_at_)qualcomm(_dot_)com> wrote on 10/08/2006 11:45:37 PM:
[snip]
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.
Yes, that is the essence of this work which is what we need to
remember and focus on. It will probably be applied for various purposes.
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-specific
strings.
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).
There seems to be confusion as two why people would want to do this.
In one sense we can protect things by not giving compromised endpoints
access to network-attached resources, including parts of the network
itself. This application has caused significant discussion as to the
security of the protocol and solutions using it, which promises to be a
subject of debate for the near future.
Another way of looking at this is that it allows customers to use the
network to enforce endpoint compliance to policy and provide a convenient
"place" to challenge endpoints, collect data from them, thus providing an
audit trail.
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 redundant
and may add measurable latency; it seems far more likely that
step one would simply be skipped if there were a vendor-specific string
and 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
vulnerabilities
are 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.
Standardized VS vendor-specific attributes is not something that
needs to be solved today. Solutions can start with vendor-specific and
migrate toward a standard, if one develops, without changing the protocol.
The specification should not preclude the addition of standardized
attributes. IE the specification is like an alphabet, attributes are like
vocabulary. You can add new words without changing the letters.
Ted Hardie
_______________________________________________
Nea mailing list
Nea(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/nea
Frank Yeh
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf