Subject: RE: [Isms] FW: Open issues from SSHSM

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Thu, 13 Oct 2005 11:00:09 -0700

Hi David,

Please find reply inline (used tag <Kaushik>)

Regards,
  kaushik!

<snipped>

I have converted a number of [todo] markers to [discuss] markers in the
latest revisions of SSHSM, because we need to reach consensus on some
issues. I expect to publish another revision before the deadline.
I numbered the markers in the text for easy correlation to the issue
discussions.

*** When discussing these issues, please use the provided # in the
subject line, and please limit the message to one topic at a time. ***

Here is the current list of issues from the SSHSM document where we need
to reach consensus. 

#1: is it important to support anonymous user access to SNMP?

<Kaushik>

Is this support for backwards compatability with noAuthNoPriv. If we do
deprecate the authoritative engine notion within SNMPv3, we should be
able to get away from engine discovery for SSHSM which is the most
prevelant use of noAuthNoPriv.

I recommend that we do not support anonymous user access unless
absolutely required.

</Kaushik>

#2: a) is server authentication a requirement that SNMP will require of
the client? 

<Kaushik>

I think this is an artifact of a TMSM, I don't think we really have an
option. 

	b) how can we verify that server authentication was performed,
or do we take simply trust the SSH client layer to perform such
authentication?

<Kaushik>

We have to trust the SSH layer. Any  TMSM not just SSHSM will need to
trust the transport layer to perform server authentication and key
negotiation.

	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?

<Kaushik>

I had mentioned this in my previous note, SSHSM does create the need to
manually provision public keys on clients until we have X.509 support
(or GSSAPI is being used). SSH client implementations in interactive
mode will verify the key by echoing it to the user  and saving the key
once the user accepts. We cannot do that with SSHSM and we either
require manual provisioning of server public keys or accept blindly the
first time, which make it suscepitble to mitm.

#3: we need some text contributed to discuss the implications of
sessions on SNMP.

<Kaushik>

What specifically are you looking at. I can certainly contribute text
that talk about how existing USM based management systems will be
impacted once we move a session based model.

#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?

<Kaushik>

I think #3, #4 & #5 could make a section that talks about impact of
introducing session based security to SNMP, I think this should be in
broader spec (may be applicatability document).

#6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM?

<Kaushik>

None that I can think especially with USM since SSHSM (or TMSM) will be
a separate security model with independent credentials.

#7: is there still a need for an "authoritative SNMP engine"? 

<Kaushik>

Based on previous discussion on thread, we might consider dropping this.

#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? 

<Kaushik>

I think we should think about using/mapping the identity of the SNMP
engine to the SNMP engine ID, this will be particularly useful when you
have multiple SNMP engines on the same host (single SSH server). The
engine ID would  be used for server identity, client like a NMS sending
out a SET will be represented by a client identity and need to
authenticate via client credentials such as passwords, user public keys
etc.

#9: Can an existing R/R session be reused for notifications?

<Kaushik>

I certainly hope we consider the possibility since SSH does allow
multiple channels to be created within a session.

We do need to consider the following issue. In the case of a R/R
channel, the client is a NMS user that authenticates to the SSH server
on the agent, the server authenticates via it's public key. The agent
(SNMP engine) will authorize the requests based on that user. In case of
notifications, we will need the agent (notification originator) to
authenticate the NMS host identity via it's public key and provide
client identity (configured username)and credentials to authenticate
itself to the NMS (Notification reciever). The principals that are
authenticated in either direction are not symmetric and we might need to
consider whether they can be mapped to allow a channel for NMS to agent
to be reused for agent to NMS.

#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 all msgSecurityParameters, should the
msgSecurityParameters field in the SNMPv3 message simply be a
zero-length OCTET STRING, or should it be an ASN.1 NULL?

#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? 

<Kaushik>

I think this is a TMSM issue, we need to talk about how to ensure that
the underlying transport is providing the level of security requested by
the SNMP engine. 

#13: 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? 

<Kaushik>

Not sure about this question, since mutual authentication is part of the
SSH specification (server authentication part of the SSH transport and
client authentication part of the SSH authentication.

#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?

#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?

<Kaushik>

I think the mapping (if any) of the username authenticated by SSH to a
SNMP securityName MUST be within the SNMP subsystem. It is not anything
we need SSH or the authentication systems to deal with. 

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 machanisms can use it as a
hint?

<Kaushik>

This will constitute SNMP specific behavior within RADIUS and other
authentication/authorization systems.

#17: I believe somebody suggested we require mutual authentication.
I'm not sure I understand the edits. 

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

#20: How do we get the mapping from model-specific identity to a model
independent securityName?. 

<Kaushik>

Isn't this a variant of #16. 

#21: we need to determine what data should be persistent and stored in
the LCD for notification purposes.

<Kaushik>

Shouldn't we be able to use the same notification data in LCD from USM.
This would primarily be the configured user and credentials for the
notification originator

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

#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

#24: How should we enable auto-discovery?

#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?

#28: For notification tables, how do we predefine the dynamic session
identifiers? 

#29: do we need to support reports? For what purpose?

#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?

#32: For an incoming message, is using a default securityName mapping
the right thing to do?

<Kaushik>

Isn't this a variant of #16. 

#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?

David Harrington
[email-masked]

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms