Subject: [Nea] comments on draft-ietf-nea-requirements-03.txt

From: "Nancy Winget \(ncamwing\)" <[email-masked]>
Date: Fri, 10 Aug 2007 20:30:26 -0700

In general the draft is a great improvement over the last revision.  I
still have a few comments/questions:
 
Section 2
---------
* while the PA, PB and PT are described in Section 5, it would be good
to give summary definitions to these here as they are referenced 

Section 5
----------
* The Posture Collector as described in 5.1.1.1 states:
  " Receiving attributes containing remediation instructions on 
        how to update the component(s) on the endpoint.  This could 
        require the collector to interact with the user, owner 
        and/or a remediation server."
   which seems somewhat contradictory or needs further elaboration when
   relating to the statement in the Posture Broker Client description of
5.1.1.2:
 " Providing user notification about the global assessment 
        decision and other user messages sent by the NEA Server."
 If the PB is maintaining a more "global" state, this implies that it
may  "reassess" and modify the "remediation" as provided by the server.
Or what is  meant by "global assessment" (as that result could imply
different actions versus  the collection of "individual assessments"
belonging to a particular Posture Collector.

* 5.1.1.1 states "...offering cryptographic protection to the attributes
returned."
  - protection from whom?  Is it protecting it from the layers within
the NEA client (e.g.
    Protected from the PB and PT) as it is provided by the PA? 

* 5.1.1.3 what are the threat models addressed in "providing
cryptographic protection
  for the message dialog between the NEA Client and NEA Server"?

* Figure 1 is somewhat confusing as the PA, PB and PT are drawn across
the client and server, but the descriptions infer that the PA flow from
PA to PB to PT and up back up on the other end.
While it is understood that the communication "targets" are across, the
security implications and considerations must take into account the
threats that may occur while the information is flowing through the
different nodes.  For instance, there may be multiple nodes supporting
the "NEA Server" and thus the transport between the Posture Validators
and Posture Broker (and Posture Transport Server[s]) must also be
described in the security considerations. 

* 5.1.2.1 (Posture Validator)
  "Requesting attributes froma Posture Collector".....does this mean
that the
  Posture Collector is uniquely identified within an NEA client? Or does
the client
  determine which PC to route the request to?  (this text infers the
former, but
  given the "global assessment" of the Posture Broker, it's not clear.

Section 7
----------

* C-2:  a nit, by "after the endpoint has gained normal
network"......the intent is really
  "during the endpoint's session in the network"?  

* C-4: who are the intermediaries?  Since there are multiple Posture
Collectors, Validators, Transports, there needs to be clarification on
the message flow as the flow say, between a particular Posture Validator
to Broker to Transport server are authorized.

* C-7, C-9: it would be good to quantify the "scale" and a reasonably
expected number of NEA clients and Posture Validators.  Is the scale on
the order of 100's, 1000's, 10K?

* In Section 7.2, there are many requirements for enabling the Posture
Validator.  Shouldn't there be allowance for the Posture attributes to
be sent unsolicited from the Posture Collector to the Validators as
well?

* PA-6: clarification is needed on the "end-to-end" security across an
NEA deployment.  The model in Figure 1 abstracts the layers as there may
be different deployments, and how the protection is carried out can be
dependent on the instatiation of the model.  It is not clear why the
protection needs to be a hard requirement vs. a "MAY" at this layer.

* PA-7: I can see this being true for the server side, but why is this
required on the client?

* PB-4:  "The PB protocol MAY support authentication, integrity and  
          confidentiality protection for the attribute messages it  
          carries between an NEA Client and Server. "  What is meant by 
	"NEA Client and Server", is the intent to protect a layer of
protection
       between the brokers?

* PT-6: "The PT protocol MUST be capable of supporting mutual  
          authentication between the Posture Transport Client and the  
          Posture Transport Server. This MAY occur by leveraging by- 
          products (e.g., keys) supplied by the PB protocol  
          authentication."
      I don't see how the PB protocol helps here?

Section 8.1:
  - Components can really mean components within an NEA Client or Server
and
    the "general" network components as well.  It is unclear in either
8.1 and
    8.1.1 what components are being referred to.  It would be better to
separate
    the threat models within the "NEA component" and between an "NEA
Client" and
    "NEA Server" and the rest of the network components (that are not
NEA participants).

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

---

From: "todd glassey" <[email-masked]>
Date: Sat, 11 Aug 2007 10:06:37 -0700

Nancy and Tim - (and nice post Nancy... :-)

CAVEAT and inline Apology...
--------------------------------------------
this retort is something I have been biting my tongue on for some months now
but its got to be said - This Commentary is not directed at any one person
but more the collective.

Many as individuals will probably find it directly offensive, so my
apologies for offending anyone with this post, but I believe the
reality is what it is...

NEA is not a new idea...
----------------------------------
I do have one comment and that is about the creation of new terms to
represent things which are already in use. This complicates the audit
process since now we have to equate the concept of "Posturing" to "Making
compliant to a set of policies" and while that may seem cool and neat that
we as techies came up with yet another way to explain something already in
common use, it causes huge amounts of pain in writing policies and control
statements for auditing where the requirement is that someone somewhere is
accountable in a legal sense for the system we design and that they are
forced to use by some (***idiot***) CIO.

Simply put - if NEA is a tool set that will enable the plug-in and
qualification of a node being installed into a network fabric, then that
capability already exists. So then the NEA method and process is yet another
method of skinning that cat, and there is nothing wrong with that, its just
that the IETF has a rule about reimplementing the wheel if there are already
IETF wheels in existence, and well... that seems to have been ignored here.

There are already existing protocols which ...
-----------------------------------
Also based on the availability of those other protocols that will and can do
these same types of things NEA is being designed to do,  there is no new IP
being generated here as original genesis no matter what new names we tried
to hide that under. A Posture Collector is a gateway or server which 
aggregates policy compliance information from its collective client nodes 
either as a repeater or a gateway. So its a Policy Aggregation Gateway... 
Something that has existed in firewalls now for maybe 20 years. See my 
point?

That means that Prior Art is available for all of this IP and that means 
that no patents
should be enforceable and that the Trust cannot also claim sole ownership of
the derivative rights since they already were given out to anyone for
anything in prior IETF drafts and publications as well as ones external to
the IETF. In fact there are likely infringements on other designs based
therein, so actually adopting NEA may have legal ramifications we have not
reviewed yet.

I find this to be "par for the course" though...
-------------------------------------
This isn't an idle comment - its about what is real and what is apparently
(IMHO) done in the Standards Org so that a few authors can claim to have
created something totally new. I apologize for those words, they are acerbic
but how would you describe an initiative to reinvent functions from already
existing technology into a new package? A repackaging effort? because that
is not what is happening here... people are claiming this is new genesis and
it simply isn't.

It's this same exact mindset that makes the Patent Enforcement Process a
freaking nightmare and if you have never had to deal with that, you just
'don't get it' or the pain and financial burden thereof.

That said - once again - I am for stripping out all the new terminology and
for use of much more generic terms and process descriptions in the
documents.

No end-use models make this another IETF fiasco
------------------------------------
But that aside, it is about what I expect out of the IETF... A document set
who's content has no specific defined uses or methods of implementing it
considered in the design phase.

The real problem is that a technology without uses is pure research, and
that belongs in the IRTF and not here wasting the valuable time of the
Vetting Pool Member's and their Sponsor's money.

Sponsors have no idea either...
------------------------------------
What's funny here is that I am also betting that effectively  the company's
sponsoring this effort really have no idea what they or their agents are
doing I am willing to bet. Because this type of effort without a MRD
(Marketing Requirements Documentation) would have never gotten out of their
internal blue-sky process. Thus documenting the core and fundamental
problems with letting people who are averse to actually designing
real-world-uses for their tools, play wizard.

Sorry - it is what it is - and that means that without specific end-use
requirements and a limitation to that, the NEA is really just another wasted
IETF effort in my opinion. Now if we could get some specific use models and
use criteria set up, and then code the standard to that, NEA would rock. But
until then IMHO this is more about a bunch of ego's than standards processes
because its tied to a bunch of whiney voices all crying "my vision is
right"...

----- Original Message ----- 
From: "Nancy Winget (ncamwing)" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 10, 2007 8:30 PM
Subject: [Nea] comments on draft-ietf-nea-requirements-03.txt

Section 2
---------

Section 5
----------

Section 7
----------

Section 8.1:

---

From: Alan DeKok <[email-masked]>
Date: Sun, 12 Aug 2007 10:24:21 -0400

> There are already existing protocols which ...

  Yes.

> for use of much more generic terms and process descriptions in the

  I agree.

> No end-use models make this another IETF fiasco

  I'm not sure I agree.  Similar protocols have been deployed before,
with similar use models.  Much of NEA is simply aggregating and
standardizing the previous ad-hoc collection of methods.

> ...  Because this type of effort without a MRD
> internal blue-sky process.

  There are other corporate objectives.  Excessive complexity in a
standard is a way to make it difficult for certain players to compete.
This kind of thing doesn't happen in the IETF, of course...

> requirements and a limitation to that, the NEA is really just another
> wasted IETF effort in my opinion.

  The IETF has a good track record of standardizing things that other
people invented.  It has a much worse track record of creating brand-new
standards.

  Alan DeKok.

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 12 Aug 2007 09:40:58 -0700

Alan  - I agree with most of what you were retorting, its more of an issue 
of using the NEA Effort to integrate a number of functions which were 
desinged for other protocols, into a homogenious infrastructure where the 
policy and stateful qualification of infrastructure components (including 
end-nodes and servers) is documented and controlled.

There is NOTHING wrong with that goal - its a powerful one, the issue is how 
its achieved, and what each of the key operating goals of the NEA charter 
requires.

If the goals are:

    1)    To allow for the qualification (from a stateful policy-centric 
manner) the 'admissibility' of a node into a secured or policy controlled 
network

    2)    To manage ongoing connectivity/entitlement rights from an already 
qualified node

these are somewhat different tasks. One is based on qualifying a node and 
assigning it entitlement with regard to servers, routing, and access to the 
outside world, and the other (2) is a process which uses a subset of the 
qualifying tools used in (1) as part of an ongoing 'certification' process. 
The idea that NEA could detect an infected system is a specific 
implementation of a stateful security policy, and as such its not the real 
focus, the policy control framework and its implementing layers are.

To that end the architecture of NEA needs to address the 'pre-installed 
systems' and their qualification at the level of the DHCP service probably 
and then later at the OS layer. That said I see the vision of the collector 
and policy aggregator's (local status nodes) but I dont see the language 
focusing on that per se. I main be missing the whole picture but I doubt it.

That said, NEA as a WG can justify aggregating a set of predefined services 
as primatives from other WG's and other IETF initiatives, but this coming up 
with new nomenclature to describe something that has been done before a 
number of times seems like a waste to me... and I just dont get why its 
better for the key architect's here to redesign wheel's which already exist 
under the banner of NEA...

Please forgive my acerbic response earlier but it is what it is. NEA is a 
good idea, redefining existing systems and frameworks with totally new 
nomencalture where it is not warranted, is not, and that is what my 
perception of what is going on here in NEA land is. We can use DHCP terms to 
define the client's and we can use PKIX policy terms to define the 
controlling messaging processes easily and that will eliminate the need to 
reinvent that wheel and will make those other IETF standards stronger IMHO.

just my 2 cents.

Todd

---

From: Alan DeKok <[email-masked]>
Date: Sun, 12 Aug 2007 13:03:28 -0400

TS Glassey wrote:
> manner) the 'admissibility' of a node into a secured or policy
> controlled network
> 
>    2)    To manage ongoing connectivity/entitlement rights from an
> already qualified node
> 
> these are somewhat different tasks.

  I think they're the same task.  Let me rephrase both goals into one
statement:  In order to achieve a certain level of network access, a
node has to satisfy certain criteria.

  This satisfies goals (1) and (2) above.

> One is based on qualifying a node
> and assigning it entitlement with regard to servers, routing, and access
> to the outside world, and the other (2) is a process which uses a subset
> of the qualifying tools used in (1) as part of an ongoing
> 'certification' process.

  I don't understand "ongoing".  If a device does nothing, there are few
reasons to re-certify it (other than changes in server policy).  If a
device requests different levels of access, it must be validated before
being granted that access.

  We do this today.  My laptop has a WEP key and/or an 802.1x id for
wireless access.  But I *still* have to enter a username && password to
send email.  And once if I send PGP signed email, I have a *different*
set of criteria I have to meet before the message will be signed.

> The idea that NEA could detect an infected
> system is a specific implementation of a stateful security policy, and
> as such its not the real focus, the policy control framework and its
> implementing layers are.

  Yes.

> Please forgive my acerbic response earlier but it is what it is. NEA is
> a good idea, redefining existing systems and frameworks with totally new
> perception of what is going on here in NEA land is. We can use DHCP
> terms to define the client's and we can use PKIX policy terms to define
> the controlling messaging processes easily and that will eliminate the
> need to reinvent that wheel and will make those other IETF standards
> stronger IMHO.

  I agree.

  Alan DeKok.

---

From: "Paul Sangster" <[email-masked]>
Date: Tue, 14 Aug 2007 17:41:53 -0700

Thanks for the comments, some feedback is in-lined... 

> -----Original Message-----
> From: Nancy Winget (ncamwing) [mailto:[email-masked]] 
> To: [email-masked]
> In general the draft is a great improvement over the last 
> revision.  I still have a few comments/questions:
>  
> Section 2
> ---------
> * while the PA, PB and PT are described in Section 5, it 
> would be good to give summary definitions to these here as 
> they are referenced 

This comment is similar to Tim's about using words (Posture Collector)
the reader doesn't yet know in the terminology.  We chose to define the
reference model in section 5 while having most of the terms defined up
front.  We'll review the spec and see if we can figure out how to reduce
the dependance on section 5 when reading section 2.  One option is to
move/copy the defs from section 5 into the terminology and massage
section 5 to not repeat what has already been defined too much.

>  If the PB is maintaining a more "global" state, this implies 
> that it may  "reassess" and modify the "remediation" as 
> provided by the server.
> Or what is  meant by "global assessment" (as that result 
> could imply different actions versus  the collection of 
> "individual assessments"

The component level (e.g. firewall) level assessments and remediation
instructions would go to the firewall Posture Collector.  The global
assessment goes to the Posture Broker Client as it handles the overall
decision.  So maybe its confusing but both the Posture Collector and
Posture Broker Client could receive attributes at the end of an
assessment (e.g. the Collector on how to remediate its associated
security mechanism and the Broker on the global assessment decision).
To have an integrated user interface, the Posture Broker Client
implementation may provide an interface to the Collectors for providing
remediation instructions to the user (this is outside the scope of this
doc as we're getting into implementation's detailed designs).

We'll edit the paragraph about the Posture Broker Client (para 3) to
help make this more clear.

> 
> * 5.1.1.1 states "...offering cryptographic protection to the 
> attributes returned."
>   - protection from whom?  Is it protecting it from the 
> layers within the NEA client (e.g.

Yes its providing end to end security protections.  This is more
obviously needed when the Posture Validator is remote from the Posture
Broker Server.  This enables the Posture Validator to cryptographically
authenticate the specific collector, check the integrity of the posture
received, and protect the confidentiality of the posture sent (which
might include PII or other information an attacker might use for
vulnerability scanning/fingerprinting).  We discussed this in Prague and
in prior e-mail threads.  Note that we downgraded the requirement for PB
security to a MAY.

>   for the message dialog between the NEA Client and NEA Server"?

This is discussed in the security considerations section.  The PT
security protections against passive and active attacks again the server
authentication, optional endpoint authentication, eavesdropping,
integrity of the PT, PB and PA payloads, MITM, replay, etc.   Note that
its optional to deploy PT security although one might expect this would
be common (much more so then PB security).

> 
> * Figure 1 is somewhat confusing as the PA, PB and PT are 
> drawn across the client and server, but the descriptions 
> infer that the PA flow from PA to PB to PT and up back up on 
> the other end.

These are encapsulating "protocols" (as per our charter terminology).
They are shown as horizonal protocol flows because those are the
entities that see the data exchanged.

> While it is understood that the communication "targets" are 
> across, the security implications and considerations must 
> take into account the threats that may occur while the 
> information is flowing through the different nodes.  For 
> instance, there may be multiple nodes supporting the "NEA 
> Server" and thus the transport between the Posture Validators 
> and Posture Broker (and Posture Transport Server[s]) must 
> also be described in the security considerations. 

Correct we do discuss this in security considerations section (search
for "remote", see section 8.1.3, section 8.2, 8.3.2 ...)  This is the
reason for PA security protections to be required.  With that said I
believe its out of scope for the Posture Transport Client, Posture
Broker Client and Posture Collectors to be on different nodes.
Similarly its out of scope for the Posture Transport Server and Posture
Broker Server to be on different nodes.  So we're just including the one
case which you mentioned.

>   "Requesting attributes froma Posture Collector".....does 
> this mean that the
>   Posture Collector is uniquely identified within an NEA 
> client? Or does the client
>   determine which PC to route the request to?  (this text 
> infers the former, but

We don't specify a particular PC/PV identification scheme but mention 3
possible approaches (section 5.1.1.1 P2 and 5.1.2.1 P2) that the PB
protocol candidates will need to specify how their approach works.  Of
course we require in PB-2 that the PB protocol can carry these
identifiers.

> Section 7

We've reworded C-2 in the next I-D so these words are removed.  The new
C-2 (merged with the old C-3) says:

"C-2	NEA protocols SHOULD provide a way for both the NEA Client and
the NEA Server to initiate a posture assessment or reassessment as
needed."

> 
> * C-4: who are the intermediaries?  Since there are multiple 
> Posture Collectors, Validators, Transports, there needs to be 
> clarification on the message flow as the flow say, between a 
> particular Posture Validator to Broker to Transport server 
> are authorized.

Intermediaries are discussed in section 8.1.2.  I believe this
requirement is oriented towards network-based intermediaries and not
hostile components on the endpoint.  Hostile components on the endpoint
are out of scope for NEA (see section 8.1.1).  We could edit it to say
"... attacks by network-based intermediaries and other endpoints ..." if
that makes it more clear?

> 
> * C-7, C-9: it would be good to quantify the "scale" and a 
> reasonably expected number of NEA clients and Posture 
> Validators.  Is the scale on the order of 100's, 1000's, 10K?

Suggestions on how to come up with an appropriate number that will work
for a very wide variety of potential deployments?  Text suggestions are
welcome.  We struggled with this issue as well and ultimately will
probably be part of the PB protocol submission.  For example, if the PB
protocol candidate assigns static UUIDs to each PC and PV then the
namespace needs to be very large.  If the PC and PV naming is
dynamically generated based on a per NEA Client basis then the number
can be *much* smaller (much higher then the largest number of PCs we
expect will ever be on a single node).  If the naming is based on
message content information (used in the subscription model) then a
large number is somewhere in between.  Our thinking was for the WG to
apply judgement when evaluation candidate protocols.

> 
> * In Section 7.2, there are many requirements for enabling 
> the Posture Validator.  Shouldn't there be allowance for the 
> Posture attributes to be sent unsolicited from the Posture 
> Collector to the Validators as well?

Not sure I follow, but we do allow for the Posture Collector to
proactively send Posture Attributes without the Posture Validator
requesting them.  For example, this could be by having pre-configured
client policy stating which attributes to send during a network
connection attempt to a particular NEA Server (this one is discussed in
a couple places in the spec including section 5.1.1.2 P1 and 9.2 P1-3.

> 
> * PA-6: clarification is needed on the "end-to-end" security 
> across an NEA deployment.  The model in Figure 1 abstracts 
> the layers as there may be different deployments, and how the 
> protection is carried out can be dependent on the 
> instatiation of the model.  It is not clear why the 

See feedback above and to Joe Salowey's comments about this topic.  Your
comment above highlighted why this was needed (Posture Validator on
different node from Posture Broker Server).

> 
> * PA-7: I can see this being true for the server side, but 
> why is this required on the client?

Encrypted attributes and other binary data could be sent by the client
and encrypted remediation instructions and other binary data could be
sent by the server.  The PA protocol needs to allow such data to be
transported.

> 	"NEA Client and Server", is the intent to protect a 
> layer of protection
>        between the brokers?

Yes we could be more specific here.  Will change to "Posture Broker
Client and Posture Broker Server".

>       I don't see how the PB protocol helps here?

This text was changed based on other comments but the example was
thinking about cryptographic bindings for EAP tunnels or potentially
channel bindings in other environments.  

> 
> 
> Section 8.1:
>   - Components can really mean components within an NEA 
> Client or Server and
>     8.1.1 what components are being referred to.  It would be

Same comments as above in this e-mail about trust boundaries.  

Also we hope to improve the terminology around components so NEA
components are easier to identify vs. other software components (e.g.
firewall) on the endpoint which might move to a different term.  With
that said intermediaries on the network are not referred to as
components in this spec.  Currently, components specifically part of the
NEA reference model are described as "NEA [optional qualifier]
component" or something similar ("components in the NEA system") to help
with readibility.  Section 8.1's components are about the components
within the NEA reference model.
 
> better to separate
>     the threat models within the "NEA component" and between 
> an "NEA Client" and
>     "NEA Server" and the rest of the network components (that 
> are not NEA participants).

The trust model discussions are organized this way.  Because of our
trust model for the NEA client and server components, the threats
primarily are those posed from the network to the network protocols not
intra-NEA client or intra-NEA server except for the remote Posture
Validator case.  So section 8.3.x is organized by network born attacks
which seems desired from my read of RFC 3552.

If you have some specific changes that would help improve the section,
we're happy to consider them.

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 14 Aug 2007 17:55:15 -0700

Paul - a component summary at 50,000 feet would deal with this and allow for 
the noticing of that there were numerous Terms of Art in the draft/rfc

Todd