[pubcookie-dev] keyserver access control proposal

[Nathan Dors]

You're probably right (yet again, Larry, hasn't
California mellowed you at all?) some sites might
reasonably want to leave their keyserver wide open,
so we ought to make that an option.

But we've always had a little bit of registration
overhead for app servers on our campus, and that
hasn't limited the breadth of our success. To get a
DES key here, you need to answer a requirements
survey of five questions. Do this once correctly,
and you're put on our frequent-flyers list of known
pubcookie sysadmins. We think we're adding value
through this process: by revealing misunderstandings
and anticipating possible problems, by collecting
contact information for future service announcements,
and by sometimes applying ad hoc policies to the
reqeusts (e.g., in the past students needed to Cc
their supervisor; requests aligned with the UW
Medical Centers were Cc'd to Medical Centers IT
staff).

And we do have a traditional web gui for this: the
requirements survey is online, frequent flyers can
bypass it, and we can give fast-track service to
admins with matching contact info in our local DNS.
The "permit" option simply provides an interface for
our registration web gui to automatically prime our
keystores. Our keyserver_client_list says our web
gui can permit new servers and nobody else.

Originally, I was also concerned how easily
kerserver would create a new key in the keystore:
essentially for any keyclient connection that passes
the CA test. We only partially addressed that ...

I hope this explanation helps.

-Nathan


On Mon, 16 Feb 2004, Lawrence Greenfield wrote:

>    Date: Mon, 5 Jan 2004 15:28:20 -0800 (PST)
>    From: Nathan Dors <dors at cac.washington.edu>
>
>    The pubcookie 3.0 keyserver provides no internal access-control
>    mechanism, i.e., any keyclient connection that passes the SSL/TLS
>    requirement can get and set a key and participate in a site's
>    pubcookie deployment.
>
> I see no technical problems with what you propose (and by now probably
> implemented). I am curious what the logic behind this enhancement is,
> however.
>
> Do you worry that users might be revealing their identities
> unknowningly in the course of browsing? (I think the solution to this
> is enhanced UI on the login server's side.)
>
> Are you worried about attacks
>
>     o  To control which hosts can use the "permit" option, keyserver
>        recognizes a new "keyserver_client_list" config variable.
>        Administrators can use this variable to define the trusted
>        hosts (probably just one or two) that they will use to
>        authorize new participating hosts.
>
> I find this curious. It would be much more natural to use personal
> certificates or pubcookie itself for this functionality rather than
> the host-based access control you propose. In such a model, you could
> have a web-accessible UI for modifying the permits file.
>
> I think the only reason to enhance keyclient is to make operations
> that cannot be accomplished in a traditional web UI.
>
> [...]
>    Does anyone disagree with this overall approach or think we need
>    to provide sites with the ability to leave their keyservers wide open?
>
> I think wide open sites are reasonable for some environments. The
> easier it is to deploy an application using pubcookie, the less likely
> an intranet developer will just take a username/password and verify it
> against the canonical authentication server. Requiring permission to
> add an application server especially hampers secure early development.
>
> Larry
>
>