RFC 4462 empty user name string

[Jim Basney]

Sorry, I should have mentioned that the patch in Bug 958 doesn't have
the empty user name string mods, as I think that's best addressed as a
separate issue (and I'll follow your Bug 1100 with interest).  Our empty
user name modifications are only in the larger patch at
<http://grid.ncsa.uiuc.edu/ssh/>, specifically
<ftp://ftp.ncsa.uiuc.edu/aces/gssapi-openssh/openssh-4.3p2.patch>.

Our current approach is to only send an empty username if:
  - the user didn't specify a username at the client
  - the server supports the GSI OID for GSSAPI authentication
    (and thus has our server-side mods)

David Leonard <David.Leonard at quest.com> wrote:
> Hi,
>
> Thanks for that. I looked at the patch in 958, and I guess I will have
> to stare at it some more (when I am more awake) to understand how it
> uses empty username strings.
>
> I'm mainly confused as to what the behaviour of the /client/ should
> be. You see I've also got patches against PuTTY, and the approach I
> made it try for gssapi-with-mic/gss-keyex was
>   - try sending an empty username string first
>   - if that fails, try sending the username provided in config
>   - if that fails, try sending the non-realm elements of the upn :)
> My plan was that the client should try to discover a way to login to
> the server by trying older and older standards.. and guesswork. The
> problem though is that sshd rejects the connection because it sees the
> client is changing the username, and won't give the client a second
> chance. The only workaround I can see is that the client re-try the
> connection after it collapses (but that has its own hairy problems.)
>
> Bug 1100 is the one I entered on this topic. I have an implementation
> (patch), for openssh but it only works without privsep at the moment.
>
> Cheers
>
> d
>
> Jim Basney wrote:
> > Yes, we find the RFC 4462 empty user name string feature very useful for
> > the GSI GSSAPI mechanism to ease single sign-on across systems where
> > usernames differ.  For interop, we have to be careful to only send an
> > empty username if we know the server will accept it.  We maintain our
> > GSI patch for OpenSSH at <http://grid.ncsa.uiuc.edu/ssh/>.  I submitted
> > a version of the patch at
> > <http://bugzilla.mindrot.org/show_bug.cgi?id=958> which I'd be happy to
> > update if there's interest.
> >
> > Cheers,
> > Jim
> >
> > David Leonard <David.Leonard at quest.com> wrote:
> >
> >> I'm all for multiple-auth in sshd, but the current impl appears to
> >> conflict with an obscure feature of RFC4462 that I have been trying to
> >> implement, namely where the username field can start off blank and the
> >> server deduces the username from the credentials. Has anyone else looked
> >> at this? sshd currently rejects connections when the username field
> >> changes between separate auth attempts.
> >>
> >> d
> >> _______________________________________________
> >> openssh-unix-dev mailing list
> >> openssh-unix-dev at mindrot.org
> >> http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >>
> >
> >
> >
>