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

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 11 Aug 2005 12:26:03 +0200

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

---

From: David Leonard <[email-masked]>
Date: Thu, 11 Aug 2005 22:10:54 +1000 (EST)

On Thu, 11 Aug 2005, Jeffrey Hutzelman wrote:

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

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

> 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

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Aug 2005 11:09:27 -0400

The handling of hostname canonicalization in GSSAPI is a thorny issue.
The short answer is that you need to get a canonical hostname from the
user or from secure DNS.  Since you don't have secure DNS, you need it
from the user.

RFC 2743 and 2744 have somewhat outdated thinking on this point.

While it is not a GSS spec, the discussion of this issue in RFC 4120
represents more current thinking.

     When appropriate data has been exchanged in advance, the application
     may perform this determination syntactically based on the application
     protocol specification, information provided by the user, and
     configuration files.  For example, the server principal name
     (including realm) for a telnet server might be derived from the
     user-specified host name (from the telnet command line), the "host/"
     prefix specified in the application protocol specification, and a
     mapping to a Kerberos realm derived syntactically from the domain
     part of the specified hostname and information from the local
     Kerberos realms database.

     One can also rely on trusted third parties to make this
     determination, but only when the data obtained from the third party
     is suitably integrity-protected while resident on the third-party

  Neuman, et al.              Standards Track                     [Page 9]
  
  RFC 4120                      Kerberos V5                      July 2005

     server and when transmitted.  Thus, for example, one should not rely
     on an unprotected DNS record to map a host alias to the primary name
     of a server, accepting the primary name as the party that one intends
     to contact, since an attacker can modify the mapping and impersonate
     the party.

     Implementations of Kerberos and protocols based on Kerberos MUST NOT
     use insecure DNS queries to canonicalize the hostname components of
     the service principal names (i.e., they MUST NOT use insecure DNS
     queries to map one name to another to determine the host part of the
     principal name with which one is to communicate).  In an environment
     without secure name service, application authors MAY append a
     statically configured domain name to unqualified hostnames before
     passing the name to the security mechanisms, but they should do no
     more than that.  Secure name service facilities, if available, might
     be trusted for hostname canonicalization, but such canonicalization
     by the client SHOULD NOT be required by KDC implementations.

     Implementation note: Many current implementations do some degree of
     canonicalization of the provided service name, often using DNS even
     though it creates security problems.  However, there is no
     consistency among implementations as to whether the service name is
     case folded to lowercase or whether reverse resolution is used.  To
     maximize interoperability and security, applications SHOULD provide
     security mechanisms with names that result from folding the user-
     entered name to lowercase without performing any other modifications
     or canonicalization.

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 11 Aug 2005 09:38:19 -0600

>> worked with it to implement it in PuTTY a few weeks back.

[...]

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

Hmmm...

I think I agree it should be SHOULD.  I.e., no one should be
slipping in extra packets between
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE and
SSH_MSG_USERAUTH_SUCCESS unless they have a darn good
reason.

I'm actually tempted to say it should be MUST-- but
that might be a bit too strong when one considers
SSH_MSG_IGNORE and SSH_MSG_DEBUG.

Thanks,

Joseph

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 11 Aug 2005 18:13:18 +0200

> SSH_MSG_USERAUTH_SUCCESS unless they have a darn good

OK.  I happen to agree, but wanted to make sure this was the original 
intent.

> SSH_MSG_IGNORE and SSH_MSG_DEBUG.

Agree.

Fixed in the source.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 19 Aug 2005 00:32:03 -0400

On Thursday, August 11, 2005 10:10:54 PM +1000 David Leonard 
<[email-masked]> wrote:

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

RFC2743's use of quotes there indicates that it is talking about a field 
called "hostname".  The quotes are not derisive, and are not intended to 
suggest that that field is populated with something other than what is 
normally meant by that word.

Unfortunately, RFC2743 is rather outdated in this respect, as well as in 
some others, and in some cases it is also unclear.  I believe Sam has 
adequately explained the current thinking among people working on GSSAPI 
regarding hostname canonicaliation.  I expect this issue to be explained 
rather more clearly in an upcoming revision of the GSSAPI spec.

In the meantime, I still believe the wording in the present document says 
what we intended, and does not require any changes.

I have been asked to submit an updated version of this document within the 
next few days, in order to get it on the agenda for the September 1 IESG 
telechat.  Unless Bill finds that we have consensus for a change in this 
area, I will submit the draft early next week with no further changes.

-- Jeff

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 22 Aug 2005 13:58:25 -0400

> area, I will submit the draft early next week with no further changes.

<wg chair hat on>

I've reviewed the messages exchanged so far on this issue.

I see what looks like consensus that there's a hole in the spec: the
spec as it stands is silent on what an implementation should do if a
hostname is not available.  

<wg chair hat off for remainder of message>

IMHO, the main thing that matters for interoperability is the complete
client system behavior rather than the behavior of the part of the
system which is above the GSS *API* boundary.  

Given that this question is being looked at within GSSAPI, perhaps the
best we can say for now is that if a client system implementing this
specification is unable to securely determine which hostname and/or GSS
target name to use, then it SHOULD NOT use this mechanism.

If the GSS API is later enhanced to provide a secure address->hostname
translation function, then *this spec* does not need to be revised to
account for this change.

