Subject: Re: [Nea] Last call for "due diligence" attributes for PA-TNC basespecification

From: "Joseph Tardo" <[email-masked]>
Date: Fri, 9 Jan 2009 18:38:25 -0800

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.

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?

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.

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.

Thanks,

--Joe

________________________________

From: [email-masked] [mailto:[email-masked]] 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.

BACKGROUND

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.  

Thanks,

PA-TNC Editors

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

---

From: "Paul Sangster" <[email-masked]>
Date: Fri, 16 Jan 2009 15:14:23 -0700

Joe,
 
Thanks for your response, the editors discussed your feedback and our
thoughts are below...

	From: Joseph Tardo [mailto:[email-masked]] 
	Sent: Friday, January 09, 2009 6:38 PM
	To: Paul Sangster; NEA
	Cc: Paul Hoffman
	Subject: RE: [Nea] Last call for "due diligence" attributes for
PA-TNC basespecification

	Paul,

	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.

	[PS] Thanks. 

	Thanks,

	--Joe

	From: [email-masked] [mailto:[email-masked]] 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.

	BACKGROUND

	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.  

	Thanks,

	PA-TNC Editors