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

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

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?

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