Subject: [Isms] FW: Open issues from SSHSM

From: "David B Harrington" <[email-masked]>
Date: Wed, 12 Oct 2005 13:57:43 -0400

Hi,

I sent this out yesterday, but I haven't seen it on the list and it's
not in the archive.

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2005 8:54 AM
To: [email-masked]'
Subject: Open issues from SSHSM

Hi,

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

#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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Oct 2005 16:35:13 +0200

Dave,

Here are my answers to some of your questions.  YMMV.

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

Are you referring to unauthenticated or anonymous?

> #2: a) is server authentication a requirement that SNMP will require

I'm not sure what you mean here, but if you mean that the client should 
verify the server identity as part of SSH session initiation, 
absolutely.  Consider Wes' simple implementation.  The SNMP subsystem 
doesn't even get invoked until long after this happens.

> or do we take simply trust the SSH client layer to perform such

You trust the underlying layer to do its job.

> correct key is being used?

I don't see how this happens other than out of band, but perhaps I don't 
understand the available public ASIs well enough.

> #3: we need some text contributed to discuss the implications of

Happy to help.  Let's grab some time at IETF after the WG, tho, so it 
follows from discussion of these points.

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

Potentially.  See below.

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

It is not clear to me why you would need this given that SSH is 
responsible for security.

> another engineID, and an NMS perfoms a SET of sensitive parameters to

In other words, the IP address to engine id mapping is broken or there 
is some man in the middle attack.  The spoofing agent is not likely to 
get this far via SSHSM because the underlying layer will have blown up 
due to failure to match the DH key.  If the attacker had access to the 
manager via other means, then perhaps the mapping could be considered 
broken.  But what would those other means be?  Perhaps a broken USM key 
with DES56?  In this case, perhaps there is a potential negative 
interaction between USM and SSHSM?

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

For obvious reasons I think this is a great idea (and visa versa - an 
existing notification session should be used for R/R).  Once a 
connection is established so long as authorization requirements are met 
the connection should be reused.  This will limit if not completely 
prevent the problem I described regarding traversing a firewall for one 
use but not being able to get back for the other.

> #13: will SSHSM be impacted by keychanges to the SSH local datastore?

I presume you mean "How will SSHSM...".  Of course the next session 
started should make use of the key change as appropriate.  There's 
always the question of what to do with an existing session.

> and server, and MUST it authenticate, integrity-check, and encrypt the

It should be capable of doing so.  Your question is should it be capable 
of not doing so?  There is always v2c, you know...

> I'm not sure I understand the edits.

You should get that by default with SSH, and would have to work hard to 
not get it.

> think it is a good idea to expose this outside of SSH.

I agree.  We would like to be able to support other forms of password 
verification.  Perhaps the real test is whether Kerberos authentication 
works.

> independent securityName?.

How about a table in a MIB?  Seriously, it would help should we choose 
to do call home later.

> the SSH session is closed by other means

Ok, I have two answers to this.  Take your pick.

Answer one:

  - the device that initiated the connection should initiate the close.
    It presumably knew why it initiated the connection and will know
    when it is done.

  - let it be a matter of configurable policy.  In some environments
    a long lived connection may be advisable while in other environments
    a short lived one so.

> "Sending an Outgoing Message to the Network" section for more details

You need some separation of establishSession() from individual requests. 
  For one, if a connection has failed you want to retry no more than 
some period+e lest you DDOS the other end.

> discuss these issues? Where? in the security considerations?

Somewhere along the way it has to be made clear who can (re)use a 
connection.  RFC 3430 didn't have this problem because individual PDUs 
were authenticated and authorized.  Perhaps this is some of the session 
wording you request above?

> #32: For an incoming message, is using a default securityName mapping

If by this you mean that ssh username = securityName by default, seems 
like a reasonable plan.  But see above.

> creation time by the underlying instrumentation, and not writable by

Can't say just yet until we answer some of the above questions in more 
detail.

Eliot