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 19, 2006, at 12:12 PM, Keith Moore wrote:

> > > I suppose that begs the question of how NEA clients learn the  
> > > profiles
> > > that they need to evaluate.
> >   I think it's "via the remediation network, which is outside of the
> > scope of NEA".
>
> not clear.  at least the format of the profiles needs to be  
> standardized, IMHO, otherwise there's no capability for  
> interoperation and no point to having an NEA standard.

It seems the entire exchange could be an exchanging certificates.   
The provider offers certificates in sets, 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.

The black-box would be the service.  The standardization would not  
need an elaborate profile, as this should be handled by the service  
as a means to retain privacy regarding the perhaps thousands of  
details involved.  These certificates could be broken down into sets,  
such as OS patches, AV solutions, Network configuration, etc.  The  
provider can decide what they find to be important by presenting both  
mandatory and option sets of certificates.  The user could then be  
allowed to interact to select those certificates that pertain to  
their system, as well as which services they are willing to accept.

The "profile" could be a simple status field entered into the  
certificate classifying a level of conformance achieved.  There  
should be error codes to indicate which field has not been accepted,  
such as the time-stamp or the classification.  Within the  
certificates, the status/classification result should provide  
adequate information upon which the provider could then make  
decisions on acceptance.

> >   The server should decide if the clients profile is out of date.
>
> on that much we agree.  the question is how the client gets the new  
> profile.  I don't like having the answer be "via the remediation  
> network" because I think the whole concept of a remediation network  
> is architecturally dubious.  it might be fine for now but is not  
> IMHO something we want to base a standard on.  it also seems to me  
> that some networks will not want to provide remediation but will  
> want to use NEA and that NEA should still be able to provide a  
> definite answer.  that implies to me that the profile downloading  
> should be able to happen via NEA, rather than introduce a situation  
> where NEA can't tell whether a client is trustworthy or not because  
> the client doesn't have a current profile.
>
> I also suspect that we're going to need to put some limitations on  
> how frequently a profile can be changed in order to limit the  
> potential for NEA to be used as a means of extracting arbitrary  
> information from a client.  If the server can keep changing the  
> profile that's about as bad as allowing the server to iterate queries.

By indicating specifically what is required for a particular service,  
either the client or the provider could open their firewalls enough  
to allow these services to run.  The protection is really found by  
knowing exactly what is needed. How the barriers are erected depends  
upon who feels threatened.  Others sharing the network may wish to  
have the provider impose the barriers, but that is largely due to the  
current state.  This state could be dramatically improved when using  
NEA to impose upon problematic clients a need to achieve compliance  
within a reasonable timeframe.

-Doug


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