Subject: [Nea] Minor comments

From: "Stephen Hanna" <[email-masked]>
Date: Wed, 20 Jun 2007 16:27:52 -0400

Here are my more minor comments, probably not worthy
of discussion. But speak up if you have any concerns.

Thanks,

Steve

------------

On page 4, "its configuration" should be "their configuration" because
"systems" is plural.

Halfway down page 4 in the sentence that begins with the word
"Architectures", I think we should say the existing architectures
"don't offer adequate interoperability" not that they "don't offer
interoperability". The TCG TNC architecture is supported by a lot of
products and it offers lots of interoperability among those products
but it does not offer full interoperability with Cisco NAC products,
for example. I'm not suggesting we add any details here, just add the
word "adequate".

At the end of that paragraph, I think we should delete the last
sentence ("These architectures ..."). Most of these architectures
actually use standards like RADIUS and EAP. The problem is that the
NAC architectures use them in different, incompatible ways.

On page 5 in the definition of "Assertion Attributes", I suggest that
we simplify the first part of the definition by changing the text from
"Attributes sharing the property that they [...]" to "Attributes that
[...]". This is much simpler and it says basically the same thing.

In the next definition on page 5, I think there's a word missing
before the word "status". The current text says "Data element [...]
describing an observed, expected or status of a component property."
Maybe the missing word is "requested"?

On page 6 in the definition of the term "endpoint", "cell phones"
should be plural (to match the other kinds of devices) and "with an IP
address" should be "that may have an IP address" (since the devices
may not have an IP address at the time they are assessed).

In the definition of the term "Message", the phrase "a component"
should be changed to "one or more components" since a single PA
message might include information about AV and Personal Firewall or
about the patch level of OS and application components.

In the definition of the term "Owner", the words "possessor on an
asset" should be changed to "possessor of an asset". The change here
is to change the word "on" to "of". This is a typo.

On page 7 in the definition of the term "Session", I suggest that the
word "subscribed" be removed from the definition. That term
presupposes a particular model for Posture Collector ID management.

In the definition of the term "User", I suggest that the phrase "to
perform her job" be changed to "for business purposes". This expands
the idea of what activities would be permissible and avoids the
problem of deciding on a gender for the pronoun.

In the first paragraph of section 3, I suggested that we add the word
"the" before the phrase "technologies being standardized". This will
clarify that section 3 covers only the technologies being standardized
in the NEA WG not any other technologies being standardized.

In the first paragraph of section 3.1, I suggest that we change the
phrase "local interfaces between NEA Reference Model components" to
"interfaces between other NEA Reference Model components" because the
interfaces in question (the ones we're not standardizing) may not be
local (constrained to one system). For instance, a Posture Validator
may be located on a different machine from the Posture Broker Server.
The change here is to remove the word "local" and insert the word
"other".

Later in that paragraph, I suggest that we change the words "provided
to provide context" to "not normative and provided only to provide
context". I think this will clarify that any discussion pertaining to
other interfaces is not normative.

In the second paragraph of section 4, I suggest that we replace the
reference to "guest machines" with a reference to "contractors'
machines". It's more likely that a corporation would want to assess
the posture of contractors' machines than guest machines. Often, guest
machines are simply given Internet access while contractors' machines
have to get access to more sensitive resources and networks.

Later in that same paragraph, I suggest changing "quarantined where
needed" to "quarantined when needed". I think the intent of these last
few words is to emphasize that assessment, remediation, and quarantine
can be used when and as appropriate. The current text might lead the
reader to focus instead on quarantining the endpoint in the proper
location. The first word in the next sentence should be "endpoints"
not "endpoint" since the verb is "are".

In the following paragraph (the first full paragraph on page 10), "the
non-compliant endpoint" should be "a non-compliant endpoint". I
believe the reference here is supposed to be to an indeterminate
endpoint, not a specific one. In the last sentence of that paragraph,
the words "on the network" should be deleted. They are unnecessary and
confusing.

In the last paragraph of section 4, the word "by" should be removed
from the last sentence and replaced with a comma. Otherwise, this
sentence can easily be understood to mean that the endpoints in
question are employing service triggered assessment to access
applications. Instead, the enterprise is using service triggered
assessment to protect applications. The endpoint is simply trying to
access those applications.

In the first paragraph of section 5, please remove the comma between
"thin" and "message wrapper". It's unnecessary and confusing. In the
following paragraph (immediately after Figure 1), change "allow" to
"allows" since "information" is singular. At the end of this
paragraph, change "part of" to "in". The former is not
grammatical. At the end of this sentence, I suggest that we change
"the Posture Transport" to "PT" or (less preferred) change it to
"the Posture Transport Protocol". The current phrase could be mistaken
as a reference to the Posture Transport Client or Posture Transport
Server.

In the bulleted list at the start of section 5.1.1, change "Posture
Collector" to "Posture Collectors". There will often be several
Posture Collectors. I think it is misleading to just mention one.

In the paragraph after the bulleted list, change the word "system" to
"endpoint". That's the term we've been using throughout for the device
that hosts the NEA Client.

In the next paragraph, remove the word "is" from the first sentence.
It's extraneous. Later in that paragraph, change "multiple domain
posture" to "posture for multiple domains". I'm pretty sure the new
phrase will be clearer for new readers (assuming I understand what you
are trying to convey).

In the first sentence of section 5.1.1.1, change "(Remediation
Attributes)" to "in Remediation Attributes". This is more consistent
with the reference to Result Attributes that appears earlier in the
sentence. At the end of this paragraph (on page 13), spell out the
acronym "IDS". This is the first time that acronym appears in the
document (although not the last).

