Subject: [Nea] Comments on -01 re: nomenclature

From: Alan DeKok <[email-masked]>
Date: Wed, 21 Mar 2007 15:48:58 +0100

I find it hard to understand the document with the multiple
Capitalized Terms.  I'll restrict my comments in this message to the
attributes.

  I don't see why it's necessary to have Posture Attributes separately
from Policy Attributes, or any other type of attribute.  I agree with
the intent in the document, but the exposition is awkward.  I'll explain
my reasons, my suggested re-phrasing, and let the group decide if my
suggestions make sense.

  When I see "Posture Attributes" and "Policy Attributes", it looks to
me like they are very different things.  e.g. A statement by a client
saying "I have Manufacturer X, Product Y, Version Z" may not be the same
format or type on the wire as a statement by a server saying "you must
have Manufacturer X, Product Y, Version Z".  Since the statements
contain much the same information in both cases, I would expect that
they are formatted and/or encoded in much the same way on the wire.
This re-use simplifies the specification and implementation.

  I recognize that the *context* is different in the two cases, of
course.  We do need to distinguish the two contexts, but linking the
context to the attribute seems to me like a layer violation.

  That is, Posture statements involve attributes sent from a client to a
server (perhaps in a "posture statement" message).  Policy requirements
involve attributes sent from a server to the client.  In both cases, the
attributes may be identical.

  The discussion in the document can then be simplified.  Rather than
saying things like "the client sends Posture attributes", it can be
rephrased as "the client sends a Posture Statement".  The first phrasing
is very different from colloquial English, while the second phrasing is
both normative, and understandable as colloquial English.

  The discussion of which attributes are sent in what message is perhaps
a subject best left to later discussion.  Therefore, the requirements
document should have minimal references to attributes, other than that
they exist, and they are to be defined later.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

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

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Wed, 21 Mar 2007 10:49:27 -0700

Hi Alan,

Please find my reply inline.

<snipped>

<Kaushik> 

The Policy Attributes are intended to carry much more than statements of
expected values. The policy attributes allow for conditions and rules to
passed from the NEA server to the NEA client so that the NEA client can
perform an evaluation of the compliance policy. The format of the policy
attributes would probably be different from posture attributes.

regards,
  kaushik!

---

From: Alan DeKok <[email-masked]>
Date: Wed, 21 Mar 2007 19:18:59 +0100

Kaushik Narayan (kaushik) wrote:
> perform an evaluation of the compliance policy.

  This will not work.  This was pointed out on the list last fall, and
again in the WG meeting.

  People have been trying to express policies in an exchangeable format
for years.  No one has figured out a generic way to do it *well*.  In
many cases, policies are implemented in scripts on a server, because
there is no other way to get the functionality that is needed.

  Since policies can in the general case be expressed only as code, the
solution is obvious: represent the policies as code.  They then get
downloaded during remediation, just like new anti-virus rules, or OS
patch updates.  The only difference is that the "manufacturer" is the
administrator of the local network, who writes and maintains those policies.

  The "policy attribute" then becomes "Yes, I'm running manufacturer X,
product Y, version Z".  Which, for the network administrator, means that
the client has downloaded executed the script he wrote.

  Since network administrators can write policies this way *anyways* in
NEA, adding a complex policy language to the NEA protocol is
unwarranted.  It adds large amounts of complexity for no benefit.

  Alan DeKok.

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Wed, 21 Mar 2007 16:12:36 -0700

Hi Alan,

<snipped>

Kaushik Narayan (kaushik) wrote:
> The Policy Attributes are intended to carry much more than statements 
> of expected values. The policy attributes allow for conditions and 
> rules to passed from the NEA server to the NEA client so that the NEA 
> client can perform an evaluation of the compliance policy.

administrator of the local network, who writes and maintains those
policies.

<Kaushik> 

I am not sure that policy attributes need a syntax equivalent of a
policy language. I would prefer that we explore the requirements for
conditions/expressions to be defined and verify whether we can contain
the complexity based on the use cases before being dismissive. 

I disagree with the assessment that such capability is not beneficial, I
think the ability for clients to execute a set of compliance rules
significantly reduces the amount of data (attributes) that need to
transported to complete an assessment and thereby providing a scalable
option for NEA deployments.

regards,
  kaushik!

</Kaushik> 

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 22 Mar 2007 10:10:43 +0100

> the complexity based on the use cases before being dismissive. 

  I'm saying many people have tried to solve this problem, and they have
failed.  I would prefer to avoid re-hashing policy discussions here.  If
learning from experience is being dismissive, then so be it.

  If you think you can solve the problem, wonderful.  Write a proposal,
and the WG can review it.  But even if the proposal works, it's
unnecessary for reasons I outlined previously, and again below.

> option for NEA deployments.

  I was very clear that exchanging policies *is* beneficial.  I was very
clear that exchanging policies would reduce the amount of data needed to
complete an assessment.  The examples I gave directly addressed those
two points.

  My first point is that we don't know *how* to exchange those policies
as anything other than executable code.

  My second point is that the local site admin can write scripts that
are downloaded during remediation that implement anything, including
complex policy checks.

  Therefore, we shouldn't try to solve a problem that no one has
succeeded in solving when there is already an existing method that works.

  To put it another way, any policy conditions/expressions that you
define *could* be downloaded as part of the NEA protocol.  But, they
could *also* be downloaded as part of remediation.  I think that
downloading complex policies (whatever the form) is something better
done during remediation than during network access.

  I don't see why defining complex policy conditions/expressions is a
good idea, or why downloading those policies as part of the NEA protocol
is a good idea.

  Alan DeKok.

---

From: "Paul Sangster" <[email-masked]>
Date: Thu, 22 Mar 2007 08:58:27 -0700

Taking this topic back up a level (out of how it might work), I do think
Alan has a point about the attribute naming giving the *appearance* of
implying that a single attribute couldn't be used in multiple of the
Attribute Types which would be inefficient.  Of course the document
doesn't state that an Attribute can only be of a single Attribute Type
but it's a reasonable assumption one might make.  We could clear this up
by stating that this isn't the case or change the names and some
descriptive text.

After some thought, the issue seems to boil down to we'll likely need a
flat attribute space for expressing things and a set of (one or more)
attributes may be grouped into a PA Message for performing a particular
operation (e.g. requesting posture).  As stated 'manufacturer X product
Y version Z' might be one or more attributes we wish to use within
different types of messages to express part of a
[request,posture,assertion,claim].

If we wish to make it more clear that the flat attribute space really
isn't subsetted into Attribute Types, we could reword the I-D to talk
about attributes being including in a set of Message Types and orient
the discussions toward sending certain Message Types for requesting
Posture or alike.  We might even find that their will be a message type
field in the PA message where this gets enumerated.

If the WG finds it easier to grok the meaning of message types to
indicate the purpose of the included set of attribute we could
investigate migrating the I-D text.

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 11:19 AM
> To: [email-masked]
> Subject: Re: [Nea] Comments on -01 re: nomenclature
> 
>   This will not work.  This was pointed out on the list last 
> fall, and again in the WG meeting.
> 
>   People have been trying to express policies in an 
> exchangeable format for years.  No one has figured out a 
> generic way to do it *well*.  In many cases, policies are 
> implemented in scripts on a server, because there is no other 
> way to get the functionality that is needed.
> 
>   Since policies can in the general case be expressed only as 
> code, the solution is obvious: represent the policies as 
> code.  They then get downloaded during remediation, just like 
> new anti-virus rules, or OS patch updates.  The only 
> difference is that the "manufacturer" is the administrator of 
> the local network, who writes and maintains those policies.
> 
>   The "policy attribute" then becomes "Yes, I'm running 
> manufacturer X, product Y, version Z".  Which, for the 
> network administrator, means that the client has downloaded 
> executed the script he wrote.
> 
>   Since network administrators can write policies this way 
> *anyways* in NEA, adding a complex policy language to the NEA 
> protocol is unwarranted.  It adds large amounts of complexity 
> for no benefit.
> 
>   Alan DeKok.
> --

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Thu, 22 Mar 2007 11:54:07 -0700

Hi Alan,

<snipped>

<Kaushik> 

I understand your concern about trying to standardize expressions in the
IETF and that could be a slippery slope, I could see these expressions
being vendor/implementation specific rather than trying to specify them
in the IETF. I just want to make sure that we don't get too prescriptive
about what policy attributes can carry thereby limiting the ability of
implementations to introduce such capabilites.

Just to clarify, here is what I was thinking about when I meant
expression. A typical example would be that NEA server provides the NEA
client an "IF THEN ELSE" statement with a list of attributes and
expected values. The NEA client can  check for different posture
attributes based on different conditions being satisfied.

</Kaushik>

> I disagree with the assessment that such capability is not beneficial,

> I think the ability for clients to execute a set of compliance rules 

  Therefore, we shouldn't try to solve a problem that no one has
succeeded in solving when there is already an existing method that
works.

<Kaushik>

I am not sure about the co-relation between conditional checks executed
by the client and remediation since such checks would be very useful in
optimizing the attribute exchange during assessment (initial or
periodic).  Remediation is the process of patching a non-compliant
endpoint to bring it back to compliant state and a NEA client could go
through several assessments and not require any remediation.

regards,
  kaushik!

</Kaushik>

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 23 Mar 2007 08:05:04 +0100

Kaushik Narayan (kaushik) wrote:

> in the IETF.

  Vendors do that now.  They call it "software".

> attributes based on different conditions being satisfied.

  I understand.

> periodic).

  That's about the third time you've said that.  I don't think we're
communicating.

>  Remediation is the process of patching a non-compliant

  I understand.

  Since you're just repeating your position and I'm just repeating mine,
this discussion is at a close.  I believe I understand what you're
trying to do.  I believe my proposal addresses your goal.  I have seen
no reason why policies have to be exchanged in the NEA protocol, rather
than elsewhere.

  Alan DeKok.

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Fri, 23 Mar 2007 18:14:35 -0700

Hi Alan,

<snipped> 

>  Remediation is the process of patching a non-compliant endpoint to 
> bring it back to compliant state and a NEA client could go through 
> several assessments and not require any remediation.

  I understand.

<Kaushik>

I think we can agree to disagree on this point however I don't think our
disagreement impacts the NEA protocol requirements.

regards,
 kaushik

</Kaushik>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Mar 2007 15:56:17 +0200

>disagreement impacts the NEA protocol requirements.

I fully disagree. What Alan is asking for is to collapse Posture 
Attributes with Policy Attributes; I agree with his request and his 
logic. I have not seen a concrete example of a Policy Attribute that 
does not have an identical analog in a Posture Attribute. For every 
"I am going to want X&Y&Z" or "I demand X&Y&Z", there is an 
equivalent "I do X&Y&Z". If someone can show me a Policy Attribute 
that doesn't have an analog Posture Attribute, it would help me 
resolve this issue.

On a separate topic, I agree with Alan that Overuse Of Capitalization 
makes the document harder to read.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Wed, 28 Mar 2007 12:45:35 -0700

Hi Paul,

>
>I think we can agree to disagree on this point however I don't think 
>our disagreement impacts the NEA protocol requirements.

I fully disagree. What Alan is asking for is to collapse Posture
Attributes with Policy Attributes; I agree with his request and his
logic. I have not seen a concrete example of a Policy Attribute that
does not have an identical analog in a Posture Attribute. For every "I
am going to want X&Y&Z" or "I demand X&Y&Z", there is an equivalent "I
do X&Y&Z". If someone can show me a Policy Attribute that doesn't have
an analog Posture Attribute, it would help me resolve this issue.

<Kaushik> 

The disagreement I was referring to was whether we need the ability to
pass and evaluate expressions in a vendor specific fashion during
assessment or all of that can be done during remediation.

I think Paul Sangster started a separate thread requesting for WG input
whether we should be moving to a flat attribute space instead of typing
attributes into posture, policy, result etc. Can I infer that you favor
a flat attribute space or is your comment specifically that we don't
need to differentiate between posture and policy attributes.

regards,
  kaushik

</Kaushik>

---

From: "Paul Sangster" <[email-masked]>
Date: Wed, 28 Mar 2007 19:46:10 -0700

Changing the topic to a slightly different question again about the need
for the policy attribute type (thus changing the subject ...)

A similar general question is whether we wish to include the usage model
where the client is trusted to perform policy compliance check and
provide only the claimed result instead of actual posture information.
This usage model was the genesis for policy and compliance claim
attribute types (passing policy or references/search keywords to the
endpoint instead of requests for posture.)

We added this usage model in response to a dialog on the alias back in
Nov/Dec where a WG member wanted a model where the endpoint did not send
posture over the network.  If the WG believes we do not want this model
supported, I see no reason for the policy and compliance claim attribute
types in the spec.

However if we do want this usage, I don't yet understand the thought
that the posture and policy attribute types are identical in syntax and
semantics.  We currently talk about policy attributes as being sent
exclusively by the NEA server in order to solicit compliance claim
attributes in response.  I might envision the policies will list (at
least) some form of components identifiers and their expected value
ranges (==,<,>,!=).  Attribute in the policy attribute type might also
just list keywords or URI to guide the NEA Client to select the policies
expected to be met (instead of including them in the PA messages.)  

Attributes in the posture attribute type are sent only by the NEA Client
in response to request attributes and would include component
identifiers and actual values reflecting the system configuration.  This
might actually be a subset of the attribute space which falls in the
policy attribute type space, but they have a different general semantic
(e.g. firewall version is 1.2.3 vs. firewall version must be > 1.1).
Maybe this would be less of a concern if we changed our class (think
category) naming to message types instead of portions of the attribute
space which would overlap.  People seemed to be confused about the fact
that its ok for particular attributes might exist in multiple categories
(AKA attribute types).  If we leave the naming we will make this more
clear.

Attribute types are a level of abstraction above the individual
attribute level.  We're not talking at that level in this I-D (that's
another RFC we'll produce when we work on PA's contents.) Each attribute
type (as they are currently) just describe the classes (or category
based on role) of a portion of the attribute space.  Its fine for us to
define specific attributes that fall within each attribute type (they
aren't intended to be proper subsets of the full attribute space just a
name for talking generally about their role in the reference model).

So a question for the WG:

Do we want to document a usage model where the NEA Server sends "policy"
to the NEA Client such that it can respond with only the client's claim
of the results of the posture comparison with the "policy"?

If no, this seems to allow Policy and Compliance Claim Attribute Types
to be removed for the I-D.

If yes, we'll need to resolve original thread.

Paul

> From: Paul Hoffman [mailto:[email-masked]] 
> Sent: Monday, March 26, 2007 6:56 AM
> To: [email-masked]
> Subject: RE: [Nea] Comments on -01 re: nomenclature
> 
> I fully disagree. What Alan is asking for is to collapse 
> Posture Attributes with Policy Attributes; I agree with his 
> request and his logic. I have not seen a concrete example of 
> a Policy Attribute that does not have an identical analog in 
> a Posture Attribute. For every "I am going to want X&Y&Z" or 
> "I demand X&Y&Z", there is an equivalent "I do X&Y&Z". If 
> someone can show me a Policy Attribute that doesn't have an 
> analog Posture Attribute, it would help me resolve this issue.
> 
> On a separate topic, I agree with Alan that Overuse Of 
> Capitalization makes the document harder to read.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Mar 2007 19:54:26 +0100

> provide only the claimed result instead of actual posture information.

  The client is already doing that.  If it reports that it's anti-virus
software is at version X, you're already trusting it to report that
correctly.  You might was well trust it to run a complex policy, and
report compliance with policy version X.

> supported, I see no reason for the policy and compliance claim attribute

  I think the use model there was to send *nothing* of posture
information over the network.  e.g. The client collects a bunch of
opaque tokens from local anti-virus software (etc.), and sends them to
the server.  Anyone watching this exchange, including the client, has no
information about what those tokens mean.

  Those tokens can have meaning to the anti-virus software on the
client, and the corresponding product on the server side.  There is no
need for those tokens to have meaning for anyone else in the network.

