[36605] in Kerberos

home help back first fref pref prev next nref lref last post

Re: [remctl] Proposal for new credential delegation functionality

daemon@ATHENA.MIT.EDU (Simo Sorce)
Fri Nov 7 10:51:25 2014

Date: Fri, 7 Nov 2014 10:50:07 -0500
From: Simo Sorce <simo@redhat.com>
To: =?UTF-8?B?UsOpbWk=?= Ferrand <remi.ferrand@cc.in2p3.fr>
Message-ID: <20141107105007.01b46f47@willson.usersys.redhat.com>
In-Reply-To: <545CD597.5020605@cc.in2p3.fr>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

On Fri, 07 Nov 2014 15:22:15 +0100
RĂ©mi Ferrand <remi.ferrand@cc.in2p3.fr> wrote:

> Hi everyone,
> 
> It's been a while since I think about a *proxy* functionnality for 
> remctl that could allow, in a scenario like:
> 
> [client (someone@EXAMPLE.ORG)] --> [remctl server 1 / command 
> *the_command*]
> 
> to delegate credentials from client to remctl server (credentials
> could be stored in a ccache like SSH does when GSSAPI delegation
> occurs). The command *the_command* executed on remctl server [remctl
> server 1] could then execute other remctl chained commands with user
> credentials.
> 
> This could allow one to call other remctl commands within a remctl 
> server command.
> 
> Each delegated credential should also be isolated from the others
> (just like SSH does).
> Of course this should be optional and specified as an option for each 
> command defined on the server.
> 
> For now, I do already have a very simple but working version of
> remctl with modified client and server to accomplish this.
> 
> Now comes the time I ask you what you think about this idea ?
> Do you think that this is a *MUST HAVE* functionnality for remctl or
> are we the only one interested in this at CC-IN2P3 :-)

It is a very nice to have, but, it would be really nice if you did not
use unbounded delegation (ie send the whole TGT) but ratherr allow to
either just send a ticket (set of tickets) for whatever action may be
neded, and/or support constrained delegation on the receiving end
(s4u2proxy).

My2c.
simo.

-- 
Simo Sorce * Red Hat, Inc * New York

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


home help back first fref pref prev next nref lref last post