David Leonard wrote:
Here are my comments about draft-ietf-secsh-gsskeyex-09.txt having worked with it to implement it in PuTTY a few weeks back. * s4 In the par. starting with "The server SHOULD ...": the word "not" is missing in the first sentence, i.e. "this method has *not* already been tried". At least that's what would make sense.
I think you mean the paragraph starting with "The client SHOULD". And yes, I agree, the word "not" is missing; I've fixed it in my source.
* s7.1 In the last phrase "the hostname of the SSH server": Sometimes users specify IP addresses instead of hostnames, and the GSS mechanism is expected to deal with it (rightly so). Now, my concern is with the use of the word 'hostname' in the case of targets specified as network addresses. As written the par seems to imply a client ought to do reverse DNS if an IP address is given. So I suggest changing "the hostname of the SSH server" to "the given name of the SSH server" or something like that.
I believe the existing text is correct. The construction of GSSAPI host-based service names requires a hostname, not an IP address. Yes, that means that if the user provides an IP address, the server will need to reverse-resolve in a secure fashion.
I think this is something the WG should comment on.
* s3.7 "This packet should be sent ...": The word "should" be capitalized to clarify its meaning?
Possibly. This text dates back to the original GSSAPI userauth draft, so perhaps Joseph Galbraith can shed some light on whether he intended this to have the force of requirements language.
* some minor typos: "environements", "gorups"
Fixed in source.
One larger issue with GSS and KEX is that when a client decides to use offer GSSKEX it queries GSS for available mechanisms and then offers these during KEXINIT in the kex algs list. Later, during gss_init_sec_ctx, the mechanism might fail (expired credentials, say). But by then it is too late, as errors in KEXINIT are irrecoverable, it makes getting a session impossible. The real problem is that an implementation has to predict which GSS mechanisms will always fail (and therefore omit them from the the offered kex algs list to proceed). One approach is to iteratively retry the connection, disable gss mechanisms as they fails. This is not addressed by the current draft, and I do not know if there is a better approach, or a better way to allocate blame :)
As Sam noted, an implementation strategy that works fairly well is to make the first call to gss_init_sec_context before deciding whether to include a particular GSSAPI-based keyex algorithm in the KEXINIT list.
-- Jeff