[OpenAFS] Re: feasibility of moving lightweight-principals issue "upstream" to kerberos
Fri, 30 Dec 2005 21:10:47 -0800
Adam Megacz <firstname.lastname@example.org> writes:
> Russ Allbery <email@example.com> writes:
>> In order to authenticate, they have to be able to talk to some
>> authentication service somewhere.
> Hrm, but I can check a public key signature even if I'm stranded on a
> desert island without "live" access to the CA. I can't do kerberos
> authentication with a peer on a desert island -- I need "live" access to
> the KDC.
The CA that signs that certificate to attest that it really belongs to
that person is the authentication services. You're certainly correct that
public key authentication can do off-line verification whereas traditional
> I mean, you can self-sign a certificate and give a paper copy to
> somebody at a conference -- all without having to lease a server that's
In that case, the person to whom you're handing the certificate and who is
verifying that you are who you say you are is the authentication service.
> I know these aren't the most realistic examples; I'm just trying to call
> attention to this requirement that a lot of people can't (or won't)
To some degree, the disagreement here is more based on terminology than
real disagreement over goals and possibilities. Many of us are used to
trying to analyze security systems by identifying where the authentication
and authorization are happening. There's always an authentication service
hidden somewhere, even if it's in a non-traditional form, and that's still
generally where the hard problems are.
What it sounds to me like you're saying is that you want to grant access
to your AFS cell (authorize) people for whom you have no traditional
authentication provider. Sure, I get this. Lots of people want to do
this. The answer is to find an authentication provider that will work for
those people. But you're still going to be doing authentication (and
therefore identity management, since you want your authentication system
to satisfy certain identity binding requirements which will require at
least some form of identity management).
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>