Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments

[David Leonard <David.Leonard%quest.com@localhost>]

On Thu, 11 Aug 2005, Jeffrey Hutzelman wrote:

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

Yes, I meant to say the "The client SHOULD" paragraph, as you deduced.

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

No. I read RFC2743 s4.1 to say that the canonicalizing of the "hostname"
string is the job of the GSS mechanism, and not that of the SSH server
code.

If you agree, then I think a better correction is to just quote the word
"hostname" in the last sentence of s7.1, as was done in rfc2743 s4.1.

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

and less subject to degradation attacks too

--
David Leonard
Vintela Resource Central software engineer
Quest Software; Brisbane, Australia
VoIP: US: 801-655-2755 
      AU: 07-3023-5133 
"With Quest Software, you can expect more."