In the second paragraph of section 5.1.1.1 (on page 13), remove the
word "the" before the word "specified". See my earlier substantive
comment on having more than one identifier per Posture Collector.

On page 13, in the second sub-bullet of the second bullet in the
bulleted list remove the word "a" from the phrase "applicability of a
recently issued attributes".

In the first bullet on page 15, change the comma into a period and
capitalize the first letter of the following word ("the"). The
responsibility being delegated is "initiating and maintaining the
communication channel to the NEA Server". The next part of the text
is just an explanation.

In the bulleted list at the start of section 5.1.2, change "Posture
Validator" to "Posture Validators". There will often be several
Posture Validators. I think it is misleading to just mention one.

In the first paragraph of section 5.1.2.1 (on page 15), change the
word "pass" to "send". Getting a request from a Posture Validator
to a Posture Collector requires a long route. I think the word "pass"
makes it sound like a short (maybe local) trip.

In the bulleted list on page 16, the words "Result" and "Remediation
Instructions" are capitalized several times. I think that's left over
from the old and now abandoned convention of capitalizing words that
are listed in the Terminology section. They should be lower case.

In section 5.1.2.2, the first occurrence of "Posture Broker Client"
should be "Posture Broker Server". I suggest placing the "e.g." in
parentheses. The current punctuation (using one comma) isn't right.
I also suggest changing "in" to "into", changing "returns" to "sends"
(because this is not a local operation), and adding the phrase "via
the Posture Transport Protocol" at the end of the sentence. That
should clarify things. Later in that paragraph, I suggest removing the
parentheses around the "s" in "(PA messages(s))". These parentheses
are not necessary since the phrase "Posture Collector responses" is
already plural. Nested parentheses are somewhat awkward, anyway.

In the second paragraph of section 5.1.2.2, the comma after the phrase
"various Posture Validators" should be a period and the following word
("this") should be capitalized. These are really two separate sentences.

The second bullet in the list at the end of sectin 5.1.2.2 should
probably just say "from and to the relevant Posture Validators"
instead of "between the NEA Client and the relevant Posture
Validators". In the third bullet, the global assessment decision is
also based on policy. You might want to mention that.

In the second sentence of section 5.1.2.3, I think "more than one
Posture Transport Servers" should be "more than one Posture Transport
Server".

In section 5.2.2, I suggest that you delete the word "requested" from
the first sentence. Even Posture Collectors that have not been
explicitly "requested" should be able to send PA messages. This is
needed for endpoint triggered reassessment.

In section 5.3.2, I suggest that the word "describe" be changed to
"explain". As described in the Terminology section, remediation
attributes generally provide instructions for how remediation should
be done. So the term "explain" is more accurate than "describe".

In the first paragraph of section 6, I suggest adding "or the only use
cases" after "the only approach to addressing the use case". This will
clarify that there may be other use cases. At the end of this
paragraph, I find this clause somewhat awkward: "how the flows might
occur and require support from the NEA protocols". I suggest that it
be reworded along these lines: "how the flows might occur and what
support they might require from the NEA protocols".

In the second paragraph of section 6, "their" should be "its".

In the first bullet on page 21 (section 6), the word "a" is missing
before the phrase "request to use a service". Also, I suggest that
the start of that sentence be changed from "This might" to "This
evaluation might". Otherwise, it's not clear what "this" refers to.

In the second bullet on page 21, "This could" should probably be "This
evaluation could". Otherwise, it's not clear what "this" refers to.

I will not provide minor comments on the subsections of section 6 at
this time since Susan has suggested substantial changes to this part
of the document.

In section 7.1, change "NEA conceptual architecture" to "the NEA
reference model". The term "conceptual architecture" has been replaced
with the term "reference model" everywhere else in the document.

In requirement C-8, "attributes messages" should be "attribute
messages".

In requirement C-10, "amount information" should be "amount of
information".

At the end of requirement PA-4, I suggest that we change "information
about additional component" to "additional information as needed".
The ability to request Posutre and Assertion Attributes more than once
isn't just needed to request information about additional components.
It can also be used to request additional information about components
previously interrogated. For instance, the first request might ask
which version of an application is being used. The second one might
ask about settings specific to that application version.

In requirement PA-5, "the Posture Validator" should be "a Posture
Validator" since no specifi Posture Validator is being referred to.

In requirement PA-7, I think "provide" would be better wording than
"support". The PA protocol needs to more than supporting those
protections. It needs to actually provide the protections. Later in
the sentence, the comma after "attributes" should be removed.
Otherwise it's not clear that the word "sent" is modifying the
attributes and not the protections (authentication, etc.)

The first paragraph of section 7.3 describes how the PB protocol
allows attributes to be sent from Posture Collectors to Posture
Validators. That's good but it should also mention that the PB
protocol supports transmission in the opposite direction as well.

In the third sentence of requirement PB-4, "allow" should be "allows"
and "be implemented" should be "to be implemented".

In requirement PT-1, "us" should be "use".

Requirement PT-2 only applies in certain specific environments (like
EAP) so I suggest that we add at the end of this requirement these
words: ", if this is valuable for the intended lower layer protocols".

In requirement PT-5, the second sentence is a bit confusing. I suggest
that we revise the section that currently says "perform
fragmentation, reassembly, and detect duplicates and reorder" to say
"perform fragmentation and reassembly, detect duplicates, and
reorder". This revision is intended to reflect the fact that
fragmentation and reassembly are one logical unit, as are
duplicate detection and reordering to provide in-sequence delivery.

In the second paragraph of 8.1, I suggest changing "these parties" to
"the components in the NEA system" or something similar. This should
help clarify which parties you're referring to. If you want to be even
more clear, you could add a parenthetical list: NEA Client, NEA
Server, and network.

In the first paragraph of section 8.1.1, the clause "if such
mechanisms do come into existence" implies that such mechanisms do not
now exist. In fact, mechanisms for detecting lying endpoints already
exist: the TPM and PTS. I suggest that this clause be changed to "if
such mechanisms are employed in a particular deployment".

The first sentence of the third paragraph of section 8.1.1 is a bit
confusing. I suggest changing the word "it" in that sentence to "this
trust" to remove ambiguity about what "it" refers to. I also think we
should not require a policy to be established. A user or owner action
should be sufficient to authorize trust. In light of this, I suggest
changing "the user or owner defined policy" to "a user or owner policy
or action". Later in that paragraph, I suggest changing "the NEA
assessment" to just "NEA assessment" since there's no one specific
assessment referred to here. This is a general statement.

In the second paragraph of section 8.1.2, I suggest we change "DOS" to
"attempt to disrupt". There are lots of ways to disrupt communications
other than dropping messages or mounting a denial of service attack.
The intermediaries could inject bad packets or replay packets, for
instance. This would not be a true DOS attack since it would only
affect one session.

In the third paragraph of section 8.1.2, we should add commas to the
list, changing it to "remediation, isolation, and access controls".
Otherwise, it's not immediately clear that it is a list.

In the first paragraph of section 8.1.3, the word "remote" should not
be in parentheses. Otherwise, it is implied that this word is not
essential to understanding the meaning of the sentence. That's not
true. This sentence is specifically addressing the matter of remote
Posture Validators. At least, that's my understanding. Later in the
paragraph, the words "are protected" should be changed to "must be
protected". We should invoke a sense of urgency here not complacency
that such protection is already provided.

In the third paragraph of section 8.1.3, I suggest that "each of the
NEA Server components" be changed to "some of the NEA Server
components". For this example, it's not necessary for all of the NEA
Server components to reside on different systems, just some of them.

In the second paragraph of section 8.3.1, "either party" should be
"both parties". With mutual authentication, the MITM must convince
both parties that it is legitimate (unless the MITM can convince one
of the parties to disclose its authentication secrets to him, which
should not be possible). Later in that paragraph, "prevent" should be
"prevents".

At the end of the first paragraph of section 8.3.2, I suggest changing
the example attack to one where the attacker sends bad remediation
instructions, causing previously compliant systems to become
vulnerable or infected. This is worse than simply hiding
non-compliance and I think we should highlight the worst case.

At the end of the second paragraph of section 8.3.2, the word
"existed" should be changed to "is located". We're not concerned with
where the Posture Validator might have existed at some time in the
past but where it is located at this time. Earlier in that sentence, I
think we need a comma before "extending" to clarify that "extending"
modifies the inclusion of the requirement not the attributes.

In the first sentence of section 8.3.3, I think we need a comma before
"recording". Otherwise, readers may think that the network is
recording. The last sentence of this paragraph does not provide much
clarification or guidance. Therefore, I suggest replacing that
sentence with this one: "For this reason, the PT protocol is required
to provide confidentiality and replay prevention."

In the first sentence of the third paragraph of section 9, I think
it's important to clarify who must establish "a clear expectation of
disclosure/compliance". Therefore, I suggest adding the clause "the
endpoint owner has established" before that phrase and removing the
words "has been established" after the phrase.

In the fourth paragraph of section 9.1, I think "of" should be "on" in
the phrase that currently reads "policies of the attributes". I don't
think you usually have policies of something. Instead, I think you
usually have policies on something. At the end of this paragraph, the
word "to" before the word "whether" should be removed. It's redundant.

In the first sentence of the next paragraph, "be" should change to
"is" to be consistent with the verb "articulates". In the bulleted
list later on that page, the punctuation at the end of each bullet
should be removed. There's no need for it and it's distracting,
especially with such short bullets.

In the References section, are [IPSEC] and [TLS] really normative? I
think they're just mentioned as examples. Actually, I think this is
also true of [EAP], [HMAC], and [RADIUS] also.

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