[cups.development] Kerberos delegation

[Andy Polyakov]

>> 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)

??? Where does it say that? RFC4559 says "here is how you incorporate
spnego tokens into http headers," RFC4178 says "here is how you
negotiate and wrap data returned by gss-api subroutines" and finally
RFC2743 says "gss-api *provides for* delegation," but the choice whether
or not it will actually be engaged is left to application. Nowhere does
it say that HTTP will/should/shall/must unconditionally engage or rely
on delegation (nor can I confirm this from experience). The choice is
really dictated by nature of application, in particular whether or not
it serves as a mid-tier and, in case it does, has to prove requester's
identity to 3rd party.

For reference, as for "more restrictive policy for delegating
credentials." All KDCs support option to prohibit delegation with at
least per-user-principal granularity (i.e. given users are prohibited to
get forwardable tickets). Then Active Directory limits delegation to
trusted hosts only, meaning that it doesn't issue forwarded TGTs for
just any target, but only to those explicitly configured as trusted for
delegation. And as far as understand Heimdal is also moving that
direction, i.e. having notion of trusted for delegation per host
principal. If one was to deploy cups server in such environment, one
would have to do just that, configure it as trusted for delegation, and
the point is that there is no sufficient reason for that. It *is*
possible to get it working without delegation. And why shouldn't it be
possible? cupsd is not mid-tier, at least not when it comes to web-based
administration or majority of printer back-ends.

>> 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.

*If* browser have sent delegated credentials, they are saved in a file
with randomly generated name denoted by KRB5CCNAME environment variable
passed to CGI program (at least that's what happens on Linux). If
browser didn't send it, no file is created and no environment variable
is passed to CGI program. But cupsd sets up local certificate
*regardless*. CGI program then attempts local certificate
authentication, the attempt is rejected by cupsd (because cupsd expects
Negotiate level, while local certification is presented as Basic). If
there are delegated credentials around, CGI program pulls ticket to
ipp/serv.er on requester's behalf and proceeds with Negotiate. Question
is following. Given that by the time CGI program is forked cupsd has
already established requester's identity (no delegation is required for
this!) and passed it to CGI program, why doesn't local certificate
authentication [or PeerCred] suffice for authentication of CGI program?
That's what patch is about: it makes local certificate [and PeerCred]
sufficient.

>> 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.

I don't understand. a) works for us *now*, what is it you are looking at
for 1.5?

>> 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).

Yes. But it doesn't make our interest any smaller: we want to support
windows printing through samba. And for that we're ready to do whatever
it takes to make it work, including cupsd modifications and discussing
these modifications on cups-dev list:-) So given that users are known to
be authenticated to samba with strong enough method (Kerberos in our
case), all we have to do is to make sure that there is strong enough
reason to believe that when local samba says it user a who is submitting
printout is actually user a. That is second thing previously submitted
path is about: providing strong enough reason by moving PeerCred method
upwards in sequence of attempted methods. For reference, this naturally
implies that samba is configured to talk to cupsd over Unix socket, and
not over TCP connection.

Cheers. A.