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

["Salowey, Joe" <jsalowey%cisco.com@localhost>]

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz%cmu.edu@localhost] 
> Sent: Thursday, August 25, 2005 4:29 PM
> To: Sam Hartman; Bill Sommerfeld
> Cc: David Leonard; ietf-ssh%NetBSD.org@localhost; Salowey, Joe; 
> galb%vandyke.com@localhost; welch%mcs.anl.gov@localhost
> Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments
> 
> 
> 
> 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.
>

[Joe] I think this text is good.
 
> 
> 
> > * 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.
> 

[Joe] It is important that we describe the issue.  We can't completely
fix the hole in this spec, we can at least put up warning signs and
recommend that they don't go there. 

> 
> 
> > * Is Jeff's text good?
> 
> Yes, I think my text is good. :-)
> 
> 
> -- Jeff
>