A secure user

[Michael Sweet]

Anonymous wrote:
>> Yes, but right now we don't even do that!  You'll find this
>> documented in the Server Security help file in CUPS 1.2, BTW...
> 
> Sure, I know, I'm talking about hacking it in.
> 
>>> Are there browsers that support IPP printing, or can cert auth
>>> be done in say, adding a Windows IPP printer? Again, though,
>>> I'd like to avoid client-side changes as much as possible.
>> You can't avoid client-side changes - *something* has to know to
>> send that certificate for the server to use.
> 
> Well, honestly, for a certain kind of configuration, I think I
> can avoid client side changes, mainly thanks to the ipp backend
> which already supports https:// . I was able to do this with the
> encrypted ident, and I think I can do it for cert auth.
> 
> It amounts to using the local cups server basically as a proxy:
> 
> user - domain sock -> local cupsd - SSL verified conn -> master cupsd
> 
> The domain sock isn't spoofable AFAIK. The local cups server then
> uses the ipp backend with a client cert to connect to the master
> who verifies the connection and considers this IPP user authenticated.
> 
> Here's where I see the hacks needing to be done:
> 
>     - DomainSockAuth type for local cupsd
>     - Hack to IPP backend adding https://host?cert=/path/to/cert.pem
>     - Hack to master cupsd to allow certified auth based on local
>       cupsd cert
>     - Exception for localhost printing for e.g. samba printing
> 
> Do you see a hole in this scenario or a place where client side
> cert support must be added?

Hmm, so you are looking to implement a "signing authority" kind of
setup, where the client certificate validates the user info that
has been passed by a trusted cupsd (or other) client.

This is certainly possible and an interesting option, but you will
still need to hack the client library or seriously hack the IPP
backend to get the certificate and user info passed in the request.
The amount of work will be pretty much the same - the only difference
is whether the server treats certificates as user- or system-
specific...

>> AFAIK, no browser supports IPP printing directly; some do indirectly
>> via toolkit support of CUPS.  I don't know if Windows allows you to
>> provide a user certificate that is used when negotiating a SSL or
>> TLS session.
>>
>> I'm looking at using certificates in a more general sense -
>> eliminating the need for a username/password challenge in the web
>> interface or any other HTTP access, which includes IPP operations.
>> Just doing it for a few specific paths will be a hack and will
>> probably be more difficult than the general solution (where hooks
>> already exist for this kind of thing...)
> 
> I don't see why this couldn't be added now as a stopgap measure
> until certs are fully supported. Even if certs are fully supported,
> I don't relish the idea of issuing one for all my users :->

This can be automated a bit, just like with SSH, and then the
server can authenticate the client normally the first time to
collect the client's certificate and user association.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com