Paul,
I have given this a
lot of thought both from do-the-right-thing standards and vendor perspectives
and have concluded that missing Joel-suggested attribute types should be
considered for inclusion, for the following
reasons:
1. If they are used
in one or more existing products as Joel found, then these products must have
found them necessary. In particular, file system and registry parameters are
necessary (but, alas, not sufficient) to accommodate arbitrary user-defined
policies using ‘commodity’ clients and verifiers. Frankly I would also like to
see the running process table in there as well.
[PS] The attributes
mentioned were specifically discussed in Minneapolis and while they
may exist in a number of commercial implementations could be considered a
privacy concern in the IETF as they allow the NEA server to ask very focused
questions about any portion of the endpoint's operational state - not just
assessing the readiness of security components on the endpoint. Such
questions were discussed during the formation of the WG and were considered
outside of the charter due to privacy concerns.
Instead it was suggested that we
take the base protocol specifications through the approval process and
additional attributes (or other NEA code points managed by our IANA registry
process) could be added using our agreed upon lightweight approval
process. See Steve's consensus check e-mail from 12/26/08 which
states:
"For all IANA registries defined in PA-TNC and PB-TNC, the following requirements must be met to add an entry to the
registry:
- Expert
Review
- Specification
Publically Available (RFC or other IANA archived
document)
- Specification
must be clear and ensure interoperability
- Must be judged
useful and not harmful to the internet"
2. The proposed set
of attributes clearly leans both in semantics and terminology towards a
specific product’s requirements as apparent justification for their inclusion.
While I have no problem with this in principle, its corollary is that adding
‘genericized’ attribute types used by other products should be equally
justified. My example is the attributes that drill down on firewall ports –
this is rather endpoint enforcement specific. Applying this rationale,
shouldn’t some of these attribute types also be more appropriately registered
in a subsequent specification?
[PS] I don't believe that the specification includes
specific products requirements so I'm not sure if you mean "specific
technology requirements". In other words, we tried to avoid including
attributes specific to a single (or very small number of) vendor
implementations but tried to represent common security oriented technologies
that may be found on the endpoint. The firewall ports are a good example of an
endpoint security technology that could be present and included in an
assessment. Many vendors offer endpoint firewall products and should be
able to represent their simple filtering rules using this attribute so its not
(vendor) product specific.
[PS] The attributes included on
Product Specific slide were considered to be not generic enough (e.g. Google
desktop search installed). Note that these could be added later
using the IANA registry process if desired and appropriate. The expert
group could help decide whether the attribute should be standardized as an
IETF (Vendor ID = IETF (0)) or vendor specific well
known value.
3. While everything
certainly can’t be anticipated, my preference would be to include a few more
known types that will either forestall proliferation of subsequent
specifications whose only purpose is to add numbers to the registry – should
there be a WG to host such drafts – or, more likely, non-interoperable but
redundant vendor-specific code points.
[PS] I agree that we won't be able to anticipate
everything that will be needed over the long term as the list will constantly
be growing. We tried to put in place with the IANA registry a
lightweight way to register new code points. The registry will handle
hosting the drafts and the expert group reviewing them. Note that these
specifications will need to document the attribute contents and semantics to
enable interoperability so its more then just adding a
number.
In other words, not
including a few additional types seems counter productive to NEA goals to
me.
By the way, the link
to the slides is http://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm.
Also, I realize I may have missed the deadline by a few hours, but hope these
points will be considered anyway.
[PS] Thanks.
Thanks,
--Joe
From:
nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On Behalf Of Paul Sangster
Sent: Tuesday, December 30, 2008 12:07
PM
To: NEA
Cc: Paul Hoffman
Subject: [Nea] Last call for "due
diligence" attributes for PA-TNC
basespecification
The PA-TNC editors are making a
last call for PA-TNC "due diligence" attributes that you would like to
advocate as being required to be included in the PA-TNC base specification
before starting the WGLC approval process. At IETF 73, we discussed that
separate specifications could be created in the future to define additional
PA-TNC standard attributes as required so the base specification should do a
best effort to define the initial standard set. However we wanted to
take a final WG check to see if any of the "due diligence" attributes
identified by Joel Snyder are important to include in the initial PA-TNC base
spec before it progresses. If you feel strongly that one or more
due diligence attributes should be included in the base specification (and not
in a future attribute specification) please state your reasoning to the WG
alias by Friday Jan 9, 2009 at 5PM PST.
During the NEA WG meeting at IETF
73, we discussed the list of "due diligence" attributes gathered by Joel
Snyder. As you will recall this attribute investigation was done to try
to identify additional PA attributes that were commonly used in today's NAC
products that were not currently captured by the PA-TNC
specification.
Joel performed the analysis
by looking at the policies supported by prevalent NAC products and inferred
the attributes required to support these policies using the NEA
protocols. In order to not be tainted by the current specification, Joel
did not attempt to filter out attributes already in the PA-TNC
specification. The editor team reviewed the reported attributes and
presented a categorized list of attributes listing those believed to be
already covered and some rationale for why those not covered were not required
in the base specification at this time. See the presentation
categorization at: http://www3.ietf.org/proceedings/08nov/slides/nea-0.ppt on
slides 19 - 27. This prompted some discussion at the meeting that we
would like to resolve on the WG alias.
Please review the IETF
73 slides and if necessary listen to the audio recording and read Joel's
original e-mail. Notify the WG alias if you feel strongly that any
additional of these attributes are required in the PA-TNC base specification
before it progresses.