> ranges (==,<,>,!=).

  Many IETF WG's have devolved into endless discussions based on what
people can "envision".  Can we talk about practical use-cases, instead?
  With examples?

  My vision is this:  The NEA server says that the client must comply
with policy version X.  That policy may include multiple sub-policies
(e.g. one for each anti-virus product, etc.).  Those sub-policies say
the same thing, that the product must comply with policy X, subsection Y.

  The client either returns proof that it is compliant, or claims
non-compliance (where no proof is necessary).  To me, this model
satisfies the NEA charter and requirements.  It also means that the
policy and posture attributes are the same:

	policy = "YOU MUST DO ..."
		attributes = "X, Y, Z"
	posture = "YES, I DO ..."
		attributes = "X, Y, Z"

>  Attribute in the policy attribute type might also

  That presumes a certain use model.

> identifiers and actual values reflecting the system configuration.

  While this would be simple, it's not strictly necessary.  The protocol
could include a CHAP-like system that proves both ends know the same
values, without actually exchanging those values over the network.

>  This

  To use that exact example to prove my point:

	policy: firewall version must be > 1.1
	posture: firewall version is > 1.1

  Even with that example, I don't see a need to exchange *different*
information.  Why is the client returning "1.2.3" when the server asked
for "> 1.1"?  Why not just return "yes", or even "> 1.1"?

> space which would overlap.

  Yes.  To re-iterate, DNS, DHCP, RADIUS, etc. all do this.  They've
done it for over a decade.  It's common practice.

> name for talking generally about their role in the reference model).

  I'm not sure I understand that paragraph.

> If yes, we'll need to resolve original thread.

  I'm not sure the question targets the discussion.

  The discussion was about sending complex policies with conditional
statements, which is unnecesary.  Sending policy *requirements* like
"prove you do X, Y, and Z" is a completely different story.  Those
requirements can be trivially described and encoded.

  Sending such requirements means that the policy and posture attributes
become the same, but they're just carried in different messages.  And
there's no need for compliance claim attributes, because the posture
attributes fulfill that role.

  Alan DeKok.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Mar 2007 15:33:56 -0700

>	posture = "YES, I DO ..."

At least Alan and I were thinking the same thing when we spoke at the 
mic last week. This is what I was thinking as well.

--Paul Hoffman, Director
--VPN Consortium

---

From: Alan DeKok <[email-masked]>
Date: Fri, 30 Mar 2007 09:58:27 +0200

My original message was private to Paul, and he responded similarly.
I'll respond publicly, to move the discussion back to a public forum.

Paul Sangster wrote:
[ re: opaque posture tokens]
> Not sure I follow the "nothing" yet we're exchanging info over the
> network.  From who's perspective are we sending nothing?  This sounds
> like the collectors create posture tokens that get sent to the peer
> validator who can also understand them.  Parties in between don't need
> to know what they contain.

  Yes.

> Do you mean by "nothing" that the opaque tokens do not contain
> information about the posture of the system?  This sounds alittle bit
> like the Assertion Attribute Type which I could see as a valid usage
> model (one that NAP plans to support.)

  Yes and no.  The tokens contain information that the validator can use
to prove posture, but which no one else can use to determine posture.

> I used that word because we haven't defined what policy attributes look
> like yet and I'm personally not sure we need them unless there is a
> usage model requiring them.  I could propose a real world example but
> would rather hear someone argue that we need this.

  My higher-layer question is this: Do we want to validate that the
client satisfies the policy, or do we want to determine what the posture
of the client is?

  Those are two very different questions.  If the client satisfies the
policy, the details of its exact posture do not matter.  This simplifies
the protocol and deployment scenarios.

> What your calling posture above is what the spec calls compliance claim
> attribute type.  Posture provides "proof" instead of making claims about
> compliance to a particular policy.  However your description sounds
> about right for the policy/compliance claims exchange.

  I see what you mean.  I'm curious to know what "proof" means in the
context of lying endpoints.  I suspect that the posture and compliance
claim attributes collapse into one.

> Correct and I'm hoping to find out if anyone cares about this usage
> model.  This example is interesting as it might allow for
> pre-provisioned (or downloaded) policy which is indexed by keywords and
> the NEA server just sends keywords indicating which policies need to be
> met.  This isn't really very different from your example just the syntax
> changes.

  It's exactly the point I was trying to get across in earlier
discussions.  If the method you outline above is available, almost all
of the NEA protocol can disappear.  All that is needed is:

	server -> client : Comply with policy X
	client -> server : proof of compliance (or claim of compliance)
...
> Again just a wording thing that "posture" is "complaince claim"
> attribute type in the spec.

  I think the common understanding of posture is close to what the spec
calls "compliance claim", and the common understanding of "proof of
posture" is what the spec calls "posture".

  i.e. The posture of the client is independent of the policy.  The
client has a particular posture, and the purpose of NEA is to convince
the network that the clients posture satisfies the policy.

  Everything else works towards that goal.  Confusing "posture" with
"proof" or "claim" results in complications.

>...  It sounds like you
> believe we need to support the assertion attribute type model (e.g.
> signed tokens asserting some compliance statements.)  Do you think we
> need to support the sending of policy to the client, or just the request
> attribute type model ('tell me about your firewall configuration?')?

  I don't think we need request attributes.  I don't think we need to
send policy to the client.  I think we just need to tell the client
which policy to run.

> But to comment on what you said I don't see how that solves the complex
> policy problem.  The "X" in your quote could be "your symantec firewall
> must be > version 1.1" and "Y" could be "your symantec AV must be
> running user-level rootkit protection with signatures newer than
> 01/01/07".  So I don't see how this eliminates conditional statements.
> It might also be that "Y" is "OR you can run the windows firewall
> version 0.5" allowing choice of firewall vendor/version.

  In case I haven't been clear, I would strenuously avoid *any* kind of
conditional expressions in the NEA protocol.  I believe that there are
other methods of achieving the same result that are simpler and more robust.

> If we drop policy attribute type we can also punt on policy expression
> which is a big plus for moving forward.  But if we need to provide an
> interoperable way to download policy and policy is contained in the
> standard attributes we are opening that box.

  How is downloading of policies different than downloading of any other
software update?

  Experience shows that if we define conditional policy statements in
the protocol, those conditions will quickly explode into a full-fledged
language.  Or, the discussions around the feature set of the language
will never end.

  My conclusion, then, is that we should avoid such rat-holes, and
discard any requirement to do conditional policies.

  Alan DeKok.

---

From: Frank Yeh Jr <[email-masked]>
Date: Fri, 30 Mar 2007 03:35:53 -0700

Greetings,

      IMHO there is no need for the server to inform the client of what it
"MUST" do. The client can simply report what it is doing and the server can
compare that against what it thinks the client must do, and make the
admission decision on the server.

      Giving the client granular descriptions of what states must be met to
attain access is a rather large security hole IMHO.

Regards,
Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

             Paul Hoffman                                                  
             <paul.hoffman@vpn                                             
             c.org>                                                     To 
                                       [email-masked]                        
             03/29/2007 03:33                                           cc 
             PM                                                            
                                                                   Subject 
                                       Re: Policy Attribute Type (split    
                                       from [Nea] Comments on -01     re:  
                                       nomenclature)                       

                                                                           

--Paul Hoffman, Director
--VPN Consortium

---

From: Alan DeKok <[email-masked]>
Date: Fri, 30 Mar 2007 14:48:57 +0200

Frank Yeh Jr wrote:
> "MUST" do. The client can simply report what it is doing and the server
> can compare that against what it thinks the client must do, and make the

  What information is the client supposed to report to the server?  The
extremes range from nearly nothing (IP / MAC / hostname), to sending its
complete disk image.

  i.e. There has to be some method of bootstrapping the clients
knowledge of what the server cares about.

  That information can be exchanged as part of NEA, or bootstrapped via
some offline method.

> attain access is a rather large security hole IMHO.

  But the client already has that information.  Anti-virus software
includes lists of "bad" content.  The client therefore knows that it
must pretend to not have any of that "bad" content before gaining access.

  Alan DeKok.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Mar 2007 06:50:36 -0700

At 3:35 AM -0700 3/30/07, Frank Yeh Jr wrote:
>	IMHO there is no need for the server to inform the client of 
>what it "MUST" do. The client can simply report what it is doing and 
>the server can compare that against what it thinks the client must 
>do, and make the admission decision on the server.

Agree. But there is still a requirement that the server be able to 
inform the client what kind of information the server wants. 
Otherwise, we have the case that Alan describes where the client 
might have to send a ton of unneeded information.

Stated another way, the requirements are:

- Server MUST be able to send request for information to the client.

- Server MUST accept whatever posture the client sends.

- Client MAY send posture to the server without knowing what th server wants.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Paul Sangster" <[email-masked]>
Date: Fri, 30 Mar 2007 08:26:05 -0700

This sounds like your preference is to only support the Request and
Posture Attribute Types usage model and to not include the Policy and
Compliance Claim Attribute Types (don't send policy to the client and
ask it to claim whether it meets the policy.)
 
Do others feel the same about this?

________________________________

	From: Frank Yeh Jr [mailto:[email-masked]] 
	Sent: Friday, March 30, 2007 3:36 AM
	To: Paul Hoffman
	Cc: [email-masked]
	Subject: Re: Policy Attribute Type (split from [Nea] Comments on
-01 re:nomenclature)

	Greetings,
	
	IMHO there is no need for the server to inform the client of
what it "MUST" do. The client can simply report what it is doing and the
server can compare that against what it thinks the client must do, and
make the admission decision on the server.
	
	Giving the client granular descriptions of what states must be
met to attain access is a rather large security hole IMHO. 

	Regards,
	Frank Yeh

	 Paul Hoffman <[email-masked]>

				Paul Hoffman <[email-masked]> 

				03/29/2007 03:33 PM

To

[email-masked]	

cc

Subject

Re: Policy Attribute Type (split from [Nea] Comments on -01 re:
nomenclature)	

	> posture = "YES, I DO ..."
	
	At least Alan and I were thinking the same thing when we spoke
at the 
	mic last week. This is what I was thinking as well.
	
	--Paul Hoffman, Director
	--VPN Consortium

---

From: "Paul Sangster" <[email-masked]>
Date: Fri, 30 Mar 2007 08:30:56 -0700

> Sent: Friday, March 30, 2007 6:51 AM
> To: [email-masked]
> Subject: Re: Policy Attribute Type (split from [Nea] Comments 
> on -01 re: nomenclature)
> 
> >can compare that against what it thinks the client must do, and make 
> >the admission decision on the server.
> 
> Agree. But there is still a requirement that the server be 
> able to inform the client what kind of information the server wants. 

This is the purpose of the Request Attribute Type (defines what the
server needs to perform the compliance comparison.)  

So it sound like you would also like to not include the Policy and
Compliance Claim Attribute Type model (send policy to client and ask it
if it is compliant)?

> Otherwise, we have the case that Alan describes where the 
> client might have to send a ton of unneeded information.

Agreed (this topic is discussed in the privacy considerations section in
hopes of causing some WG discussion.)  This model seems inefficient and
not privacy sensitive.

> - Client MAY send posture to the server without knowing what 

Sounds reasonable although I wonder if we even need the last one (fodder
for group discussion).  Since it's just a MAY this seems acceptable.

---

From: Frank Yeh Jr <[email-masked]>
Date: Fri, 30 Mar 2007 08:33:10 -0700

Greetings,

      Sorry for the confusion_ I just read my previous email and I don't
even understand it!

      What I meant to say was that I think the server should be able to ask
the client for the information it wants but it does not necessarily have to
tell the client what the required values are for any attribute. EG What are
the antivirus S/W release level and def file date? The server than compares
the returned values against the required ones and makes the decision. This
model is probably most straightforward but it will generate the most
network traffic.

      If we allow the client to know what the required values are for the
attributes in question, then the client really should not have to send back
any state information at all, just a binary compliance state. EG Is the A/V
release level equal to 3.1 and the def file date > 01/01/07, to which the
client basically replies with a yes or no. This model is not a
straightforward as it allows the client to simply report compliance to gain
entrance. It is more scaleable across constrained network links and places
less load on the server, but it requires a higher level of Trust in the
client stack. So something like the TCG's Trusted Computing Model would
have to be used to provide confidence that the client was not tampered
with.

      I don't think there are any other models that make sense.

Regards,
Frank Yeh

                                                                           
             Paul Hoffman                                                  
             <paul.hoffman@vpn                                             
             c.org>                                                     To 
                                       [email-masked]                        
             03/30/2007 06:50                                           cc 
             AM                                                            
                                                                   Subject 

                                                                           

- Client MAY send posture to the server without knowing what th server
wants.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Paul Sangster" <[email-masked]>
Date: Fri, 30 Mar 2007 09:07:32 -0700

> Sent: Friday, March 30, 2007 5:49 AM
> To: Frank Yeh Jr
> Cc: [email-masked]; Paul Hoffman
> on -01 re:nomenclature)
> > "MUST" do. The client can simply report what it is doing and the 
>   What information is the client supposed to report to the 
> server?  The extremes range from nearly nothing (IP / MAC / 
> hostname), to sending its complete disk image.
> 
>   i.e. There has to be some method of bootstrapping the 
> clients knowledge of what the server cares about.

The server could ask the client for component information it cares about
(using attributes of the Request Attribute Type.)

> 
>   That information can be exchanged as part of NEA, or 
> bootstrapped via some offline method.

Yes, the group could decide to support a model where in effect the
request attributes are pre-provisioned on the endpoint or we could just
say the server requests what it needs each time.

>   But the client already has that information.  Anti-virus 
> software includes lists of "bad" content.  The client 

I presume your refering to the AV product specific policy defs which
define "signatures" the AV uses to recognize "bad" content.  Not sure
this is useful for anything outside the AV product.

> therefore knows that it must pretend to not have any of that 
> "bad" content before gaining access.

I think his point was not wanting to trust the client to manage (keep up
to date), protect and properly report compliance to an enterprise's
policy.  This adds more complexity to the NEA Client which increases the
likelihood for bugs, vulnerabilities, ...  Also, not sending to the
client requests including both: "what is the version of the XYZ
component" and "i'm looking for an answer of 1.0" which makes it trivial
to write a non-cooperating NEA Client that just repeats the desired
answers instead of reporting its current posture information.

If we stay out of expressing the expected result (compliance policy)
then we can avoid the complexity of policy expression and how we make
that interoperable.  This seems helpful but at the cost of always
sending posture information across the network (unless a prior assertion
can be re-used which is a different usage model.)

---

From: Alan DeKok <[email-masked]>
Date: Fri, 30 Mar 2007 18:13:12 +0200

Frank Yeh Jr wrote:
> the client for the information it wants but it does not necessarily have
> to tell the client what the required values are for any attribute. EG
> What are the antivirus S/W release level and def file date? The server
> than compares the returned values against the required ones and makes
> the decision. This model is probably most straightforward but it will
> generate the most network traffic.

  Even that has privacy implications.

> attributes in question, then the client really should not have to send
> back any state information at all, just a binary compliance state.

  Some level of proof would be better than just a blind compliance
claim.  e.g. a challenge/response method that proves the client knows
about a particular A/V release.

> ... It is more scaleable across constrained network links and
> places less load on the server, but it requires a higher level of Trust
> in the client stack. So something like the TCG's Trusted Computing Model
> would have to be used to provide confidence that the client was not
> tampered with.

  I'm not familiar with that, so I'll have to look into it.

  I think it's easy to prove that the client has a copy of a particular
piece of software.  It's more difficult to prove that the client is
running the software.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 30 Mar 2007 18:18:34 +0200

Paul Sangster wrote:
...
> this is useful for anything outside the AV product.

  It's still an example of policy that is known by the client.

> likelihood for bugs, vulnerabilities,

  Yes.  But any complex policy is just... running more software.  We
already have a model where the client downloads & runs software (A/V, OS
updates, etc.).  What's the cost of one more download?

> ...  Also, not sending to the

  Yes.

  Yes.

  Alan DeKok.