Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements)

[Douglas Otis <dotis at mail-abuse.org>]

On Dec 20, 2006, at 3:20 PM, Alan DeKok wrote:

> Douglas Otis wrote:
> > It seems the entire exchange could be an exchanging certificates.   
> > The provider offers certificates in sets,
>
>   Why sets?  Why not just one certificate?

Assume services might be offered by various third-parties.  There is  
a likelihood a service might work for one OS and not another.  By  
indicating the type of service and the suitable OS within each  
certificate, the user could then select a service that is both  
compatible and acceptable.

There could be mandatory sets, and optional sets.  In the case of  
optional sets, these could be seen as advertisements of recommended  
services.  Even within an enterprise environment, it is extremely  
common for laptops from individuals outside the enterprise to seek  
access.  It should not be assumed that everyone uses Windows or  
MacOSX.  Linux and FreeBSD are also fairly common, depending upon the  
nature of the work.  Within the IETF, this list will be even larger.   
It seems eating one's own dog food provides a good basis for judging  
requirements.  Can IETF meetings utilize NEA?

> We can presume that NEA client policy updates are much rarer than  
> network connection requests (i.e. posture assessments).  In that  
> case, the client can be issued a certificate for a particular  
> network once it has downloaded the latest set of updates.  That  
> certificate may then be used for repeated posture assessments.

Who is producing the certificate?  Who is offering the service?  You  
do not want individuals to start trusting just any access point  
running NEA.  Service providers should be the ones offering the  
certificates.  Each service may need to update on a regular basis.   
Each service may represent a large diversity of service providers.

> i.e. the NEA server issues the client a certificate that validates  
> a particular posture (or set of provider certificates).  Once  
> that's done, the client only has to present one certificate to the  
> NEA server, rather than a set.

It seems impractical for an NEA server to assess thousands of details  
related to various services being contemplated.  Unless the  
certificate is something as simple as agreeing to an AUP, the NEA  
server is not really able to generate certificates directly.  The NEA  
server must delegate assessments to trusted organizations able to  
properly determine the state of the client.  The NEA server does not  
need to know these details, nor is that really desired.  The NEA  
server indicates which services they both trust and expect to have  
been completed by the client.  The NEA server may also recommend  
services as well.

> When the NEA server decided that it has new updates available, it  
> can compare the date of "last known update" to the "client  
> certificate issue date".  If the clients certificate was issued  
> before the last update, then the client needs remediation.   
> Otherwise, the client doesn't need remediation.  The process then  
> repeats.

The NEA server might know that service X has a critical update  
available at time Y.  The NEA server could then reject certificates  
that might make the client prone to a zero-day exploit.  Being able  
to tell the client to open specific resources and obtain a specific  
service would be one method that NEA might help prevent non- 
compromised systems from being compromised.  Certificates should be  
consider simply an end-product of completing some service.  There  
might be many services needed to support a possibly vast array of  
systems and uses, even within an enterprise environment.  The NEA  
would list these Certificates by reference and allow the client to  
request the host's version of the certificate when needed.  (This  
would be a rare event.)

> Similarly, if the client notices that updates are available, it can  
> invalidate it's own certificate (i.e. by not using it), at which  
> point the NEA server will ask it to perform remediation, and then  
> issue a new certificate.

I don't see that as part of the NEA service.  Most of these types of  
services are already done routinely.  There might be cases where this  
routine needs to be changed in the face of a new zero-day exploit.   
It can also help large organizations better track problematic  
systems.  There have been embarrassing situations where some system  
within an enterprise becomes compromised, and this machine must be  
physically found to correct the situation.  Knowing the nature of the  
problem might allow targeted services aimed at resolving specific  
issues.  They happen far too often to not be considered.

> > perhaps by reference based upon a service URI, OS, and service  
> > name, where clients then request and verify a producer of the  
> > certificate which may be some third-party.  Within the  
> > certificates held by the provider, there should be a time-stamp,  
> > their identity (perhaps hostmaster@), the type of service  
> > providing the certificate, suitable OS, and resources needed to  
> > obtain the service that in the end generates a certificate for the  
> > client based upon the client's identity.
>
>  Yes, although it's not clear what provider posture information (if  
> any) needs to be available to the NEA server.

The posture information would be in the form of a service completion  
classification.  This completion classification might be "Server-OS  
updated".  The information conveyed could be extremely general, and  
yet offer all that is needed when deciding acceptance.

-Doug


_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea