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

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Mon, 2 Apr 2007 15:02:42 -0700

Hi All,

I am not sure that this thread was summarized but I think atleast those
who responded to this thread feel that we should have a model wherein
the NEA client is always instructed by the NEA server about the
information (attributes) it is required to provide. The only
optimization that was suggested was where the NEA server can pass an
expected value and the client can assert instead of passing back the
specific value. 

I think as a design team we tried to use the attribute classes to
describe the existing implementation models, i.e. NEA client centric
(policy attributes & compliance claim attributes),  NEA server centric
(request, posture & result attributes) & assertions. The suggestion is
to stay away from such specificity and at the PA layer define a flat
attribute space similar to say RADIUS/Diameter. We could further attempt
to simplify the model by describing the protocol between each individual
collector and validator as a generic challenge/response utilizing a set
of attributes and the each validator determines the posture decision at
the end of this exchange. 

I just want to confirm with responders on this thread that this summary
is accurate and would request other members of the WG to respond in case
they have differing views.

regards,
  kaushik

-----Original Message-----
From: Paul Sangster [mailto:[email-masked]] 
Sent: Friday, March 30, 2007 9:08 AM
To: Alan DeKok
Cc: [email-masked]
Subject: RE: Policy Attribute Type (split from [Nea] Comments on
-01re:nomenclature)

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]]
> Sent: Friday, March 30, 2007 5:49 AM
> To: Frank Yeh Jr
> Cc: [email-masked]; Paul Hoffman
> Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 
> re:nomenclature)
> 
> 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.
> 
>   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.

> 
> > Giving the client granular descriptions of what states must
> be met to
> > 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

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.)

> 
>   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
> 

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

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