Subject: [Nea] NEA requirements draft comments

From: "Nancy Winget \(ncamwing\)" <[email-masked]>
Date: Tue, 27 Feb 2007 17:27:07 -0800

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.

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
    - consider adding one or two terms for: User, Owner, Deployer,
Administrator
    - 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.
 
Section 7.1 Common Protocol Requirements
    - 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."
 
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."
    - 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.
 
    - 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.
 
    - 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?
 
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.
 
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.
    - 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".  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."
 
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"
    - 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.  
    - 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.
 
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 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.
 
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.
 
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.
 
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.
    - 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?
    - 'opt-in' policy?  Not sure exactly what this means?  Enable use of
NEA protocols as a whole?  or to particular attributes?
    - 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.
 
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.
    - 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?  
        - 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?
        - 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.
    - 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?)
 
Regards,
   Nancy.
_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea