1 / 13

SSHSM Issues

SSHSM Issues. David Harrington IETF64 ISMS WG Vancouver, BC. SSHSM vs SSH.

dale-benson
Download Presentation

SSHSM Issues

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. SSHSM Issues David Harrington IETF64 ISMS WG Vancouver, BC

  2. SSHSM vs SSH • #2: a) is server authentication a requirement that SNMP will require of the client? b) how can we verify that server authentication was performed, or do we take simply trust the SSH client layer to perform such authentication? c) for the common case of DH signed by public keys, how does the client learn the host's public key in advance, and verify that the correct key is being used? • #8: Do we need a mapping between the SSH key (or other SSH engine identifier) and SNMP engineID? What happens if an agent "spoofs“ another engineID, and an NMS perfoms a SET of sensitive parameters to the agent?

  3. SSHSM vs SSH • #12: a) how does SSHSM determine whether SSH can provide the security services requested in msgFlags? B) There were discussions about whether it was acceptable for a transport-mapping-model to provide stronger security than requested. Does this need to be discussed in the SSHSM document, or should we discuss this in the TMSM document? c) when sending a message into an environment where encryption is not legal, how do we ensure that encryption is not provided? • #13: How will SSHSM be impacted by keychanges to the SSH local datastore? • #14: MUST the SSHSM model provide mutual authentication of the client and server, and MUST it authenticate, integrity-check, and encrypt the messages? • #15: What data needs to be stored in the tmStateReference, and how does SSHSM get the information from SSH, for the various authentication and transport options?

  4. SSHSM vs SSH • #16: The SSH server doesn't necessarily authorize the name carried in the SSH_MSG_USERAUTH_REQUEST message, but may return a different name or list of names that are authorized to be used given the authentication of the provided username. A) What should be the source of the SSHSM mechanism-specific username for mapping to securityName? • #20: How do we get the mapping from model-specific identity to a model independent securityName?

  5. SSHSM vs SSH • #18: I currently have multiple sections, one for each known auth mechanism. We need to discuss the parameters that need to be cached for each, and determine whether we can collapse this into one section. a) Using Passwords to Authenticate SNMP Principals B) Using Public keys to Authenticate SNMP Principals C) Using Host-based Authentication of SNMP Principals D) Using RADIUS to Authenticate SNMP Principals • #19: RADIUS is just an instance of the password authentication protocol. The details of RADIUS are within the SSH layer. I don't think it is a good idea to expose this outside of SSH. • #32: For an incoming message, is using a default securityName mapping the right thing to do?

  6. Sessions • #3: we need some text contributed to discuss the implications of sessions on SNMP. • #23: We need to discuss the circumstances under which a session should be closed, and how an SNMP engine should determine if, and respond if the SSH session is closed by other means • #25: Where is the best place to call establishSession()? See the "Sending an Outgoing Message to the Network" section for more details on this issue. • #26: According to RFC 3411, section 4.1.1, the application provides the transportDomain and transportAddress to the PDU dispatcher via the sendPDU() primitive. If we permit multiple sessions per transportAddress, then we would need to define how session identifiers get passed from the application to the PDU dispatcher (and then to the MP model). • #27: The SNMP over TCP Transport Mapping document [RFC3430] says that TCP connections can be recreated dynamically or kept for future use and actually leaves all that to the transport mapping. Do we need to discuss these issues? Where? in the security considerations?

  7. SSHSM vs RADIUS • #16 B) passing a securityname might be useful for passing as a hint to RADIUS or other authorization mechanism to indicate which identity we want to use when doing access control, and RADIUS, etc. can tell us whether the username being authenticated is allowed to be mapped to that authorization/accounting identity. Should we provide securityName when establishing a session, so the authentication mechanisms can use it as a hint?

  8. SSHSM vs USM • #7: is there still a need for an "authoritative SNMP engine"? • #10: a) which securityparameters must be supported for the SSHSM model? b) Which services provided in USM are needed in TMSM/SSHSM? C) How does the Message Processing model provide this information to the security model via generateRequestMsg() and processIncomingMsg() primitives? • #11: If we eliminate msgSecurityParameters, should the msgSecurityParameters field in the SNMPv3 message simply be a zero-length OCTET STRING, or should it be an ASN.1 NULL? • #29: do we need to support reports? For what purpose?

  9. SSHSM vs USM • #30: If we actually do not extract anything from securityParameters,do we need to check whether this field parses correctly? • #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once for the session? Do we need to take into consideration the SSH window size? • #6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM?

  10. Notifications • #9: Can an existing R/R session be reused for notifications? • #21: we need to determine what data should be persistent and stored in the LCD for notification purposes. • #28: For notification tables, how do we predefine the dynamic session identifiers?

  11. SSHSM or TMSM? • #4: Should the SSHSM document include a discussion of the operational expectations of this model for use in troubleshooting a broken network, or can this be covered in the TMSM document? (Either way, we could use some contributed text on the topic) • #5: Should the SSHSM document include a discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine, or can this be covered in the TMSM document, or in an applicability document?

  12. Text Needed • #17: I believe somebody suggested we require mutual authentication. I'm not sure I understand the edits. • #22: Joe: There are a significant number of security problems associated with mapping to a transport address which may need to be discussed in the security considerations section.

  13. New Features • #1: is it important to support anonymous user access to SNMP? • #24: How do we enable auto-discovery? • #33: does the mib need to be writable, so sessions can be preconfigured, such as for callhome, or would it be populated at creation time by the underlying instrumentation, and not writable by SNMP?

More Related