Re: NEA requirements (was Re: [Nea] Re: use of a design teamto developrequirements)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NEA requirements (was Re: [Nea] Re: use of a design teamto developrequirements)
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 "hostmaster at example.com" 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
_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.