ISMS IETF72 David Harrington

Status IETF72 Transport Subsystem for the Simple Network Management Protocol (SNMP) –IETF69: draft-ietf-isms-tmsm-09.txt –IETF72: draft-ietf-isms-tmsm-12.txt Transport Security Model for SNMP –IETF69: draft-ietf-isms-transport-security-model-05.txt –IETF72: draft-ietf-isms-transport-security-model-08.txt Secure Shell Transport Model for SNMP –IETF69: draft-ietf-isms-secshell-08.txt –IETF72: draft-ietf-isms-secshell-11.txt

Status IETF72 WGLC started following ietf69: –draft-ietf-isms-tmsm-09.txt –draft-ietf-isms-transport-security-model-05.txt –draft-ietf-isms-secshell-08.txt

Transport Subsystem

draft-ietf-isms-tmsm-12.txt Compatibility with SNMPv3, RFC2119 and RFC4181 Security considerations for v1/v2c co-existence Updated architectural diagrams and ASIs Same security for request/response Moved comparison with USM to TSM document IANA duplicate registries fixed

Transport Security Model

draft-ietf-isms-transport-security-model-08.txt Compatibility with SNMPv3, RFC2119 and RFC4181 Added tsmLCD MIB Differentiated requested/actual securityLevels Eliminated all mention of sessions from TSM

SSH Transport Model

draft-ietf-isms-secshell-11.txt Compatibility with SNMPv3, RFC2119 and RFC4181 Added sshtmLCD MIB Differentiated requested/actual securityLevels Notification originators act as SSH client Op considerations about client key distribution Session cleanup to prevent reuse security hole Resolved#8: TM cannot specify SM

Open Issues Predictability of securityName/identity mappings

Open Issues #2,3 Admins need to configure user-specific policies into the VACM MIB and Target MIB and Event MIB using securityName. The (possibly multi-step) transform to/from a specific transport-security mechanism from/to a securityName must be predictable An admin must be able to predict what the securityName will be for a given principal authenticated by a security mechanism, and which security identity will be used for a given securityName.

Open Issue #2a – incoming TM SSHTM does not have predictability in generating tmSecurityName from the various security mechanisms SSH can use. SSH provides a required “user name” field, but makes the content optional, so we cannot rely on the value of “user name” to construct a predictable transform. We could require that for SNMP usage, only mechanisms/implementations that provide predictable “user name” content be used.

Open Issue #2b – incoming SM TSM does not have predictability in mapping from tmSecurityName to securityName We could state that securityName must be set to the value of tmSecurityName to make this predictable. Problem: different TMs could automatically generate the same tmSecurityName for different principals

Open Issue #2c – incoming SM Problem: Different TMs might generate the same tmSecurityName for different principals Proposal: add a mapping table in TSM to map SSH::tmSecurityName and TLS::tmSecurityName to different securityNames (and allow mapping different tmSecurityNames to a single securityName) These are extra features, with extra complexity, requiring admin pre-configuration This might be handled in the SSH and TLS configurations rather than in an SNMP-specific solution

Open Issue #2a – outgoing TM SSHTM does not have predictability in mapping tmSecurityName to the various security mechanisms SSH can use, including session identifiers.

Open Issue #2b – outgoing SM TSM does not have predictability in mapping from securityName to tmSecurityName We could state that tmSecurityName must be set to the value of securityName to make this predictable.

Open Issue #3c – outgoing SM Problem: Different TMs might utilize the same tmSecurityName for different principals or sessions Proposal: add a mapping table in TSM to map different securityNames to SSH::tmSecurityName and TLS::tmSecurityName and/or session IDs These are extra features, with extra complexity, requiring admin pre-configuration This might be handled in the SSH and TLS configurations rather than in an SNMP-specific solution

Thank You Questions?