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 21, 2006, at 1:15 PM, Alan DeKok wrote:

> Douglas Otis wrote:
> > 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.
>
>   Yes... each third party (virus scanner, etc.) would indicate the  
> scenarios under which it's validation of the clients posture is  
> OK.  But as I stated earlier, there's no need to exchange the full  
> set of certificates for every network access request.

The goal is to minimize data held within a certificate such that it  
remains possible to hold several within a single packet.  When the  
number of certificates becomes burdensome, an exchange reduction  
could be accomplished by a "caching" NEA server producing a  
certificate that reflects the client's certificates currently held.   
That seems overly complex for what is likely not a problem when  
certificates are kept to a minimum size.

> > Who is producing the certificate?  Who is offering the service?   
> > You do not want individuals to start trusting just any access  
> > point running NEA.
>
>   The charter scenario targets the enterprise space, where NEA  
> client and server are in the same administrative domain (i.e. owned  
> by the same people).  In that case, trust is irrelevant, because  
> there's only one party involved: the enterprise that owns the  
> equipment.  And the enterprise administrators are the ones  
> producing the certificates and offering the services.

Any large enterprise will host a number of guests, contractors,  
salesmen, and consultants.  These individuals should not be forced to  
trust some NEA server's profiling application.  Few will remain  
within the same environment, so NEA should consider the effects a  
compromised NEA server might have.

The NEA design should allow the entities providing services be  
trusted instead, rather than a larger number of NEA servers of  
questionable status.  Rather than assuming a work environment  
requires that one must always expose their system directly to the NEA  
server, a normal mode of operation should permit trust based upon  
those directly providing a service, such as OS updates or AV  
scanners.  Few would want to be forced to run an enterprise Brand X  
application that does who-knows-what at an administrative level.   
Working within an enterprise environment should not demand the NEA  
server itself be trusted.

>   For the case of someone visiting an enterprise with NEA, they can  
> choose to trust the NEA server and accept it's security policies.   
> Or, they can choose to not trust it, and then not obtain network  
> access.
>
> >  Service providers should be the ones offering the certificates.
>
>   The service provider space is explicitly outside of the WG charter.
>
>   Maybe you mean "services offered by third parties", as above?

The word service might cover any number of things related to securing  
the client.  OS, applications, as well as supplemental defenses-in- 
depth could be covered by the term service.  By service provider,  
this was not meant to imply an access server provider, although they  
would not be excluded either.

> Overloading the word "service" here is impractical.  And your  
> discussion mixes "service" as third party software running on both  
> the client and server, *and* as the action of doing something to  
> obtain updates.  As a result, it's extremely difficult to  
> understand what you're getting at.

What would you suggest that it be called?  How about Comprehensive  
Assessment and Remediation (CAR) service?

> > It seems impractical for an NEA server to assess thousands of  
> > details related to various services being contemplated.
>
>   Then NEA as a whole is impractical.

NEA facilitates a means to communicate with an endpoint specific  
requirements based upon generalized status contained within a CAR  
certificate.  The CAR service is well beyond the scope of the NEA  
server.  CAR certificates form a basis for NEA acceptance or  
notification.  The NEA server should not be directly trusted in  
providing CAR services however.

> >  Unless the certificate is something as simple as agreeing to an  
> > AUP, the NEA server is not really able to generate certificates  
> > directly.
>
>   I fail to understand why.  If others can produce certificates,  
> then the NEA server can produce them, too.  If others can supply  
> their certificates (i.e. posture assessment) to the NEA server,  
> then it can produce a certificate saying that it believes the  
> client is compliant at a particular date.  And the only certificate  
> that normally needs to be presented to the NEA server is the one  
> issued by the NEA server.

An NEA server could offer minimally intrusive CAR services, such as  
negotiating an AUP or caching previously exchanged certificates.  It  
seems a bad idea to add more points of trust at administrative levels  
and pose the potential for catastrophic security breaches.   
Leveraging existing trusted services would be much safer, more  
acceptable, and easier to administer.

> > 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.
>
>   Which is a scenario I explicitly described, and which my proposal  
> was demonstrated to satisfy.  I don't think you're disagreeing with  
> me, but you don't seem to be addressing my proposal.

Ensure there is a two-way negotiation of CAR services.  The NEA  
server should in essence say "pick one from each set" and then offer  
a related certificate.  For details, the Server can offer their  
certificate signed for them (i.e. hostmaster@).  These sets might be  
mandatory or simply recommended.

> > 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.
>
>   I have no idea what that means.  I haven't seem that terminology  
> explained, or used elsewhere, so it is difficult for to establish a  
> frame of reference.

Provide a clearer distinction between what a CAR provides and what an  
NEA server negotiates.  In essence, NEA adds a requirement that CAR  
services offer clients a receipt in the form of a certificate.  These  
services exist today.  With a minimal effort, these certificates can  
be exchanged indicating the results.  The NEA server is not where  
these CAR services are run without major and rather risky changes.

-Doug


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