Kerberos outside the firewall

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Kerberos outside the firewall

Nordgren, Bryce L -FS
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.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos outside the firewall

Russ Allbery-2
"Nordgren, Bryce L -FS" <[hidden email]> writes:

> 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.

Given that you cannot outsource any IT service without doing this, my
experience is that CIOs are not only willing but eager to find ways of
exposing corporate identities to the Internet.  It's more that this is
almost entirely to authenticate to web applications such as Salesforce,
and that's why Kerberos is not very interesting, not because it's the
Internet.  All that stuff these days is based on either SAML or OpenID.

It's completely routine to expose a SAML or OpenID identity provider to
the Internet at large, even assuming you're talking about the sort of
environment where the company isn't using "Google authentication" for a
ton of things anyway.

> 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.

I think the biggest problem with this approach is that most SAML
authentications aren't based on an identity, at least solely.  Rather,
they're based on some sort of attribute set, probably best thought of as
roles.  SAML carries a bunch of attributes, such as whether the person is
an employee, whether they should have access to this application or that
one, and so on.  In other words, it's both an authorization and an
authentication system, whereas Kerberos provides only the authentication
component.

What you're describing is essentially extending Kerberos to carry
authorization information.  I'm a bit dubious about that, if for no other
reason than that extending the size of Kerberos tickets causes various
problems, and there are lots of other, well-established authorization
systems these days.  So it's not clear why one would want to reinvent that
partiuclar set of wheels.

> 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.

And this is the approach that we took at Stanford, and that I think is
fairly common: Kerberos is the internal authentication mechanism, and is
used to authenticate our users to the identity providers for things like
SAML.  Information exchange with trusted third parties is done via
protocols like SAML that can carry a richer set of information.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos outside the firewall

Ken Hornstein
In reply to this post by Nordgren, Bryce L -FS
>I didn't say SSO didn't work. Also didn't say LDAP was required for
>Kerberos authentication to function. :)

Your EXACT words were:

  Kerberos is not a complete identity solution. You would also need to
  expose the LDAP p[ao]rt which parcels out a few user attributes (name,
  email, something like an SID or UID/GID...)

Considering the context of the discussion was about authenticating via
Kerberos across the Internet, at best this statement is misleading.

>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."

Meh.  I'm not sure it's a peception of high maintenance (the maintenance
of cross-realm trust is essentially zero).  I get the feeling that the
reasons are more due to a lack of understanding about Kerberos.  The average
AD administrator doesn't understand about Kerberos; they know that
users authenticate to the AD domain controller, but they don't know what
that means from a protocol persecptive.  Combine that with the official
guidance from Microsoft ... it's a hard sell to the average AD administrator.

>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.

Again, I think you're kind of missing the thrust of the discussion.  The
usual case is clients may be outside of your firewall, but the application
servers (the ones that need access to LDAP or some other authorization
service) are inside of your trust boundary.  That's pretty straightforward,
but again it would require Internet access to the domain controller,
which is a non-starter for a lot of people.

Note that this whole thing springs from the comments from MIT asking why
people wouldn't want to expose their KDC to the Internet, since Kerberos
was designed to solve the exact problem of authentication users over
untrusted networks.

I'm neutral about the new PKCROSS proposals; at a MINIMUM it will be 5
years before they become usable (I'm talking about the time it would
take to go through the standards process, get implemented and supported
in common software, etc).  That's the best case, and to me that's a long
time to wait.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Kerberos outside the firewall

Nordgren, Bryce L -FS
In reply to this post by Russ Allbery-2
> > 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.
>
> Given that you cannot outsource any IT service without doing this, my
> experience is that CIOs are not only willing but eager to find ways of exposing
> corporate identities to the Internet.  It's more that this is almost entirely to
> authenticate to web applications such as Salesforce, and that's why Kerberos
> is not very interesting, not because it's the Internet.  All that stuff these days
> is based on either SAML or OpenID.

I need to refine then: Convincing my CIO to expose corporate Kerberos IDs is a loser. My CIO has operated a public facing SAML IdP since 2006-7 or so. The original question was asked because of an observed recalcitrance concerning the exposure of Kerberos IDs. To clarify, have you observed an eagerness on the part of CIOs to expose Kerberos IDs?

> I think the biggest problem with this approach is that most SAML
> authentications aren't based on an identity, at least solely.  Rather, they're
> based on some sort of attribute set, probably best thought of as roles.  SAML
> carries a bunch of attributes, such as whether the person is an employee,
> whether they should have access to this application or that one, and so on.
> In other words, it's both an authorization and an authentication system,
> whereas Kerberos provides only the authentication component.

It's easy to discard information. If it doesn't belong in Kerberos, don't include it in the ticket. Remote roles are likely not useful in a local environment anyway. Things typically used for authorization (UidNumber) are particularly prone to collision if one is foolish enough to directly leverage that attribute in the local realm. Useful attributes describe the human (name/GECOS, email, etc.). If there's a way to package this useful data in the TGT, great. Otherwise, let the larger identity solution handle it. (This does imply that the server API would need an interface for people to write an "attribute inspector", so that interesting-but-not-for-Kerberos data can be captured.)


> > 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.
>
> And this is the approach that we took at Stanford, and that I think is fairly
> common: Kerberos is the internal authentication mechanism, and is used to
> authenticate our users to the identity providers for things like SAML.
> Information exchange with trusted third parties is done via protocols like
> SAML that can carry a richer set of information.

I was actually proposing the opposite flow: use SAML or OAuth IdPs to authenticate users to Kerberos (WebAS). :) If the user can successfully authenticate to the AS using one of the SASL non-web SAML or OAuth workflows, they should get a local TGT (provided the KDC is configured for this).

All we'd be changing is the need for a shared secret between the user and the KDC. The principal name can reflect the fact that the client does not originate in the local realm. Operationally, this gives the local realm access to identities in the SSO ecosystems which can fairly be described as "thriving"; reduces the number of accounts one has to create for external partners; and avoids the people problem of trying to convince admins to expose Kerberos identities.

Bryce





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.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos outside the firewall

Russ Allbery-2
"Nordgren, Bryce L -FS" <[hidden email]> writes:

> I was actually proposing the opposite flow: use SAML or OAuth IdPs to
> authenticate users to Kerberos (WebAS). :) If the user can successfully
> authenticate to the AS using one of the SASL non-web SAML or OAuth
> workflows, they should get a local TGT (provided the KDC is configured
> for this).

I think this is working against the strengths of both systems.

Kerberos is really good at authenticating users -- there are tons of
programs and local tools for managing this, it's integrated with device
login, and so forth.  But it's bad at conveying attributes and
authorization.  SAML is great at conveying attributes about a user but
completely punts on authentication, requiring that you provide some local
auth mechanism (which often defaults to something crappy like passwords).

So using Kerberos for authorization and SAML for authentication is really
unintuitive to me, and I think is maximizing your pain levels.  :)
Whereas using Kerberos for authentication and then exposing that
information via SAML is well-trod ground.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Kerberos outside the firewall

Nordgren, Bryce L -FS
> So using Kerberos for authorization and SAML for authentication is really
> unintuitive to me, and I think is maximizing your pain levels.  :) Whereas using
> Kerberos for authentication and then exposing that information via SAML is
> well-trod ground.

I'm not certain where using Kerberos for authorization came into this. :) Can we just agree not to do it and stop talking of it?

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.

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?

Bryce






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.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos outside the firewall

Russ Allbery-2
"Nordgren, Bryce L -FS" <[hidden email]> 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 ([hidden email])              <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Kerberos outside the firewall

Nordgren, Bryce L -FS
> But desktop/workstation logins and fileservers are generally *also* not
> allowed outside of a VPN, so I don't understand what you're gaining.

There simply is no one VPN to cover all the actors.

I am not speaking hypothetically or "generally". The meat and potatoes of this research organization is to collaborate with external users who  cannot access our VPN. To share Terabytes of data. And process it. With something that's not a website. The absolute number one obstacle to getting work done is exactly the sentiment you just expressed. I would also be willing to bet that the lack of Kerberos IDs outside the firewall is due to this sentiment running rampant. If there's nothing to be gained by exposing the KDC, why do it? It's not necessarily a lack of education, it could merely be due to the belief that the primary consumers of Kerberos IDs are things which are not allowed outside of their VPN. That is a self-fulfilling prophecy which affords no opportunity for correction.

Hence, issuing a TGT to an ID which _is_ exposed.

Bryce




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.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos outside the firewall

Russ Allbery-2
"Nordgren, Bryce L -FS" <[hidden email]> writes:

> I am not speaking hypothetically or "generally". The meat and potatoes
> of this research organization is to collaborate with external users who
> cannot access our VPN. To share Terabytes of data. And process it. With
> something that's not a website. The absolute number one obstacle to
> getting work done is exactly the sentiment you just expressed.

Yeah, you're definitely looking for AFS.

No idea if you can politically deploy it, but this is *exactly* the use
case that AFS was designed to solve, and what it's used for extensively in
the high energy physics community.

But yeah, you're going to need cross-realm Kerberos in order to be able to
do it.

> I would also be willing to bet that the lack of Kerberos IDs outside the
> firewall is due to this sentiment running rampant.  If there's nothing
> to be gained by exposing the KDC, why do it?  It's not necessarily a
> lack of education, it could merely be due to the belief that the primary
> consumers of Kerberos IDs are things which are not allowed outside of
> their VPN.  That is a self-fulfilling prophecy which affords no
> opportunity for correction.

My point is that the file service is much harder to secure than Kerberos.
I get that you have management who apparently have no idea what they're
talking about but are still making security decisions, and that's, alas,
really common in this space.  That's partly Ken's point as well, and there
are some really unfortunate misconceptions created by the way that Active
Directory tends to mix all this together alongside things that are more
vulnerable to attack.  But if one understands the protocols involved, one
gets very dubious about the idea that exposing the file servers is safe
and exposing Kerberos is not.

Yeah, I know you can make lots of arguments about how Kerberos can be used
to access other things, and is the keys to the kingdom, and the file
servers are more limited, and so forth, but none of them really hold water
for me at least.  There are other ways to work around those problems, and
Kerberos is really pretty easy to secure; the protocol surface is not
large, and you can still rely on network proximity and multifactor for the
VPN to protect other critical things.  I don't think it's the likely
attack vector.  We always exposed Kerberos directly to the Internet at
Stanford.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Kerberos outside the firewall

Nordgren, Bryce L -FS
> But if one understands the protocols involved, one gets very dubious
> about the idea that exposing the file servers is safe and exposing Kerberos is
> not.

Ah, that's the problem.

Here, anyway, the model where "one" person/entity makes self-consistent decisions concerning the entire enterprise IT stack is flawed. The CIO is responsible for the corporate identity store and the end users are currently responsible for all collaboration IT (from ISP to DHCP/DNS to OS to applications, all the while "pinky swearing" that we will obey all applicable regulations, whatever they might be.) Absolutely no one holds the position you just expressed.  That's just the inevitable result  of bad policies which require regular exceptions for the organization to function.

We're making progress in terms of getting a CIO managed collaboration network, but so far we've only got buy in from the enterprise network team, and not the identity management team. It will take both of these teams ganging up on the enterprise security team to get any kind of traction on exposing Kerberos IDs. If this kind of fragmentation is common elsewhere, it may explain why railing against a lack of understanding has not worked. You need some serious motivation (i.e., pushback) to overcome this kind of inertia.

Or, "go with the flow" and just adapt the corporate IDs that they do publish. Depends on how fond of pain you are, I guess. :) May not be ideal, but it's better than nothing.

Bryce







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.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos