Subject: RE: NEA requirements (was Re: [Nea] Re: use of a design team to developrequirements)

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 18 Dec 2006 16:51:57 -0500

>> I have assumed that the network could require information
>> to allow access.
>
> What kind of information?  Why?  What will the NEA
> server do with that information once it receives it?

NEA server probably couldn't care less for what kind
of information it is transferring. Policy-driven.

As long as there is NEA agent (or clent) on the 
supplicant machine, it can pass whatever info it
deems right.

So practically - as long as either the NEA client
or the relevant plug-in that talks to it, can get
the information that the server requests - that 
piece of data will cross the wire. 

> When I work through the various scenarios,
> I don't see much use for queries.

Whether there is a "chatter", is unclear. 

Perhaps NEA server will be able to mention everything it 
wants in one request, and the client might be able to 
pack all the data into one response. Or perhaps NEA
client will just shove everything it can get about
the system and send it in one bunch, without being
specific - in response to a generic request.

Perhaps based upon the first response to small and generic query, 
the server will choose to send more specific queries to learn 
about some particulars of the client machine.

>> The user could also refuse to provided certain information. 
>> The result on the network side might be to allow only access
>> to a remediation network. 

An old example: "Customer doesn't have to provide his 
Social Security number, the bank doesn't have to grant 
the loan." :-)

>> The result on the user side might be to only allow
>> the user to connect to a particular web site. 
>> The point is that policy exists at both places.
>
> Of course.

What's that "second place" where the policy exists?

>> The value of queries  to at least some people is the
>> reason for the wg.
>
> That's nice.  Do you have *concrete* examples that
> we can talk about?

Me too :-)

Do you mean a small set of generic posture attributes that 
every host is supposed to carry? 
Regardless, it doesn't seem to be the main focus of this WG. :-)

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Dec 2006 14:03:18 -0800

> specific - in response to a generic request.

  What I see is something along the following lines:

Client -> Server: I'm client FOO
Server -> Client: I'm network BAR
Client -> Server: Here's my posture information for BAR
...

> about some particulars of the client machine.

  Again, I don't see a need for this.  Ever.

> What's that "second place" where the policy exists?

  The client.  It can be configured to tell network A one thing, and
network B another.

  e.g. It tells my workplace that its virus scanner is up to date, but
doesn't tell my broadband provider that information.

> Regardless, it doesn't seem to be the main focus of this WG. :-)

  It seems so.  I would like to start off knowing use-cases, scenarios,
and the intent of the administrator.  From that, we determine what
information is needed in order for the administrator to make an informed
decision.  We then determine how to design a protocol that carries that
information.

  i.e. *concrete* use-cases.  "Assessing posture" is a nice phrase, but
I don't know how it translates to real-world decisions.

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

---

From: Khaja Ahmed <[email-masked]>
Date: Mon, 18 Dec 2006 14:36:49 -0800

I think the approach that Alan outlines is a pretty reasonable one. I
too see no reason for a query/response based protocol.  In fact a query
response based protocol is only likely to add needless complexity and
make the scheme susceptible to abuse.  

Based on the identity of the network, the machine will communicate the
state necessary to gain (or be denied) admission.  With appropriate key
management and federated trust mechanisms in place the information can
also be encrypted so only authorized networks can get / see the
information.  

Khaja

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Monday, December 18, 2006 2:03 PM
To: Blumenthal, Uri
Cc: [email-masked]
Subject: Re: NEA requirements (was Re: [Nea] Re: use of a design teamto
developrequirements)

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Dec 2006 16:05:02 -0800

On Dec 18, 2006, at 2:36 PM, Khaja Ahmed wrote:

> I think the approach that Alan outlines is a pretty reasonable one.  
> I too see no reason for a query/response based protocol.  In fact a  
> query response based protocol is only likely to add needless  
> complexity and make the scheme susceptible to abuse.
>
> Based on the identity of the network, the machine will communicate  
> the state necessary to gain (or be denied) admission.  With  
> appropriate key management and federated trust mechanisms in place  
> the information can also be encrypted so only authorized networks  
> can get / see the information.

Agreed.  The information exchanged could represent a set of time- 
stamped certificates.  Information contained within the certificates  
would be the provider and resources used.  The client's version of  
the certificate would also indicate the status of the service.  The  
NEA protocol could be limited to just the broker advertising in sets  
of desired or required certificates offering their certificates  
carrying their identity of "[email-masked]" as the entity  
making the request.  Having a current certificate for each required  
set should satisfy any acceptance requirement.  When a certificate is  
lacking, the resources and the provider of the certificate and  
related service will be apparent.  The resources can be verified  
prior to invoking any service related to remediation or questioning  
prior to obtaining a fresh certificate.

This approach should make it easy to implement a scheme suitable for  
autonomous devices, or client systems that will likely closely  
approximate an autonomous system.  The requested service might be as  
simple as acknowledging the provider's AUP and their current status  
when dealing with humans.

-Doug