[cups.development] Kerberos delegation

[Andy Polyakov]

Hi,

Some time last year (on the 6th of November to be specific) I wrote:

> get_gss_creds: Attempting to acquire credentials for HTTP at server...
> get_gss_creds: Credentials acquired successfully for HTTP at server.
> cupsdAuthorize: No delegated credentials!
> cupsdAuthorize: Authorized as user at REA.LM using Negotiate
> ...
>
> [As for "no delegated credentials." I'll be discussing this at some
> later point in separate context.]

The context was "seamless" deployment of Kerberos authentication for
both web-based authentication and printing... But to the "later point":-)

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?

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?

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); b) have local cupsd forward client requests with HTTP 3xx
redirection code (would it require cups modification, right?); 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.
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...

One can address above problems, in particular with web-based
administration and samba printouts, by favoring local authentication
methods by a) making sure they are evaluated first; b) assigning higher
"trust" level. This is what attached patch attempts to do: it moves
PeerCred authentication up and assigns whatever authentication method
cupsd expects to see, as opposite to pretending local authentication was
Basic one. As for the latter. More "politically correct" solution could
have been to rank authentication methods by assigning ascending numbers
to various methods, say 0 for none, 1 for Basic, 2 for Negotiate, 3 for
local method X, etc. and evaluating expected level by >= provided
instead of ==. I mean AuthType would denote minimum required level as
opposite to exact one. Note that I claim no explicit liability for
correctness of provided patch, even though I can confirm that it's
deployed in real-life installation. The patch is relative to 1.3.8, yet
can be off by few lines, because of interference with other local patches.

On related matter one can also question what value does
GSS_C_MUTUAL_FLAG add in current implementation? I mean what value could
server authentication help protecting? It could only be printout data,
couldn't it? But the token confirming server identity is transfered to
the client *after* printout data is transferred, or in other words *too
late* for client to make a decision and regret. Wouldn't it be more
appropriate to insist that server authenticates itself *prior* client
sends printout data? Say in HTTP/1.1 100 Continue reply... One can even
argue that this also should be the point where server can tell the
client if delegation is required for given printer queue, so that
delegation can be configured on per-queue basis (preferably even with
option for explicit consent from user on the client side), not as
unconditional surrender of forwarded TGTs. I mean protocol could have
looked as following instead:

Client                                  Server

POST header with non-delegated
Negotiate followed by IPP header
                                        Continue reply with server
                                        token
[                                       and custom flag denoting
                                        required delegation

<disconnect>

POST header with delegated
Negotiate followed by IPP header
                                        Continue reply with server
                                        token
                                        [and custom flag denoting
                                        required delegation]
]
IPP data

Cheers. A.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cups.diff
Type: text/x-patch
Size: 2765 bytes
Desc: not available
URL: <http://lists.cups.org/pipermail/cups-devel/attachments/20090303/246bd317/attachment.bin>