From: chris on
It's possible that I've misunderstood it, but Kerberos seems like a
hassle in comparison to modern public key cryptography, and they seem
to accomplish similar goals. Where is the distinction drawn?
From: Joseph Ashwood on
"chris" <where.you.wanna.be(a)gmail.com> wrote in message
news:f26e203e-3a1e-4d4e-b83e-64c7be73666a(a)q15g2000yqj.googlegroups.com...
> It's possible that I've misunderstood it, but Kerberos seems like a
> hassle in comparison to modern public key cryptography, and they seem
> to accomplish similar goals. Where is the distinction drawn?

Kerberos is actually a very sophisticated system, with many capabilities
beyond a simple public key system. Kerberos is about authenticating people
based on a small secret, this secret can be kept on a smartcard and it can
be a private key for an asymmetric system (public key). Most of the Kerberos
design is about leveraging that small secret to achieve not just
authentication but authorization.

There is also the fact that asymmetric/public key cryptography is
computationally expensive. Kerberos allows for a limited computation in
asymmetric crypto in the first authentication followed by just symmetric
crypto which is substantially cheaper computationally.
Joe

From: Anne & Lynn Wheeler on

Jim Haynes <jhaynes(a)alumni.uark.edu> writes:
> Either way you have to have an entity you can trust, either the Kerberos
> server or the server that gives out the public keys. Kerberos was developed
> and was free back when public key was still encumbered by patents and
> licenses.

Kerberos started out being able to register "something you know"
shared-secret ... aka password. PKINIT for kerboros started out
registering a public key ... in lieu of password for authentication. It
was later that there was lots of pressure to add digitial certificate
based public key processing option to PKINIT.

lots of public key cryptography is only used around the edges
.... because it is so much more expensive than symmetric keys ... aka SSL
uses public key for symmetric key exchange ... and then the rest is done
not using public key cryptography.

way back when, we were part of one of the corporations that was
underwriting Project Athena ... and would go by for periodic reviews of
their projects ... including Kerberos. One week sat thru the evoluation
of design for cross-domain operation.

Much more recently sat thru a presentation of one of the first SAML
deployments... and brought up that their message flows were identicial
to Kerberos cross-domain.

One of the original issues vis-a-vis digital certificate paradigm
.... there still being requirement for the authorization information
(what permissions), in addition to authentication. Early digital
certificate scenarios were that both authentication and authorization
information would be carried in the certificate. The issue was that a
lot of authorization information needed to be much more timely than the
stale/static information carried in the digital certificates ... as well
as finding that authorization information frequenlty turning out to have
privacy implications.

Creating real-time (non-public) repository for the authorization
information ... significant reduces the justification for having digital
certificates; in fact recording the authentication information (whether
shared-secret or public key) in the same real-time (non-public)
repository ... makes digital certificates redundant and superfluous

another major authentication/authorization infrastructure is RADIUS
.... used by ISPs all over the world. This also started out with
shared-secret authentication ... in approx. same time-frame as Kerberos.
In much the same way that PKINIT had public key registration in lieu of
password ... it is also possible to do RADIUS infrastructure that
registers public key in lieu of password (neither actually requiring
digital certificates as part of doing public key authentication).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970
 | 
Pages: 1
Prev: OAEP vs. PSS in PKCS#1
Next: Modes of operation