RE: [Isms] securityName
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Isms] securityName
Hi Eric,
> My own belief is that security can be enhanced if transport-layer
> authentication, which is used to create transaction privacy via TLS,
> SSH, or DTLS, is distinct from application layer authentication.
This
> permits a virtual two-factor authentication-like system by having
the
> transport layer leverage "what you have" credentials or Radius
lookups
> or whatever and the application layer use "what you know"
> passwords, or
> their symmetric key constructs such as what SNMPv3 currently
enables.
I hear you asking for enhancements but not working to develop them.
Your desired solution is only waiting for some author to write it,
Eric.
I hereby formally invite you to do so.
>
> This means that it is theoretically possible to "bolt on" a standard
> (modern) transport layer security addition to SNMPv3, and
> fully benefit
> from its transport privacy provisions, and still maintain the
historic
> SNMPv3 authentication system untouched, except perhaps for its
privacy
> provisions (unless we want redundancies there).
You can do that now; you don't need ISMS to achieve that.
> Of course, we still
> would have the historic SNMPv3 symmetic key distribution problem
about
> which I've complained repeatedly, but my complaints would be
addressed
> if a secure standards track key distribution system would be
> defined for
> SNMPv3. After all, SNMPv3 currently supports AES today, if
> only we could
> securely distribute those keys.
That desired solution is only waiting for some author to write it,
Eric.
I hereby formally invite you to do so.
>
> Alternatively, we could integrate the transport layer authentication
> with the application layer authentication.
That's what some us believe is the solution to pursue and we've
stepped up to write the documents to make it happen.
> My reading of the mail list
> is that the latter is what the WG is presuming, but if we go that
way
> then we really need to define how USM/VACM can handle novel-to-USM
> concepts such as asymmetric keys. The latter are the issues
> that I have
> been worrying about.
>
> --Eric
>
David Harrington
dbharrington at comcast.net
_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.