[cups.development] Kerberos delegation

Michael Sweet msweet at apple.com
Tue Mar 3 10:28:06 PST 2009


On Mar 3, 2009, at 9:26 AM, Andy Polyakov wrote:
> ...
> One of commonly recognized "good-design" principles for a security
> system is least required privilege. And the question is if  
> delegation is
> actually required for cups? Or even, is it appropriate for an
> application to effectively deny a site to exercise more restrictive
> policy for delegating credentials?

Kerberos over HTTP requires credentials that can be delegated and  
forwarded.
(its part of the spec that we have to follow)

> Let's consider web-based administration to start with. As of now the
> only way to get it working is to ensure that administrator gets
> forwardable TGT and configures his/her browser for delegation (in
> Mozilla case ensures that cups server is listed in
> network.negotiate-auth.[trusted|delegation]-uris)... But for what
> purpose exactly? What happens is following: cupsd saves forwarded TGT;
> forks a cgi program which connects back to cupsd; with the help of
> previously saved forwarded TGT the cgi program pulls a ticket to cupsd
> server and authenticates itself... Does it really have to be that way?
> Couldn't cupsd recognize own descendant and assume initiating client's
> identity? And thus eliminate requirement for delegation?

The web interface CGI programs use local certificate authentication  
instead of Kerberos - when you access a page that needs Kerberos, the  
browser provides the credentials to cupsd, which "saves" them with the  
certificate for the CGI program.

> Moving on to printing. As it is now *if* you ought to talk to cupsd on
> localhost, then your host has to have proper keytab, even if your
> computer has no locally attached printers. But maintaining hundreds of
> keytabs is no fun and sometimes is simply impossible (think
> self-administered computers). Three possibilities: a) instead of  
> talking
> to local cupsd talk directly to central server that delivers printouts
> to all the printers (for reference, currently deployed scenario at our
> site);

This is something we are looking at for CUPS 1.5.

> b) have local cupsd forward client requests with HTTP 3xx
> redirection code (would it require cups modification, right?);

That would require a CUPS change on all clients and has security  
issues of its own when the client does not use Expect:.  In addition,  
I do not believe that Windows supports the 307 redirects that would be  
needed for POSTs.

> c) given
> that local cupsd is privileged it could access user ticket cache  
> without
> requiring delegation (doesn't require client modification). In these
> cases delegation would be required only if back-end would require
> authentication, let's say back-end was to talk to Windows server.

That won't work without writing a whole new Kerberos implementation  
(i.e. a replacement for MIT or Heimdal) since even though you can read  
the user ticket cache you can't ask for new tickets from that cache  
(which is what would be needed).

> Another related issue here (actually of larger interest in our  
> context)
> is printout delivered through samba running on cupsd server. As samba
> can't make clients provide forwarded TGT, authentication between samba
> and cupsd is doomed to fail. Unless of course one does something...

SMB-based printing is always going to be problematic due to the  
fundamental limitations of the protocol. Printing is an afterthought  
with SMB and Windows has no notion of server proxies - you always talk  
directly to the destination server from the user session. So, if you  
require Kerberos authentication in CUPS you can't use Samba for  
printing, only IPP (https://server:631/printers/printername).

________________________________________
Michael R Sweet, Senior Printing System Engineer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cups.org/pipermail/cups-devel/attachments/20090303/f540d148/attachment.html>


More information about the cups-devel mailing list