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

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

I have to strongly disagree with this approach.

My view is that the application should not canonicalize the hostname (as
supplied by the user) before passing it to GSS in a targ_name. This is
because the GSS mechanisms may be sensitive to non-canonicalized names,
and indeed the GSS mechanisms may do their own secure canonicalization
themselves.

I propose instead for 7.1 that a client system SHOULD first construct
targ_name = "host@"+hostname (without modifying the user-supplied
hostname) and try GSS. Then, if the GSS fails [?], the application
SHOULD try canonicalizing the hostname and construct targ_name2 =
"host@"+canonicalize(hostname) and try that instead (if it's a
different string).

This serves the need for interoperability with GSS mechanisms that
do not canonicalize, and the (more important) need for passing
user-supplied hostname strings as-is to the GSS mechanisms.

I note that when constructing channels, the hostname may need to
be canonicalized to form a channel address, but that this is a 
problem outside of this part of the ssh architecture.

Recently, I added a GSSAPIServiceName option to vintela-openssh
that allows users to explicate the service name to use. A number
of customers found this useful because they have DNS namespaces
that look nothing like their realm namespace. A similar
issue may arise from draft-ietf-krb-wg-kerberos-referrals.

d

On Thu, 25 Aug 2005, Jeffrey Hutzelman wrote:

> On Wednesday, August 24, 2005 05:19:52 PM -0400 Sam Hartman
> <hartmans-ietf%mit.edu@localhost> wrote:
> 
> >     Bill> IMHO, the main thing that matters for interoperability is
> >     Bill> the complete client system behavior rather than the behavior
> >     Bill> of the part of the system which is above the GSS *API*
> >     Bill> boundary.
> > 
> >     Bill> Given that this question is being looked at within GSSAPI,
> >     Bill> perhaps the best we can say for now is that if a client
> >     Bill> system implementing this specification is unable to securely
> >     Bill> determine which hostname and/or GSS target name to use, then
> >     Bill> it SHOULD NOT use this mechanism.
> > 
> > 
> > Jeff, would you please draft text to be added in an rfc editor note to
> > do this?
> 
> Sure.  I think we need a bit of background in addition to the simple
> requirement Bill mentioned.  I'll propose adding the following text to the end
> of section 7.1 to address this issue:
> 
> 
>  Because the GSSAPI mechanism uses the targ_name to authenticate the
>  server's identity, it is important that it be determined in a secure
>  fashion.  One common way to do this is to construct the targ_name
>  from the hostname as typed by the user; unfortunately, because some
>  GSSAPI mechanisms do not canonicalize hostnames, it is likely that
>  this technique will fail if the user has not typed a fully-qualified,
>  canonical hostname.  Thus, implementors may wish to use other methods,
>  but should take care to insure they are secure.  For example, one
>  should not rely on an unprotected DNS record to map a host alias to
>  the primary name of a server, or an IP address to a hostname, since
>  an attacker can modify the mapping and impersonate the server.
> 
>  Implementations of mechanisms conforming to this document MUST NOT use
>  the results of insecure DNS queries to construct the targ_name.  Clients
>  MAY make use of a mapping provided by local configuration, append a
>  statically configured domain name to unqualified hostnames, and/or use
>  other secure means to determine the targ_name to be used.  If a client
>  system is unable to securely determine which targ_name to use, then it
>  SHOULD NOT use this mechanism.
> 
> 
> 
> > * Is Bill's solution a good idea
> 
> I think Bill's solution is good, as far as it goes.  The basic requirement is
> that clients that cannot figure out what to do securely SHOULD NOT use this
> mechanism.  The text I proposed provides a little background on why, and also
> adds the requirement that implementations MUST NOT use insecure DNS to decide
> what hostname to use.  Based on what I've seen in ssh implementations, I don't
> expect that to be a difficult sell in this WG.
> 
> 
> 
> > *  Is it a requirement that we fix this hole
> 
> I'm not sure that it is.  RFC4120 provides very similar advice to what I
> provided above, and it is my hope that the next GSSAPI revision will do the
> same.  On the other hand, there is the danger that if we don't call this out,
> some implementor will think it is a good idea to reverse-resolve an address
> provided by a user, which would be unfortunate.
> 
> I think I'll mostly stay neutral on this question.
> 
> 
> 
> > * Is Jeff's text good?
> 
> Yes, I think my text is good. :-)
> 
> 
> -- Jeff
> 
> 
> 

--
David Leonard
Vintela Resource Central software engineer
Quest Software; Brisbane, Australia; www.quest.com
Phone: (US) +1 801 655 2755 
       (AU) +61 7 3023 5133