RE: [Isms] securityName

["Fleischman, Eric" <eric.fleischman at boeing.com>]

Tom,

I concur with your analysis. However, additional issues are whether the
application level, which is SNMPv3 USM/VACM in this case, uses the same
authentication credentials as the transport layer security (e.g., TLS,
SSH, DTLS) or not.

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.

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). 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.

Alternatively, we could integrate the transport layer authentication
with the application layer authentication. 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

From: Tom Petch [mailto:nwnetworks at dial.pipex.com] 
<snip>
>Every xSM should be passed the same parameters 
>and return the same values, as per the ASI in the 
>SNMPv3 Architecture.  Trouble is, when security 
>is done at transport level (SSH, TLS), the security 
>is best done before ever the PDU gets to the message 
>processing subsystem so its calls, eg to get the PDU 
>decrypted, are somewhat meaningless.  So for me, 
>the architecture does not allow for transport level 
>security and so needs flexing or changing; I don't 
>see this as a problem, others do.  Likewise, the 
>transport level knows what authentication has taken 
>place, who the 'principal' is; no way to pass this 
>on - the security model is expected to produce it out 
>of a hat from the msgSecurityParameters for the message 
>processing subsystem whereas, with transport level 
>security, the security parameters are no longer in the 
>SNMP PDU but part of the SSH/TLS header.
<snip>

_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms