Kerberos outside the firewall

Nordgren, Bryce L -FS bnordgren at fs.fed.us
Sun Nov 30 16:45:18 EST 2014


Renaming thread.

> Not sure what you mean by that; been doing cross-organization SSO for over
> 15 years with a wide variety of organizations; it works just fine.

>The specific implementation of Active Directory may require LDAP (or other
>protocol) access for Windows clients, but it is important to note that this is
>NOT a requirement for the Kerberos protocol in general.

I didn't say SSO didn't work. Also didn't say LDAP was required for Kerberos authentication to function. :) I said Kerberos wasn't a good SSO solution, mostly for the reasons given in [1] and [2]. Simply put, it is reasonable to believe that cross-organizational Kerberos SSO hasn't caught on because, real or perceived: "high maintenance is bad."

As to the other thing...I consider the absolute number one use case to be providing identities for desktop logins to Linux/Windows/Mac (real and virtual workstations as well as cluster machines). Number two use case would be standing up a file server. Number three would be providing identities for websites. All of the top three require additional user attributes, and not just for authorization. Kerberos in isolation is a pretty esoteric edge case in an enterprise environment. The question of why CIOs don't use Kerberos outside the firewall is ill-formed, and needs to become: "Why don't CIOs use Kerberos-containing identity solutions outside the firewall?" This makes consideration of those "other" components valid.

In the spirit of choosing our battles wisely, I sense that convincing my CIO to expose corporate identities to the internet is certainly a loser. My read of this list is that this may be common to more than just my CIO. If the heart of SSO is "no new passwords for users" rather than "my corporate identity everywhere else", then the path forward might be establishing a process where the local KDC can do initial authentication with a publicly exposed remote identity provider. There's been a fair amount of activity defining non-browser SASL workflows for OAuth and SAML. Close the loop: define a concise, logical, human-friendly way to express these foreign identities as Kerberos principals, define the effect on the transited path, define how to encode some subset of whatever attributes the remote source provides in the TGT, require some unspecified means of configuring permissible identity sources, and give that remote user a TGT for the local realm! If necessary, make a new KDC service ("WebAS") leveraging these non-browser SASL workflows.

Collaboration related machines and apps can get corralled into the DMZ, get their own Kerberos realm and WebAS enabled KDC (and attribute provider). The totally separate, not-trusted, DMZ-residing KDC can be the thing which leverages WebSSO. Corporate IDs can stay islanded inside the firewall.

Given a choice between solving the do-able technical problem and the intractable people problem, the technical problem should win. :)

Bryce

[1] https://tools.ietf.org/html/draft-ietf-cat-kerberos-pk-cross-08
[2] https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross-03




This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.



More information about the Kerberos mailing list