Subject: [Nea] Substantive comments

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

I have a lot of non-substantive comments (typos and such) on
the latest NEA requirements draft so I have divided my comments
into two emails: one with substantive comments (this one) and
another that I'll send in a minute with only minor comments.

Thanks,

Steve

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

Section 5.1.1.1 says "Each Posture Collector will be associated
with an identifier..."  Depending on how things work, there may
be more than one identifier per Posture Collector so I think we
should say "...associated with one or more identifiers...".
This comment applies to other parts of the document as well, such as
section 5.1.2.1.

Section 5.1.2.1 talks about a Posture Validator's "corresponding
Posture Collector". I don't think there will always be a one-to-one
mapping from one Posture Collector to one Posture Validator. One
Posture Collector may be able to handle Anti-Virus and Personal
Firewall messages while another may only be able to handle Anti-Virus.
The same holds true for Posture Validators. This comment applies
to other parts of the document as well, like section 5.2.1.

In section 5.2.2, PB should be able to carry non-PA messages other
than the global assessment decision. For example, it may be useful
to have PB carry information about the user's preferred language.
That way, this information can be made available to all Posture
Validators so they can send any messages in the preferred language.

The first paragraph of section 5.3 says "The NEA WG will define a
common (standard) set of attributes that are expected to be supported
by all Posture Collectors." I don't think we want to require all
Posture Collectors to support all of the standard attributes, do we?

In section 7.1, requirement C-4 should require that NEA protocols
include protection against attacks by endpoints.

In section 7.2, the first sentence says that PA defines a transport.
I don't think so. PB and PT do that. PA is more like a format. This
comment also applies to other parts of the document, like section 5.2.1.

Requirement PA-1 says "The PA protocol MUST support transport of the
required (standard) attributes defined in the data model." But there's
no data model any more, just standard and vendor-specific attributes.
I think we should have PA-1 require support for the standard attributes
and PA-2 can cover the vendor-specific attributes.

Requirement PB-1 lists some specific messages and says the PB protocol
must be capable of carrying those. I think it should instead just say
that the PB protocol muse be capable of carrying all PA msgs and also
standard & vendor-specific non-PA messages.

Requirement PB-2 should not talk about peer Posture Collectors and
Posture
Validators. Instead, it should explicitly support the idea that one
Posture
Collector or Posture Validator may map to several of the other.

Requirements PT-7 and PT-8 are already covered better by requirements
C-2 and C-3. We shouldn't have PT requirements for these since this
implies that all PT protocols MUST support these use cases. We should
allow some PT protocols to specialize in one use case or another.

Section 8.3.4 refers to "carrier protocols". Those are in PT now so
we shouldn't be referring to them separately.

In section 9.1, I think the phrase "explicitly not" should be "not
explicitly". At least, I hope so!

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

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 21 Jun 2007 16:00:48 -0700

Hi Steve,

Thanks for your comments. Please find my response inline.

> another that I'll send in a minute with only minor comments.

<Kaushik>

Agreed. The text was meant to convey that there needs to be a mechanism to
uniquely identify each posture collector. Will the following edit address
your comment.

"Each Posture Collector will be associated with one or more identifiers that
will be used to uniquely identify the posture collector".

</Kaushik>

> to other parts of the document as well, like section 5.2.1.

<Kaushik>

I agree that the text may be misleading but we certainly did not imply a
1-to-1 relationship. Will the following edit (and similar edits in other
places) address the comment

"A Posture Validator is a component that is responsible for handling Posture
Attributes from corresponding Posture Collector(s). A Posture Validator can
handle Posture Attributes from one or more Posture Collector(s) and
vice-versa".

 </Kaushik>

> Validators so they can send any messages in the preferred language.

<Kaushik>

Agreed. We have discussed the possibility that the PB layer might require to
handle additional attributes in the future and I agree that we should have
text to indicate that possibility.

</Kaushik>

> Posture Collectors to support all of the standard attributes, do we?

<Kaushik>

I am not sure that we need all posture collectors to support all standard
attributes infact I am not sure we are completely settled on how the
standard posture attributes are handled.

I think we should get rid of the second part of that sentence and just state
that " The NEA WG will define a common (standard) set of attributes that
will be present in all NEA deployments irrespective of vendor specific
extensions"

</Kaushik> 

> include protection against attacks by endpoints.

<Kaushik>

I am not sure about the comment. An endpoint is an intermediary in the
network and hence covered by the existing text. Are you referring to attacks
on the NEA client hosted on the endpoint from other endpoint processes, I am
not sure that is within scope

</Kaushik>

> comment also applies to other parts of the document, like section 5.2.1.

<Kaushik>

The text in Section 7.2 seems like a typo will be edited. The first sentence
in Section 5.2.1 does mention "a protocol that carries attribute messages"
which needs to be cleaned up. Section 5.2.1 does try to clarify the scope of
the PA protocol

"The PA protocol is a message oriented lightweight wrapper around a set of
attributes being exchanged.  This wrapper may indicate the purpose of
attributes within the message"

</Kaushik>

> and PA-2 can cover the vendor-specific attributes.

<Kaushik>

Agreed. Would deleting the text " defined in the data model" from PA-1
address this comment ?

</Kaushik> 

> standard & vendor-specific non-PA messages.

<Kaushik>

Agreed. This text should have been addressed as part of our -02 revision
since we decided to move away from attribute types.

</Kaushik>

> Collector or Posture Validator may map to several of the other.

<Kaushik>

Agreed. I think this comment should be addressed as part of editorial
suggestions for your previous comment on 5.1.2.1.

</Kaushik>

> allow some PT protocols to specialize in one use case or another.

<Kaushik>

I agree with your comment about C-2 & PT-7 but I would suggest that we
examine C-2 as a common requirement (rather than deleting PT-7) since the
ability to perform assessment prior to normal network access being granted
to an endpoint depends completely on whether the PT can support such a
capability.

Requirements C-3 and PT-8 might not be identical, since C-3 specifies the
need to support client or server triggered re-assessment and PT-8 requires
the PT protocol to support creation of a communication channel based on
either end of the channel initiating the connection request.  PT-8 will be
required for use cases beyond re-assessment.

I am not completely clear about your comment about specialization of PT
protocols since the charter requires us to specify one mandatory to
implement PT protocol that will probably have to meet all requirements ?

</Kaushik>

> we shouldn't be referring to them separately.

<Kaushik>

We used the term "carrier protocol" to refer to protocols that might carry
the PT, for e.g. EAPoL & RADIUS would be a carrier protocol for EAP. Do you
consider EAPol, RADIUS & EAP as all being part of the PT.

</Kaushik> 

> explicitly". At least, I hope so!

<Kaushik>

You are right. I think it is a typo. In the context of the section, I think
the text intends to say that attributes that are not explicitly shared by
the user will result in a notification

regards,
 kaushik

</Kaushik>

---

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 22 Jun 2007 17:11:07 -0400

Thanks for your response, Kaushik. My responses are below,
marked with <Steve>.

Take care,

Steve 

-----Original Message-----
From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 7:01 PM
To: Stephen Hanna; [email-masked]
Subject: Re: [Nea] Substantive comments

Hi Steve,

<Kaushik>

Agreed. The text was meant to convey that there needs to be a mechanism
to
uniquely identify each posture collector. Will the following edit
address
your comment.

"Each Posture Collector will be associated with one or more identifiers
that
will be used to uniquely identify the posture collector".

</Kaushik>

<Steve>
Actually, I would prefer to just change the phrase "an identifier" to
"one or more identifiers". Then the text would read:

    Each Posture Collector will be associated with one or more
identifiers
    that enables it to be specified as the destination in a PA message.

I don't think it's necessary for each Posture Collector to have a unique
identifier. It's just necessary to be able to route messages to it.
Later
in that paragraph, it says that the identifier may be "a function of the
attribute messages the collector desires to receive (e.g. message type
subscription)." I'm a fan of that approach and don't want to see the
text
changed to make it impossible, as I think your proposed edit would do.

</Steve>

<Kaushik>

"A Posture Validator is a component that is responsible for handling
Posture
Attributes from corresponding Posture Collector(s). A Posture Validator
can
handle Posture Attributes from one or more Posture Collector(s) and
vice-versa".

 </Kaushik>

<Steve>

Yes, that is great! Thanks.

</Steve>

<Kaushik>

Agreed. We have discussed the possibility that the PB layer might
require to
handle additional attributes in the future and I agree that we should
have
text to indicate that possibility.

</Kaushik>

<Steve>

Very good! Thanks.

</Steve>

<Kaushik>

I am not sure that we need all posture collectors to support all
standard
attributes infact I am not sure we are completely settled on how the
standard posture attributes are handled.

I think we should get rid of the second part of that sentence and just
state
that " The NEA WG will define a common (standard) set of attributes that
will be present in all NEA deployments irrespective of vendor specific
extensions"

</Kaushik> 

<Steve>

I agree with most of what you said except this new text: "will be
present
in all NEA deployments". I suspect that some attributes will not be
needed
for some NEA deployments. I suggest this alternative text for that
sentence:
"The NEA WG will define a common (standard) set of attributes that will
be
widely used for maximum interoperability but Posture Collectors may
support 
additional vendor-specific attributes." How's that?

</Steve>

<Kaushik>

I am not sure about the comment. An endpoint is an intermediary in the
network and hence covered by the existing text. Are you referring to
attacks
on the NEA client hosted on the endpoint from other endpoint processes,
I am
not sure that is within scope

</Kaushik>

<Steve>

I don't think the endpoint is an intermediary. According to
Merriam-Webster,
an intermediary is (among other meanings) one who is at a middle place.
The endpoint is not an intermediary. It's one of the endpoints. So
attacks
by the endpoint on the NEA Server or other parts of the system are not
covered by the current text. They should be. Otherwise, a nasty or
infected
endpoint could bring down the whole system.

</Steve>

<Kaushik>

The text in Section 7.2 seems like a typo will be edited. The first
sentence
in Section 5.2.1 does mention "a protocol that carries attribute
messages"
which needs to be cleaned up. Section 5.2.1 does try to clarify the
scope of
the PA protocol

"The PA protocol is a message oriented lightweight wrapper around a set
of
attributes being exchanged.  This wrapper may indicate the purpose of
attributes within the message"

</Kaushik>

<Steve>

I agree with the text from section 5.2.1 that you cited. If you can
clean up section 7.2 to match, I'd appreciate it.

</Steve>

<Kaushik>

</Kaushik> 

<Steve>

Yes, that would do it. Thanks.

</Steve>

<Kaushik>

</Kaushik>

<Steve>

OK, great.

</Steve>

<Kaushik>

<Steve>

Good, good.

</Steve>

</Kaushik>

<Kaushik>

I agree with your comment about C-2 & PT-7 but I would suggest that we
examine C-2 as a common requirement (rather than deleting PT-7) since
the
ability to perform assessment prior to normal network access being
granted
to an endpoint depends completely on whether the PT can support such a
capability.

Requirements C-3 and PT-8 might not be identical, since C-3 specifies
the
need to support client or server triggered re-assessment and PT-8
requires
the PT protocol to support creation of a communication channel based on
either end of the channel initiating the connection request.  PT-8 will
be
required for use cases beyond re-assessment.

</Kaushik>

<Steve>

Hmmm. I guess this raises a larger question. Do we want to require
the mandatory to implement PT protocol to support both assessment
before and during network access and to support both client-triggered
and server-triggered reassessment? That's a tall order! Personally,
I think we should not expect one protocol to do all of these things.
But probably this should be discussed on a separate email thread so
it gets broader visibility.

</Steve>

<Kaushik>

We used the term "carrier protocol" to refer to protocols that might
carry
the PT, for e.g. EAPoL & RADIUS would be a carrier protocol for EAP. Do
you
consider EAPol, RADIUS & EAP as all being part of the PT.

</Kaushik> 

<Steve>

I don't think they're called out separately in our reference model
so yes, I would consider them to be part of PT unless we want to
call them out separately in the reference model.

</Steve>

<Kaushik>

You are right. I think it is a typo. In the context of the section, I
think
the text intends to say that attributes that are not explicitly shared
by
the user will result in a notification

</Kaushik>

<Steve>

Good. That's what I thought you wanted to say but the
current text says something different.

</Steve>

regards,
 kaushik

</Kaushik>

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 22 Jun 2007 17:02:32 -0700

Hi Steve,

Please find my response inline marked with the <Kaushik-Response> tag . I
have snipped some of the text to focus on comments that require a response.

<snipped>

> changed to make it impossible, as I think your proposed edit would do.

<Kaushik-Response>

I was suggesting uniqueness as a property of the identifier to allow Posture
Broker Clients to route Attribute messages to the right Posture Collector. I
wasn't suggesting a globally unique identifier that needs to be statically
allocated which would preclude the posture broker assigning these IDs or IDs
derived from attribute messages based on subscription.

I will probably just stay with your suggestion to avoid the use of the term
unique since it might be confusing.

</Kaushik-Response>

> additional vendor-specific attributes." How's that?

<Kaushik-Response>

Sounds good. Thanks.

</Kaushik-Response>

> endpoint could bring down the whole system.

<Kaushik-Response>

Fair point. We never intended to rule out endpoints when we used the term
intermediary. Would the following text work

" NEA protocols MUST provide protection against active and passive attacks
by intermediaries and other endpoints including protection to prevent replay
based attacks. "

</Kaushik-Response>

> it gets broader visibility.

<Kaushik-Response>

This might require us to think about the use cases that are mandatory to
support for the PT. I agree that this needs more thought and wider
discussion within the WG.

</Kaushik-Response>

> call them out separately in the reference model.

<Kaushik-Response>

You are right. The reference model does not call out the notion of carrier
protocols and we should largely stay consistent with that.

regards,
  kaushik 

</Kaushik-Response>

---

From: "Stephen Hanna" <[email-masked]>
Date: Sun, 24 Jun 2007 15:42:10 -0400

I added comments where necessary (marked with <Steve-Response>)
and snipped areas where we seem to have reached agreement.

Thanks,

Steve 

-----Original Message-----
From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Friday, June 22, 2007 8:03 PM
To: Stephen Hanna; [email-masked]
Subject: Re: [Nea] Substantive comments

Hi Steve,

Please find my response inline marked with the <Kaushik-Response> tag .
I
have snipped some of the text to focus on comments that require a
response.

<snipped>

<Kaushik-Response>

I was suggesting uniqueness as a property of the identifier to allow
Posture
Broker Clients to route Attribute messages to the right Posture
Collector. I
wasn't suggesting a globally unique identifier that needs to be
statically
allocated which would preclude the posture broker assigning these IDs or
IDs
derived from attribute messages based on subscription.

I will probably just stay with your suggestion to avoid the use of the
term
unique since it might be confusing.

</Kaushik-Response>

<Steve-Response>

Ah, so you meant unique only within the NEA Client or NEA Server. I'm
afraid
I don't even agree with that. There may be several Posture Validators
for AV
messages on the NEA Server if an organization wants to recognize the
vendor
specific messages of several AV vendors. So I think it's best to avoid
the
idea that these identifiers will be unique.

</Steve-Response>

<Kaushik-Response>

Fair point. We never intended to rule out endpoints when we used the
term
intermediary. Would the following text work

" NEA protocols MUST provide protection against active and passive
attacks
by intermediaries and other endpoints including protection to prevent
replay
based attacks. "

</Kaushik-Response>

<Steve-Response>

I'm OK with your text but find the phrase "other endpoints" confusing.
Some intermediaries may not have an IP address (like an L2 bridge). And
within the NEA Reference Model, the endpoint is generally the device
being assessed. I suggest removing the word "other" from your text.

</Steve-Response>

<Kaushik-Response>

</Kaushik-Response>

<Steve-Response>

OK, I'll start a separate thread.

</Steve-Response>

---

From: Kaushik Narayan <[email-masked]>
Date: Sun, 24 Jun 2007 22:20:16 -0700

Hi Steve,

Please find my response inline tagged <Kaushik-Response-II>

<snipped>

> idea that these identifiers will be unique.

<Kaushik-Response-II>

I am not completely clear about your comment since within a NEA
server/client the Posture Broker (client/server) will use these identifiers
to distinguish between different posture validators/collectors.
 
Anyway, I think we can avoid the term "unique identifier" given the
confusion.

</Kaushik-Response-II>

> being assessed. I suggest removing the word "other" from your text.

<Kaushik-Response-II>

I included the term "other endpoint" since I wanted to clarify that we won't
be addressing attacks initiated within the same endpoint, i.e. Attacks on
the NEA client by other processes within the same endpoint.

I will avoid the use of the term "other" since it is confusing and try to
clarify this explicitly.

regards,
  kaushik

</Kaushik-Response-II>