Comments?

						- Bill

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2005 17:19:52 -0400

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill> On Fri, 2005-08-19 at 00:32, Jeffrey Hutzelman wrote:
    >> I have been asked to submit an updated version of this document
    >> within the next few days, in order to get it on the agenda for
    >> the September 1 IESG telechat.  Unless Bill finds that we have
    >> consensus for a change in this area, I will submit the draft
    >> early next week with no further changes.

    Bill> <wg chair hat on>

    Bill> I've reviewed the messages exchanged so far on this issue.

    Bill> I see what looks like consensus that there's a hole in the
    Bill> spec: the spec as it stands is silent on what an
    Bill> implementation should do if a hostname is not available.

    Bill> <wg chair hat off for remainder of message>
<ad hat on>

I agree that the spec is silent on what an implementation should do if
the hostname is not available.  It is not a requirement that the
specification define semantics for all cases only that sufficient
semantics be defined that all implementations are interoperable.  It
seems that is true for this specification in the case where a hostname
is available.  The fact that there are security concerns if the wrong
thing is done may make fixing this hole in the spec a requirement.
Never the less if we can come to quick consensus on a fix then we
should include it.

    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?

I'm seeking comments on the following three issues:

* Is Bill's solution a good idea
*  Is it a requirement that we fix this hole
* Is Jeff's text good?

My presumption (what I'll do absent comments) is as follows.  Bill's
solution is good and Jeff's text is good provided I don't find major
problems with it.  My presumption is also that fixing this issue is
optional.

<ad hat off>

My personal opinions do align with my presumptions.  I am still a bit
concerned that because of the security problems we may actually need
to fix this spec deficiency and so I'd much rather have agreement on a
fix than have to think about whether to block publication.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 25 Aug 2005 19:28:34 -0400

> Jeff, would you please draft text to be added in an rfc editor note to

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

---

From: David Leonard <[email-masked]>
Date: Fri, 26 Aug 2005 11:33:17 +1000 (EST)

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:

> requirement Bill mentioned.  I'll propose adding the following text to the end
> of section 7.1 to address this issue:
> 
> 
> 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.
> 
> 
> 
> 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.
> 

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

---

From: David Leonard <[email-masked]>
Date: Fri, 26 Aug 2005 11:37:51 +1000 (EST)

> "host@"+canonicalize(hostname) and try that instead (if it's a

and by 'canonicalize' i mean securely canonicalize, and only if such
secure canonicalization is available. (i.e. as discussed)

d

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Aug 2005 22:38:49 -0400

Is your only objection to the claim that implementations may append a
static string to the hostname?

If so, let's remove that text.  If not, please explain yourself and
provide alternate text.

---

From: David Leonard <[email-masked]>
Date: Fri, 26 Aug 2005 16:58:44 +1000 (EST)

> static string to the hostname?

To the unqualified hostnames? yes, I think so. Even case folding in
some security schemes might be a problem in unicode cases.
Though, I'm not sure about this.  RFC2742 s4.1 (to which this I-D's 
s7.1 refers) suggests that the mechanism may do folding/canonicalizing. 
This thread has been mostly about what SSH clients should do for 
older GSS implementations, of which I am not expert.

> If not, please explain yourself and
> provide alternate text.

I will suggest this text to add to 7.1:

 An implementation SHOULD NOT perform any modifications or
 canonicalization of the hostname when constructing the targ_name. 

The intent is to prevent the client canonicalization of the user's hostname
from inadvertently interfering with the intended service determination
made by a GSS mechanism. But, to fulfil interoperability objectives of the
RFC 4120 s1.3 ilk this text would also have to be added.

 To maximize interoperability, an implementation SHOULD fold the
 hostname to lowercase before constructing targ_name.  If a mechanism
 described in this document subsequently fails AND a secure method of
 canonicalization is available, an implementation SHOULD re-attempt the
 mechanism using a targ_name constructed from the securely-canonicalized
 hostname.  Secure methods of canonicalization include appending
 statically configured domains to unqualified hostnames, and secure DNS.

Now, I'm not 100% happy with this compromise approach (the second suggested
para), because 're-attempt' really means 'reconnect', which is bad. I'm
open to other ideas because I'm unsure about this.

d

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 Aug 2005 12:54:06 -0400

>>>>> "David" == David Leonard <[email-masked]> writes:

    David> On Thu, 25 Aug 2005, Sam Hartman wrote:
    >> Is your only objection to the claim that implementations may
    >> append a static string to the hostname?

    David> To the unqualified hostnames? yes, I think so. Even case
    David> folding in some security schemes might be a problem in
    David> unicode cases.  Though, I'm not sure about this.  RFC2742
    David> s4.1 (to which this I-D's s7.1 refers) suggests that the
    David> mechanism may do folding/canonicalizing.  This thread has
    David> been mostly about what SSH clients should do for older GSS
    David> implementations, of which I am not expert.

OK. 

    >> If not, please explain yourself and provide alternate text.

    David> I will suggest this text to add to 7.1:

    David>  An implementation SHOULD NOT perform any modifications or
    David> canonicalization of the hostname when constructing the
    David> targ_name.

This proposed text does not actually address Bill's original concern:
it does not give implementation advice in the case where the
implementation cannot figure out what to do.  The implementation
advice we're trying to give is to not use mechanisms described in the
draft in that case.

As such I'm going to adopt Jeff's text without the recommendation of
appending a static hostname or discussing case folding.