Hi -
On 10/31/2016 11:45 PM, Ludwig Seitz wrote:
On 2016-11-01 01:41, Randy Presuhn wrote:
Hi -
On 10/31/2016 7:25 AM, Renzo Navas wrote:
...
The need for a secure source of time is getting clearer on ACE (either
that, or mechanisms to assure freshness of each transaction), and we
hope that with this protocol we are giving the first step to come up
with a constrained-resource friendly solution.
...
Along the way to SNMPv3, we learned that a full-blown time
protocol isn't actually necessary to provide authentication,
timeliness, replay protection, etc. See RFC 3414 for details
on how to get these properties cheaply, both from protocol
overhead and processing perspectives.
Randy
Does your "etc" include expiration of access tokens?
The standard access control model (VACM, RFC 3415) does not
rely on "access tokens" - what is (and is not) allowed is
determined the currently configured permissions on the system
whose information is being accessed / modified / published,
and the authenticated identity of the user/entity to which the
information is being delivered or by which it is being modified.
This may or may not meet your needs. The SNMP design was driven
in part by a requirement for things to work correctly even when
large portions of the internet infrastructure (such as NTP,
PKI, DNS, etc.) were malfunctioning, broken, or under attack,
and to work on systems with minimal (from the perspective
of the late 1980s and extending into the 1990s) capabilities.
Again, this might not be necessary here. It does seem, however,
that what seems like a shortcut here or there can have large
impacts on the ultimate complexity and technology footprint
of a design...
Randy
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
