 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
David Harrington wrote:Hi Pasi, Iam not certain that I have addressed all your issues. Can you please check the latest rev? comments inline.The one thing that's still slightly unclear is how tmStateReference cache entry gets created on SSH client side (e.g. command originator). In particular, Section 5.2, step 1, seems to assume that it always gets a tmStateReference. But when the Dispatcher on e.g. command generator (acting as SSH client) calls sendMessage for the first time, it doesn't have a tmStateReference yet? (Or if it does have a tmStateReference, where did it come from?)
In the expected case, it comes from TSM, in paragraph 4.2(2) of draft-ietf-isms-transport-security-model-10.txt.
However, modularity demands that SSHTM work even when not used with TSM, and particularly, section 6.1 of draft-ietf-isms-tmsm-15.txt implies that the sendMessage ASI needs to work even when tmStateReference is not given.
My guess is that Section 5.2 should say that if tmStateReference is not present, steps 1..3 are skipped, and instead we create a tmStateReference cache entry (because we can't call openSession without having one) and go to step 4 (opening a new session).
We don't need a tmStateReference cache entry to call openSession. I believe the right behavior here is in fact to skip directly to step 4, as if there had been no LCD entry, and create a new SSH session. The difficulty is that currently we can't call openSession without a tmSecurityName, and we don't have one. I see two possible solutions to this problem:
(1) redefine openSession (a private ASI between SSHTM and SSH) to not require a tmSecurityName. In the case where destTransportAddress does not contain an '@' and tmSecurityName is not given, openSession should not pass any username to SSH. Instead, SSH will figure out on its own what username to use. Most SSH client implementations have heuristics for this which are quite often right; in the case of SSHTM-without-TSM, I'd expect these heuristics to be at least as good as anything else we can do, probably including using the SNMP securityName.
(2) redefine sendMessage to include the security model, name, and level, so that a secure transport can use them in setting up a session. Then, if there is no tmStateReference, pass the securityName parameter on to openSession.
Separately, I think we may have an issue in that sendMessage currently looks for the one-and-only existing session which matches destTransportAddress and tmSecurityName, and then reports an error if tmSameSecurity is true and the session ID does not match. Is it possible that there will be two different sessions with the same transport address and security ID? If so, and even if not, it seems that it may be appropriate to search for the one-and-only existing session with the same sessionID, and then verify that the transport address and security name match, rather than the other way around.
-- Jeff