Proposed F19 Feature: GSS Proxy

Jaroslav Reznik jreznik at
Mon Jan 28 10:02:32 UTC 2013

= Features/gss-proxy =

Feature owner(s): Simo Sorce <ssorce at>, G√ľnther Deschner 
<gdeschner at> 

The main purpose of this project is to replace rpc.svcgssd(8), the server-side 
rpcsec_gss daemon.

The gss-proxy consists of a standardized RPC protocol, a client and server 
implementation with other future components. The gss-proxy protocol allows 
proxying of GSSAPI initiation and authentication. 

== Detailed description ==
The goal is to have a GSS-API proxy, with standardizable protocol and a 
[somewhat portable] reference client and server implementation. There are 
several motivations for this some of which are:

- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be
  able to leave all complexity of GSS_Init/Accept_sec_context() out of
  the kernel by upcalling to a daemon that does all the dirty work.

- Isolation and privilege separation for user-mode applications.  For
  example: letting HTTP servers use but not see the keytab entries for
  HTTP/* principals for accepting security contexts.

- Possibly an ssh-agent-like SSH agent for GSS credentials -- a

In order to use the gssproxy only the gssproxy daemon has to be started at 
boottime. Once this is done, the GSSAPI mechglue library will make sure all 
GSSAPI calls issued by an application are directed to the gssproxy service 
transparently. Depending on the configuration of the system, the gssproxy 
daemon will then allow or disallow access to cryptographic keys stored in 
keytabs on the system.

Two major features that are planned to be achieved for Fedora19:

- rpc.gssd, the NFS client application, should be enabled to use the gssproxy. 
  It will be possible to aquire tickets for kerberized NFS mounts given user 

- gssproxy will offer Kerberos ticket renewal when user keytabs are available

More information about the devel-announce mailing list