Subject: RE: [Nea] NEA requirements draft comments

From: "Paul Sangster" <[email-masked]>
Date: Sun, 18 Mar 2007 06:56:49 -0700

Just realized my 3/5 response to Nancy's comments didn't also go to the
alias.

________________________________

	From: Paul Sangster 
	Sent: Monday, March 05, 2007 8:25 PM
	To: 'Nancy Winget (ncamwing)'
	Subject: RE: [Nea] NEA requirements draft comments

	Thanks for your comments, many of the responses below were
included in the (now published) -01 I-D (just didn't have time to send
out the response).  Comments with [PS] prefix...

________________________________

		From: Nancy Winget (ncamwing)
[mailto:[email-masked]] 
		Sent: Tuesday, February 27, 2007 5:27 PM
		To: [email-masked]
		Subject: [Nea] NEA requirements draft comments

		Hi,
		 
		I reviewed the requirements and security considerations
of the NEA requirements draft and have some comments below:

		General:
		    - the terms Client and NEA Client, are used
interchangeably; only one term should be chosen and used consistantly.
Similary for Server and NEA Server.
		 
		[PS] Reviewed the draft and fixed these ambiguities
(however left uses of "NEA Client and Server" which seems clear enough.
Some uses of "server" were also appropriate.  Didn't find any examples
of "Client" or "Server" (capitalized) without a NEA oriented prefix.
		 
		Section 2. Terminology
		    - Should add the following terms as they are used
throughout the draft: Validator (or Posture Validator and use only one
of these terms), NEA Client, NEA Server, NEA Component
		 
		[PS] These are described in the Reference Model section.
We felt these needed more context then a short definition.
		 
		    - consider adding one or two terms for: User, Owner,
Deployer, Administrator
		 
		[PS] Added "User" which we had intended to define all
along and Deployer.  Owner was already defined.  Will consider adding
others as well although some have expressed a concern about our defining
terms for too many generic (well known) words.  User and Owner were
important for the privacy considerations section so were desired.
		 
		    - Policy:  there is much mention of the general term
"policy" which at times is a configuration option, at times a set of
"Policy Attributes" and at times something else, that needs to be
clarified and defined in this section.
		 
		[PS] Policy Attributes are defined.  Not sure if we want
to try to define something specific for the term policy but am open to
feedback on this (including text contributions.) 
		 
		Section 7.1 Common Protocol Requirements
		 
		[PS] We will discuss section 7 at a later date as our
current focus is on the context setting sections.  We appreciate the
comments and will respond to these separately. 
		 
		    - the protocol requirements put forth imply that
there is a predefined means by which the client and server know how to
reach each other.  This could be implied or also assumed by the
underlying protocol, but is not mentioned in either the requirements,
assumptions or considerations sections.  While there is mention to this
in the architecture section, there should be more clear mention as to
such assumptions in either Section 7 or Section 8 as well.
		    - while the individual requirements for the PA, PB
and PT protocols call out for confidentiality and integrity, the common
section does not.  While C-4 speaks to protection against active,
passive and replay attacks, there is no mention to forgery or
eavesdropping attacks?

		Section 7.4 Posture Transport (PT) Protocol Requirements
		    - Should PT-5 also include retransmissions?
		    
		Section 8.1 Trust
		    - This paragraph is too leading and can be construed
to attempt to impose further security requirements versus a descriptive
statement to assert that the trustworthiness of the attribute contents
is beyond the scope of this body.  Further the security requirements
imposed on the PA, PB and PT are to establish trust between the NEA
Client and NEA Server but does not assert trust of the Endpoint hosting
the NEA Client.  My suggestion is to reword the first paragraph of this
section to something like:
		    "Network Endpoint Assement enables NEA Clients and
NEA Servers to communicate Posture information that is assessed by
Posture Validators.  The trust relationship established between the NEA
Client and NEA Server is used to securely exchange attributes but is not
intended to provide assuranses to the trustworthiness of the Endpoint."
		 
		[PS] Based on others prior comments the initial sentence
was replaced with something closer to what you have suggested. 
		 
		Section 8.1.1 Client Components
		    - 1st sentence of the first paragraph should read:
"For NEA to properly operate, the NEA Client component of the Endpoint
needs to be trusted to accurately represent the requested security
Posture of the Endpoint to the NEA Server."
		 
		[PS] The intention was to be more broad as their could
be other software on the Endpoint that might trick the NEA Client into
misrepresenting the Posture of the system.  We are trusting that this is
not happening and that the Endpoint is accurately representing its
Posture.
		 
		    - it is not clear to me why the rest of this first
paragraph (e.g. 2nd sentence to end of paragraph) is needed?  If the
point is "The trustworthiness of the contextual information of the
attributes themselves is beyond the scope of this draft." then it should
just state that and removed the rest of the text.
		 
		[PS] This text is consistent with the NEA WG charter
("However, the protocols developed by the NEA WG must be designed to
accommodate emerging technologies for identifying and dealing with lying
endpoints.") and is one of the items that needs to be covered by our
activities.  This was discussed at the NEA BOFs.  Unless its not
accurate or misleading i would prefer to see it remain.  What is the
concern about this text? 
		 
		    - The 2nd paragraph should also include that there
must be some inherent trust between the NEA Server with the NEA Client
that is doing the comparison and effective compliance validation.
		 
		[PS] Can you be more specific?  If I understand the
comment this is at the heart of what this paragraph is about.  I made
one change (c/we/the NEA Server/) to help clarity but this might not
have captured your intent.
		 
		    - The 3rd paragraph should define what is meant by
"User or Owner" policy.  I assume it is policy configured at the
Endpoint based on a particular User identity?
		 
		[PS] Its policy defined by the User and/or Owner of the
Endpoint as being authorized for use of the Endpoint (e.g. firewall
rules.)  The details of the policy are mechanism specific.  Changed to
"User or Owner defined policy."
		 
		Section 8.1.2 Network Communications
		    - The last paragraph of this section states a
rationale for requiring confidentiality, integrity and replay protection
and should be transcribed as such.  It currently reads as being too
passive, where the requirements posted in Section 7 impose some of these
protections as a MUST.  My suggestion is to state that NEA must guard
against such attacks by providing confidentiality, integrity and replay
protection minimally (or as a MUST) for PA and as a SHOULD for PT.
		 
		[PS] Ok, will try to reword.  I'll note that this text
is informative and the normative requirements are in section 7 (which do
require support for strong security.)  This text is (as you said)
supportive rationale for why such security services are needed. 
		 
		Section 8.1.3 Server Components
		    - Shouldn't this section precede 8.1.2?
		    - Only the first and last sentence of the second
paragraph is needed....the middle ones seem superfluous.
		[PS] Not sure I see them as superfluous as they describe
what is meant by "network footprint" and "internal workings".  Is there
something specific of concern about these sentences or is it just that
its believed they are unneeded (obvious?)
		 
		    - The last paragraph reads squishy as well,
especially the last sentence.  I presume by "different systems", it is
intended to say "the components physically reside in different hosts". 
		[PS] Yes, i've added your text.
		 
		  The last sentense should be more direct in stating
"When there is physical separation, the communications between the NEA
Server components must ensure that the PB Session and PA Message Dialogs
are resistant to active and passive attacks, in particular, guarded
against eavesdropping, forgery and replay."
		[PS] Thanks will change the words
		 
		Section 8.2 Overlapping protections
		    - I would not exactly call the protections as
overlapping, as each mechanism and protocol had its own security
requirements.  While it may be true that deployments may not wish to
afford the costs in security every layer and stack for NEA, I would not
construe them as "overlapping".  A more appropriate title would be
"Protection Policy"
		[PS] Understood, several folks have asked why we are
requiring these (perceived overlapping) protections at each layer.  Will
change the section name.
		 
		    - In some instances, especially when the Posture
Validator is resident in the NEA Server, it may be acceptable to only
encrypt the transport, but in general, such assumptions can not be made.
Thus, I have a problem with this section as it seems to make assertions
that this is generally acceptable.  
		[PS] Where does it assert that a particular protection
should be made?  It points out why we require strong security
protections in each protocol and ultimately the deployer decides which
mix to use based on their environment.  The goal of this section is to
help justify the requirement for cryptographic security services at each
layer and not to dictate when they are used so if you see something
misleading please let us know.
		 
		    - This section should state that consideration for
Policy configuration to allow for the relaxation of protection, say, at
the PA when assurances are afforded by the PT may be allowed.  However,
care must be taken to assure that proper protection is provided for that
particular deployment to meet the security goals of the NEA charter and
requirements.
		[PS] This sounds like its giving the deployer advise on
when to use certain protections.  This draft is merely providing context
and definition of requirements to be used by the NEA WG during protocol
selection.  8.2 is hoping to help justify some of the requirements for
cryptographic security services in section 7 and raises the need for the
deployer to be able to control (via policy) when these services are
actually used.  This is the separation of the requirement to be
supported by a candidate protocol vs. the lack of a requirement for a
deployer to use these services as deemed necessary. 
		 
		Section 8.3.1 MiTM
		    - This, like most of the security sections are too
wordy.  Mutual authentication of the PT link doesn't really guard
against a MitM as the attacker can still listen in on the dialog.  It is
the 
		 
		[PS] Correct and as the section states this is for
active MiTM protection (not passive.)
		 
		protection of the transport itself to guard against any
injection such as forgery, replay or any packet injection/spoofing is
the consideration to be stated as a requirement.  Furthermore, to
disable a MitM from discerning the content of the information being
passed, confidentiality must also be considered to guard against
eavesdropping; but this latter one, isn't really considered a MitM
attack.
		    - The notion of establishing mutual authentication
is a good one, but is not one for MiTM but rather to ensure that only
authorized links between NEA Server and NEA Client are established.
Perhaps that should be the focus of this section as succeeding sections
already describe the need for confidentiality, integrity and replay
protection.
		 
		[PS] Not sure what to make of this comment as it seems
consistent with what was written (maybe your point is 2 paragraphs is
too much ... wordy.)  Since this section is informative and providing
rationale for the requirements, its not clear 2 paragraphs is an issue.
The 1st paragraph talks about the potential for a MiTM attack and the
2nd talks about how mutual authentication and secure communications
(tied to the authentication) prevent the passive and active MiTM from
attacking the protocols.  I added a sentence to include the replay
prevention in case it were possible for an attacker to replay encrypted
messages without detection (although replay is the topic for section
8.3.3)
		 
		Sections 8.3.2, 8.3.3 and 8.3.4 could be better
summarized into one section that describes the different protections:
confidentiality, integrity and replay to guard against the different
attacks.  They currently seem wordy and somewhat redundant as they are
described in more than one section.
		[PS] Will consider this suggestion.  The 8.3 section is
oriented towards "Relevant Classes of Attack" which seems appropriate
for a Security Considerations section as per guidance from  RFC 3552,
section 5.  Whether we structure the section by attack or countermeasure
we get to the same information - potential attacks to be considered and
countermeasures that should be required.  It sound like this comment is
to include less background information to reduce the amount of
text/wordiness.  It will be interesting to see if other agree that this
is an issue or is beneficial.

		Section 9 Privacy Considerations
		    - As this is a requirement specification, this
section could also be shorted to only list the requirement
considerations.   There are two main points that need to be described in
this section: (1) As privacy issues may be regulated and governed by
enterprises, institutions and even governments users may be restricted
to software or even networks based on such regulation.  (2)
Configuration management and control of an endpoint may be administered
by the physical user but constrained to the privacy guidelines as
regulated by the enterprise and/or government.  There is other text
mentioning scope of WG and what NEA technology enables that need not be
(redundantly) described here.
		 
		[PS] I do think this section could be shorter but we
need to see what the consensus is for which portions to remove.  Its
possible that much of 9.2 could be removed (this was included to "seed
discussion".)
		 
		Section 9.1 Implementation Considerations
		    - this section again, seems overly wordy...also, its
focus is more towards NEA Client implementation considerations; suggest
to rename the section as such.
		 
		[PS] Will consider a different name, maybe
"Implementation Privacy Considerations".  Their have been a number of
discussions on the alias involving potential privacy issues with NEA so
this section attempts to capture some of these ideas while recognizing
that they aren't specific to the protocols we are selecting (so fall
more into the realm of implementations.)
		 
		    - it is not clear what is meant by a user to control
which networks.....is the user the one that is configuring the NEA
solution deployments?  Would it be better to refer to the
'administrator' versus a 'user' especially as there is mention of
"per-User" access which can be construed as a NEA Client user or as a
administrator controlling access?
		 
		[PS] Added definition of User but this is not intended
to be the administrator.  The deployer/adminstrator could certainly also
impose policy on the NEA components more likely for reasons other then
User privacy (unless dictated by local laws/customs.)
		 
		    - 'opt-in' policy?  Not sure exactly what this
means?  Enable use of NEA protocols as a whole?  or to particular
attributes?
		 
		[PS] Correct, opt-in is the ability for the User to
decide if they wish to share their Posture information and potentially
any private information with the network in order to gain access.
Several folks on the alias believed it was important that the User be
able to readily assert they do not wish to share information (or limit
what they do share.)  This of course might mean loss of network (or
service) access or more limited access based upon the deployer's policy.
This might be beneficial in countries with more advanced privacy laws
(e.g. EU countries.)
		 
		    - I am somwhat confused to who "user" and "Owner"
and "User policies" refer to.....these roles need to be clearly defined
and the terms used consistently.
		 
		[PS] See the definitions in -01 to see if that helps
(Owner is defined in -00.)  "User policies" are policies expressed by
the User of the system that impacts the operation of the NEA Components.
"Owner policies" would be expressed by the Owner of the Endpoint.  We
believe these terms are being used consistently.
		 
		Section 9.2 Minimizing Attribute Disclosure
		    - the terms "user" "owner" and "deployer" seem to be
used inconsistantly to sometimes means the "one" configuring the full
deployment,  sometimes the "one" using the "endpoint" or the "tag" used
to apply "per-User" policy.....and is somewhat confusing.  Please add a
subset of these in the Terminology section and use them throughout the
specification consistantly.
		 
		[PS] Please reference where you see the inconsistency.  
		 
		    - This section is somewhat confusing as it's now
clear the direction of policy assessment, or the notion of "policy"?
For instance:
		        - this section implies that a "policy" is
defined by a "set of attributes" but is not explicitly clarified?  
		 
		[PS] A privacy policy might be expressed as a set of
attributes which are allowed to be shared with a network.  NEA isn't
defining policy syntax nor semantics so these are just considerations
for implementers wishing to create privacy friendly products (as stated
in 9.1).
		 
		        - this section implies that there is "policy" at
the Endpoint which can limit the information that is provided to the NEA
Server?  Why couldn't this be negotiated between Client and Server?
		 
		[PS] Sure it could be a negotiation that would reflect
the policies of both parties so something would still need to be
expressed on the Endpoint.  It also could be the NEA Server asks for a
set of Attributes and the Client responds with those it is configured to
share with this network and the Server decides if that is sufficient or
whether additional Attributes are needed (or it may just deny/limit
access based on what was disclosed.)  This is the third model described
in 9.2.
		 
		        - these seem to describe different mechanisms
for realizing one model?  That is, the model where the client is
provided "policy" of which attributes it may share with the Server to
serve as a filter.
		 
		[PS] The point of 9.2 was to "seed discussion" on models
for Attribute exchange and their impact on User privacy.  This
discussion may decide this section isn't useful (long term) or to focus
it on an agreed upon smaller set of models for the eventual RFC.  We're
hoping the WG will have some discussions of this section and it will be
significantly simplified.  Before the Prague meeting we'll prompt this
discussion if it doesn't happen organically.
		 
		    - This last paragraph implies that only 1 privacy
filter is needed?  What about an Endpoint that is mobile and may need to
adhere to different privacy policies based on government regulations?
(or Inside vs. Outside an enterprise?)
		 
		[PS] The privacy policies are per-network.  We'll clean
up the last paragraph so this is more consistent with earlier text.
		 
		Regards,
		   Nancy.

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