Re: [kitten] [EXTERNAL] Re: Windows Intent to revive and implement IAKerb draft-ietf-kitten-iakerb-03

[Paul Romero <[e-mail]>]

Hi Nico:

I don't  agree that SCRAM is obsolete and am curious why
you think that is the case. I've used it quite a while and
never experienced a security breach.  The only problem
I have come up against is the configuration of the end to end
secret.

Best Regards,

Paul R.

On 2/19/23 15:52, Nico Williams wrote:
> On Sun, Feb 19, 2023 at 02:43:54PM -0500, Ken Hornstein wrote:
>>> Just throwing it out here, because I sure would love to make it
>>> possible (and easier) to use kerberos-backed out on the Web, without
>>> all the issues that come with multiple-roundtrips, which are what I
>>> find breaks most of these scenarios (the complexity of the protocol
>>> itself and the unfamiliarity of any non-password/bearer based auth
>>> scheme aside).
>> You know, the frustrating thing to me (as a Kerberos fan) is that
>> the multiple roundtrips problem isn't a Kerberos problem but more
>> related to all of the stuff layered on top of Kerberos (GSS, SPNEGO,
>> etc etc).  I see how we got here, but I always was a bit skeptical of
>> the value-add of all of those layers in practice.
> I suspect that Simo is referring to HTTP 401, 200, 401, 200, .. problem.
> That can happen with any HTTP authentication scheme, and I've seen that.
> The solution is to use cookies.
>
> GSS-API adds no round trips.  SPNEGO only adds a round trip if the
> initiator's optimistic choice fails.  Kerberos w/o mutual auth needn't
> add even one round trip to the application layer protocol (though having
> huge tickets doesn't help) provided the application is using the
> sub-session keys (i.e., GSS per-message tokens or KRB-PRIV/SAFE).
>
> The problem with Kerberos is not the round trips.
>
> The biggest problem with Kerberos is that the world has been moving to
> HTTP for everything, and in HTTP land the number of user-agent
> implementations is enormous, and most don't support Negotiate.
> Credential orchestration needs to be self-service in all deployments,
> regardless of whether we're talking about Kerberos or PKI.
>
>    (For this problem I've build an experimental Negotiate-as-a-service.)
>
> Another problem with Kerberos is credential orchestration -especially
> server credentials ("keytabs")- and the need for KDC synchronization.
> Just as there's a Let's Encrypt for the web that makes TLS server
> credential provisioning much simpler, Kerberos and anything else that
> requires server credentials also needs that.  Without this feature it's
> all just hard to use and scale.
>
> The lack of a standard "kadmin" protocol for fetching keys (and rotating
> them) is a serious interoperability problem that causes integration and
> provisioning pain.  (Maybe we should propose Heimdal's httpkadmind
> protocol?)
>
> There's also KDC synchronization that can be annoying.
>
>    (For this problem in Heimdal we've build a virtual service principal
>     namespace feature that derives service keys from the namespace's
>     keys, the principals' names, and each key rotation epoch.)
>
> It's not like it's all great with other authentication protocols.
>
>   - JWT lacks a fetch-a-rock protocol (like the TGS protocol).  Such a
>     protocol would have to be dead simple.
>
>   - OIDC requires both, clients _and_ servers to talk to OIDC issuers.
>
>   - OIDC and SAML transport authentication material in URI q-params.
>
>   - Client certificate support coverage is terrible and hard to use from
>     apps (especially where there's reverse proxy involved), plus the few
>     apps that support client certs don't have any support for using SANs!
>
>   - DIGEST is obsolete.
>
>   - SCRAM was obsolete the day it was born.
>
>   - PAKEs are not a general purpose solution.
>
> There are good reasons why Kerberos is still around; the shortcomings of
> other systems are among them.  But there's been zero work in 30 years on
> making Kerberos easy to deploy, orchestrate, and operate.  The number of
> people who are intimate with the protocol and who have the energy and
> funding to tackle these issues is dwindling.  That's not a recipe for
> success.
>
> Nico

-- 


Paul Romero
-----------
RCOM Communications Software
EMAIL:[e-mail]
PHONE: [phone]