SSH mediated Kerberos authenticated sudo.
g.w at hurderos.org
Fri May 13 03:08:34 EDT 2011
On May 11, 1:00pm, Frank Cusack wrote:
} Subject: Re: SSH mediated Kerberos authenticated sudo.
> On Wed, Dec 22, 2010 at 10:31 AM, <g.w at hurderos.org> wrote:
> > ftp://ftp.hurderos.org/pub/Hurdo/Hurdo-0.1.0.tar.gz
> Revisiting this.
Hi Frank, hope the week has gone well for you and others on the list.
> In my followup idea on having the server initiate the request for
> the fresh credential, any thoughts on how to present a secure UI to
> the user so that he knows this is ACTUALLY a local password request
> and not something being mocked up by a compromised server?
I've spent a lot of time thinking about what you proposed in advance
of the next release of Hurdo. While the initial focus was sudo I
think there is the opportunity to make this a more generic
The next release will have a PAM module which handles the
authentication of the forwarded AP-REQ packet. That will eliminate
the need for the sudo patch and provide a general mechanism for any
application to leverage this system.
The next hurdle will be to handle the model you propose whereby a
remote application can request a credential from a user. The
philosophical question is the scope of trust to be afforded the remote
By definition the remote sshd infra-structure is 'trusted' secondary
to the host key authentication mechanism. The only real implication
of that is we have some guarantee as to the authenticity of that
host. It doesn't speak to the overall integrity of the system of
course, including applications hosted on the remote system.
In your proposed model, for full trust, an application would have to
authenticate itself to the sshd infra-structure in order to elicit the
request for credentials. At that point we are working within the
context of a trust enclosure.
I could, for example, envision sshd setting up a user specific AF_UNIX
socket on the remote host which an application would connect to and
authenticate a request for a user credential. sshd would compose a
message packet to the client to request a credential from the user for
the application. At that point the client requests the user for the
So that would be a model for a complete trust environment where an
application required forwarding of a user password. Any model which
requires that is decidedly dangerous but sometimes a reality.
In actuality, at least in the environments I work in, the request
would be a request for 'authorization' to authenticate. My ssh client
holds a valid TGT in its credential cache which the client would use
to request a service ticket for the target application. So the SSH
client would be asking for permission to mint and forward a service
ticket for the application.
The user has decided to run an application which in turn requests an
application specific credential which the user verifies can be
returned to the application on their behalf. I guess it becomes a
philosophical question whether there is a need for the application to
authenticate itself to the infra-structure to initiate the request.
If the remote application can't be trusted it would seem there is a
much higher risk associated with running that application then the
possibility of it obtaining an application specific credential which
authenticates the user. If the infra-structure was forwarding a TGT
it would be a different story since in this era of addressless
tickets that would be a much more valuable entity to obtain.
> With the client-initiated escape sequence, I think it's less of a
> concern since as long as the client software is not tampered with
> the user has a guarantee that they are actually entering their
> password locally. And if the client software IS tampered with, then
> all bets are off anyway.
Indeed, and in this era of malware an increasingly difficult dilemma.
Hope the above is helpful, I would be interested in any additional
thought people may have with respect to shaping this system.
Best wishes for a pleasant weekend to everyone.
}-- End of excerpt from Frank Cusack
The Hurderos Project
Open Identity, Service and Authorization Management
"When I am working on a problem I never think about beauty. I only
think about how to solve the problem. But when I have finished, if
the solution is not beautiful, I know it is wrong."
-- Buckminster Fuller
More information about the krbdev