======================================================= Integrated Security Model for SNMP WG (isms) IETF 72 Dublin Thursday, July 31, 2008, 1510-1610 Taken by Juergen Schoenwaelder, Dave Shield ======================================================= Chair: Juergen Schoenwaelder Agenda: 1) Agenda bashing, WG status ( 5 min) 2) Discussion of transport subsystem draft ( 5 min) 3) Discussion of transport security model draft (20 min) 4) Discussion of SSH transport model draft (20 min) 5) Discussion of RADIUS draft ( 5 min) 6) Review of milestones and action points ( 5 min) Documents: - Transport Subsystem for the Simple Network Management Protocol (SNMP) - Transport Security Model for SNMP - Secure Shell Transport Model for SNMP - Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models - Simple Network Management Protocol (SNMP) Context EngineID Discovery - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management - Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP) - Datagram Transport Layer Security Transport Model for SNMP Actors: JS = Juergen Schoenwaelder DH = David Harrington JH = Jeffrey Hutzelman JO = Joseph Salowey WH = Wes Hardacker PE = Pasi Eronen BW = Bert Wijnen DN = David Nelson KN = Kaushik Narayan ... Summary: The ISMS WG has four WG documents: the Transport Subsystem for SNMP , the Transport Security Model for SNMP , the Secure Shell Transport Model for SNMP , and the Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models . The open discussion points mainly concern the Transport Security Model and the Secure Shell Transport Model documents and in particular the mappings of the identity used by secure transports (e.g. SSH user names) to the SNMPv3 securityName. There has been good progress during the meeting and on the mailing list to resolve these issues and the goal is now to get revised documents into WG last call in September and to the IESG in November. Discussions: 1. Agenda and WG Status JS reviews the status of the WG documents. Most documents are in a good shape. The open issues concern the Transport Security Model (TSM) and SSH Transport Model (SSH-TM) documents. Two documents related to ISMS WG documents in the OPSAWG and the RADEXT WG have already gone to the IESG. 2. Discussion of Core ISMS Drafts DH started by reviewing the changes that were made to the documents following the last call that took place around IETF-69. See his slides for a summary of the changes. Issue: Predictability of securityName The securityName of an incoming message must be predictable for the VACM/Target/Event MIB modules to work properly. - Incoming Messages: SSH supports several user authentication protocols and it was discussed to what extend we can assume that the SSH user name is filled in and provide the authenticated identity. PE and JH explained that GSSAPI provides an empty SSH user name since the server is expected to infer the user name from the credentials. After discussion, it was concluded that we can make the assumption to get a suitable user name from SSH. Further discussion centered around the mapping of the authenticated user name to a tmSecurityName. JO asked whether the differentiation should be done based on the protocols or by the credentials provided? DH explains that we deliberately decided to not pass up in the SNMP stack details how authentication has been performed or which credentials were used. PE suggests that there might be TM specific mappings and WH confirms that for DTLS, there should be a DTLS specific way to map a certificate into a user name. Finally, the tmSecurityName must be mapped to the SMNP securityName, either by a simple identity transform or a more complex mapping through a mapping table. DN asked whether it is sufficient to point out the issue? WH and JH explained that this approach might not work because network operators likely have no control over the names used in existing authentication and PKI infrastructures. So the problem needs to be dealt with. - Outgoing Messages: For outgoing messages, the SNMP securityName must be mapped to a tmSecurityName for a selected transport model and then the transport model must map it to security model specific identities and associated credentials. KN asks (similar to DN) whether we make up a problem here, adding complexity for some corner cases. JH responds by mentioning that he has a friend named Root who has lots of fun when he asks for a user name. Ignoring the problem is likely going to backfire. PE explains that in the case of outgoing notifications, the SSH transport mapping needs an internal mapping mechanism since the security name used by SNMP for access control might not necessarily be the user name used to establish the SSH session for transporting the notification. JH explains the SSH user name for notifications is actually the notification receiver's name for us, which likely is different from the SNMP securityName. One possible solution is to have names in the SSH transport address. During the discussions, the following observations were made: a) Some transport mappings (TMs) _must_ provide TM specific mapping capabilities. For example, TLS/DTLS transports must deal with certificates and identities that do not fit into the securityName constraints. b) If we were to require mapping capabilites in all TMs, we might in theory not _need_ a mapping capability at the security model (SM) layer. c) However, even if all TMs do support a TM specific mapping capability, it might be more efficient in terms of configuration complexity to map at the SM layer instead of mapping at all TMs involved. d) We can assume that SSH provides to us a suitable user name that does not need a specific mapping. For SSH authentication mechanisms such as GSSAPI, we can assume that SSH internally maps into a user name that can be used outside of SSH. e) Ignoring naming conflicts (identical names used by different secure transports with different meanings) is not an option since operators can not be expected to have control over authentication infrastructures. The recent prefix mapping proposal posted by WH seems to be a reasonable compromise for a workable solution. The details need to be worked out on the mailing list since the ISMS meeting slot does not provide enough time for this. 3. Discussion of the RADIUS Draft JS presents some slides provided by DN, who could not attend the IETF in Dublin. The remaining open issues are editorial in nature and the next version of the document addressing these issues should be ready for WG last call. 4. Wrap Up It was agreed to have revised core ISMS documents in September resolving the open issues and going to WG last call. Any issues coming up during WG last call should be resolved in October so that the revised documents can go to the IESG in November.