Kerberos outside the firewall

[Russ Allbery]

"Nordgren, Bryce L -FS" <bnordgren at fs.fed.us> writes:

> Again we return to the start: a lack of exposed Kerberos identities. The
> point of the suggestion was to make a bevy identities available to the
> top use cases for Kerberos: desktop/workstation logins and
> fileservers. SAML and OAuth are incompatible with this purpose, but
> that's where the available identities are.

But desktop/workstation logins and fileservers are generally *also* not
allowed outside of a VPN, so I don't understand what you're gaining.  The
resource to which you're trying to authenticate is likely to be even more
restricted than access to the Kerberos KDC because it's more vulnerable to
attack.  I'm pretty sure there are a lot more attacks on CIFS/SMB than
there are on Kerberos; the exposed protocol is far more complex.

> You'd likely only be using this method for remote identities, when
> Kerberos IDs are not exposed. And you're likely only doing this out in
> the DMZ, where you're supposed to be working with others. Is manually
> creating an account for the remote user and emailing them a password
> really better than just leveraging an existing authentication source?
> Hiring someone to deliver the password by phone?

If management is willing to expose a Kerberos-authenticated file server to
the Internet but not a Kerberos KDC to authenticate to that file server,
but *is* willing to expose some sort of authentication mechanism probably
built with passwords on top of SAML to the Internet and maintain some
complicated bridge to use that for file service and expose *that* to the
Internet... that management is so utterly confused about security and
authentication that I really can't predict what sort of nonsense they'd be
willing to do.  :)

If you're just looking for a collaborative file store outside of the
firewall and local restricted network environment because it's used for
collaboration with third parties, there are a wealth of cloud storage
providers that support exactly that use case and are willing to use SAML
identities or OpenID or other methods of identity that you're probably
already exposing.  For an environment that isn't willing to expose
Kerberos but does want to have collaborative, authenticated public file
stores, that's the route I personally would recommend.  (Full disclaimer:
I now work for one of those companies, but I believe I would have made the
same recommendation six months ago before I took a job there.)

Personally, I think you should just expose the Kerberos KDC to the
Internet and use AFS for shared file service, but I suspect the chances of
getting management to understand the merits of that approach are low.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>