Subject: RE: [Nea] REQ: sections <= 2

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Mon, 5 Mar 2007 05:40:46 -0000

Paul wrote...

> We wanted to call out when we were using a defined term vs. the generic
> equivalent (roughly equivalent of SHOULD vs should.)  Since we use a
> few
> commonly used words (e.g. Message, Component ...) with a special
> meaning
> we thought it was important to be clear what was intended.  For
> sections
> that are prior to the terminology section we didn't wish to use defined
> terms (since they weren't defined yet) and instead stick with generally
> known wordings.  Another WG member already pointed out that we missed a
> few terms that were used in the abstract (which is fixed in -01.)

Perhaps the underlying issue here is not as much the capitalization (which
is symptomatic of the issue), but the choice in terminology.  Could better
choice of terms assuage the need to capitalize? 

> >
> > Section 2 specific comments
> > 1. How exactly do policy attributes differ from posture
> > attributes?  It's unclear to me because of the claim in the
> 
> Policy Attributes describe or reference policies that the Endpoint must
> meet to be considered compliant ("must have <vendor> firewall running
> at
> least version 1.2.3").  These are sent by the NEA Server (will add text
> to mention this.)
> 
> Posture Attributes includes Posture information about a requested
> Component (Firewall installed, version 1.5, Firewall running, ...)  The
> Posture Validator compares this information to its policy to determine
> compliance.  These are sent by the NEA Client.

Ah...so if I this understand correct, policy attributes are used to carry
just references to some [named] policy, while posture attributes are
explicit posture values.  To use a programming analogy it's the case of pass
by reference vs. pass by value. 

If my understanding is correct, then I would suggest that the document
describe the fact that policy attributes require the pre-population of
policy in endpoint.  Otherwise, the policy attributes will likely reference
policy that has no particular meaning to the endpoint.  This also brings up
the question of just how far we expect to standardize policy attributes.
While it may not be too difficult to reach consensus on attribute syntax,
agreement on semantics, in particular how policy references should be
interpreted, may be difficult. 

> > definition of policy attributes that states that policy
> > attributes can be used to establish compliancy without
> > divulging posture information.  Isn't the exchange of policy
> > and compliance attributes in fact a form of posture
> > information exchange.
> 
> I presume you mean Policy and Compliance Claim Attributes.  In some
> sense you could argue this but we felt it was important to be more
> clear
> about the different types of attributes as they have differing
> security,
> privacy and operational properties.  We found these names very helpful

I agree, but again I point out the statement, "...Policy Attributes might be
used to enable an NEA client to determine whether the Endpoint is compliant
without disclosing Posture information..."  Don't you agree that policy and
compliance claim attributes in fact do disclose indirectly posture
information?  I see where the design team is going with policy attributes,
but probably went too far in asserting that posture attributes don't
disclose [any] endpoint posture information. 

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

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 5 Mar 2007 14:00:47 -0800

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, March 04, 2007 9:41 PM
> To: Paul Sangster; [email-masked]
> Subject: RE: [Nea] REQ: sections <= 2
> 
> Paul wrote...
> 
> > We wanted to call out when we were using a defined term vs. the 
> > generic equivalent (roughly equivalent of SHOULD vs 
> should.)  Since we 
> > use a few commonly used words (e.g. Message, Component ...) with a 
> > special meaning we thought it was important to be clear what was 
> > intended.  For sections that are prior to the terminology 
> section we 
> > didn't wish to use defined terms (since they weren't 
> defined yet) and 
> > instead stick with generally known wordings.  Another WG member 
> > already pointed out that we missed a few terms that were 
> used in the 
> > abstract (which is fixed in -01.)
> 
> Perhaps the underlying issue here is not as much the 
> capitalization (which is symptomatic of the issue), but the 
> choice in terminology.  Could better choice of terms assuage 
> the need to capitalize? 

I think the issue is the ability for the reader to easily identify which
words that are defined terms (so reviewing the terminology section might
help if a point is hard to understand.)  The fact that we defined a few
commonly used words as terms might add to people's confusion so we could
discuss selecting other analogous terms if that helps.

> attributes?  
> > > It's unclear to me because of the claim in the
> > 
> > Policy Attributes describe or reference policies that the Endpoint 
> > must meet to be considered compliant ("must have <vendor> firewall 
> > running at least version 1.2.3").  These are sent by the NEA Server 
> > (will add text to mention this.)
> > 
> > Component (Firewall installed, version 1.5, Firewall running, ...)  
> > The Posture Validator compares this information to its policy to 
> > determine compliance.  These are sent by the NEA Client.
> 
> Ah...so if I this understand correct, policy attributes are 
> used to carry just references to some [named] policy, while 
> posture attributes are explicit posture values.  To use a 

Correct

> programming analogy it's the case of pass by reference vs. 
> pass by value. 

Not sure the analogy is a perfect fit as call by reference means the
data is provided via a reference rather than explicitly (on the stack).
In this case the Policy information describes (possibly via reference)
what the desired situation should be and the Posture information
describes exactly what the current situation is.

> 
> If my understanding is correct, then I would suggest that the 
> document describe the fact that policy attributes require the 
> pre-population of policy in endpoint.  Otherwise, the policy 

I don't think we're requiring pre-population.  The Policy Attributes
might contain the policy or it might as you mention include keywords
intending to locate the policy or it might have a more general reference
to the policy (e.g. URI).  We're not being overly precise as the WG will
define the specific syntax/semantics of these attributes later but we
did want to allow the policy to be encoded in the attributes or be
available via reference (e.g. if they are large and/or the link is
bandwidth constrained.)

> attributes will likely reference policy that has no 
> particular meaning to the endpoint.  This also brings up the 
> question of just how far we expect to standardize policy attributes.
> While it may not be too difficult to reach consensus on 
> attribute syntax, agreement on semantics, in particular how 
> policy references should be interpreted, may be difficult.

This is certainly something the WG will need to discuss.  The notion of
passing policy to the Endpoint and asking for its assessment of
compliance is something that came up on the NEA alias so we wanted to
accommodate that model but the WG should consider what level of
specification is appropriate.
 
> attributes 
> > > can be used to establish compliancy without divulging posture 
> > > information.  Isn't the exchange of policy and compliance 
> attributes 
> > > in fact a form of posture information exchange.
> > 
> > clear about the different types of attributes as they have 
> differing 
> > security, privacy and operational properties.  We found these names 
> > very helpful
> 
> I agree, but again I point out the statement, "...Policy 
> Attributes might be used to enable an NEA client to determine 

Note that it says "NEA Client" not "NEA Server".

> whether the Endpoint is compliant without disclosing Posture 
> information..."  Don't you agree that policy and compliance 
> claim attributes in fact do disclose indirectly posture 
> information?  I see where the design team is going with 
> policy attributes, but probably went too far in asserting 
> that posture attributes don't disclose [any] endpoint posture 
> information. 

They don't directly include posture information.  I think you mean that
a party might be able to infer some amount of posture information based
on what policies/claims are also observed.  Yes, some amount of
inference is possible if a party can see both the policy information
(actual policy rules) and the claim.  How much information can be
learned depends on the granularity of the policy (e.g. the policy might
state 'you must run a firewall' and the compliance claim says 'yes, I'm
running a firewall').  Not much is learned about the specific firewall
(vendor, version, policies, ...) but sending posture attributes are
likely to be more precise as it could state these exact values.

We'll consider a reword of "without disclosing" in the definition to
something more specific to inclusion within the attributes such as
"without explicitly including" (we weren't intending to cover inference
just what was included in the attribute values.)  Does this help?