1 / 18

ISMS IETF72

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

bob
Télécharger la présentation

ISMS IETF72

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ISMS IETF72 David Harrington

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

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

  4. Transport Subsystem

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

  6. Transport Security Model

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

  8. SSH Transport Model

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

  10. Open Issues • Predictability of securityName/identity mappings

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

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

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

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

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

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

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

  18. Thank You • Questions?

More Related