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

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

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