Kerberos n00b question.

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

Kerberos n00b question.

Grant Taylor
Hi,

I have what may seem like a Kerberos n00b question.

I've been around, but largely ignored, Kerberos for years.  As I'm now
investigating doing things with it, and really liking what I'm seeing,
I'm starting to wonder if there are any security guidelines about where
it's safe to use Kerberos.

It's my (mis?)understanding that communications between Kerberos clients
and the KDC are in the clear (but do not include the password), and that
there is functionally no communications between a remote server and the KDC.

As such, I'm wondering if it would be relatively safe enough to use
Kerberos to authenticate to a VPS in the cloud when both the client and
KDC are on the LAN.  I think Kerberized SSH would be the only Kerberos
related traffic across the Big Bad Internet to the VPS.  Is this correct?

Can anyone point me to some general reading that any /a ll Kerberos n00b
should read?  (I've been following How-Tos and gotten a lot to work.)

Thank you in advance.



--
Grant. . . .
unix || die


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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Russ Allbery-2
Grant Taylor <[hidden email]> writes:

> It's my (mis?)understanding that communications between Kerberos clients
> and the KDC are in the clear (but do not include the password), and that
> there is functionally no communications between a remote server and the
> KDC.

I don't think describing it as "in the clear" is quite right, but a
default Kerberos configuration using enc-timestamp and no tunneling as the
preauth mechanism is somewhat vulnerable to packet capture followed by an
off-line dictionary attack to recover the authentication key.  The
standard solution for this is FAST, which protects the initial
authentication against this attack.  (You do need some other credential to
set up the FAST tunnel, but you can use anonymous Diffie-Hellman via
anonymous PKINIT, or you can use a randomized key.)

The attack still requires subsequent work; you can't just snoop the
connection between the client and the KDC and immediately get credentials.
The work factor is basically linked to the complexity of the client key,
so it's not much of a worry for a randomized key but is a worry for user
passwords.

> As such, I'm wondering if it would be relatively safe enough to use
> Kerberos to authenticate to a VPS in the cloud when both the client and
> KDC are on the LAN.  I think Kerberized SSH would be the only Kerberos
> related traffic across the Big Bad Internet to the VPS.  Is this
> correct?

Yes.

> Can anyone point me to some general reading that any /a ll Kerberos n00b
> should read?  (I've been following How-Tos and gotten a lot to work.)

I don't have a good answer for this, unfortunately.

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

Grant Taylor
On 01/07/2019 10:53 AM, Russ Allbery wrote:
> I don't think describing it as "in the clear" is quite right, but a
> default Kerberos configuration using enc-timestamp and no tunneling as
> the preauth mechanism is somewhat vulnerable to packet capture followed
> by an off-line dictionary attack to recover the authentication key.

Sorry, "in the clear" may have been a poor choice of words.  I was
meaning to imply "revealed more than desired in an untrusted ~> hostile
network", particularly in the context of between clients and the KDC.

> The standard solution for this is FAST, which protects the initial
> authentication against this attack.  (You do need some other credential
> to set up the FAST tunnel, but you can use anonymous Diffie-Hellman via
> anonymous PKINIT, or you can use a randomized key.)

Would you please expand (what I assume is) the FAST acronym?  I expect
that there will be quite a few phonetic collisions searching for "FAST".

> The attack still requires subsequent work; you can't just snoop the
> connection between the client and the KDC and immediately get credentials.
> The work factor is basically linked to the complexity of the client key,
> so it's not much of a worry for a randomized key but is a worry for
> user passwords.

Good to know.  Thank you for explaining.

> Yes.

:-)

> I don't have a good answer for this, unfortunately.

Fair enough.



--
Grant. . . .
unix || die


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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Russ Allbery-2
Grant Taylor <[hidden email]> writes:
> On 01/07/2019 10:53 AM, Russ Allbery wrote:

>> The standard solution for this is FAST, which protects the initial
>> authentication against this attack.  (You do need some other credential
>> to set up the FAST tunnel, but you can use anonymous Diffie-Hellman via
>> anonymous PKINIT, or you can use a randomized key.)

> Would you please expand (what I assume is) the FAST acronym?  I expect
> that there will be quite a few phonetic collisions searching for "FAST".

I think it stands for Flexible and Secure Tunneling.  It's defined in:

    https://tools.ietf.org/html/rfc6113.html

The keywords "kerberos fast" in Google seem to turn up the right stuff
(rather more than I had expected; I like you was expecting that to be
drowned by performance stuff).

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

Robbie Harwood
In reply to this post by Grant Taylor
Grant Taylor <[hidden email]> writes:

> I've been around, but largely ignored, Kerberos for years.  As I'm now
> investigating doing things with it, and really liking what I'm seeing,
> I'm starting to wonder if there are any security guidelines about
> where it's safe to use Kerberos.

Always.  But like any security system, you have to set it up right.

> It's my (mis?)understanding that communications between Kerberos
> clients and the KDC are in the clear (but do not include the
> password), and that there is functionally no communications between a
> remote server and the KDC.

No, communication isn't in the clear.  It may provide some intuition of
what Kerberos communicates (though is no longer entirely technically
accurate) to look at https://web.mit.edu/Kerberos/www/dialogue.html

The biggest concern in a new Kerberos deployment is secrets being based
on passwords.  To varying degrees, this reduces the strength of the
system as a whole to the strength of the passwords.  In the system
proposed in the dialogue above, for instance, it's possible to observe
an exchange and mount an offline dictionary attack against it.  More
information on mitigating that (which isn't too hard) can be found here:
https://web.mit.edu/kerberos/krb5-devel/doc/admin/dictionary.html#dictionary

> As such, I'm wondering if it would be relatively safe enough to use
> Kerberos to authenticate to a VPS in the cloud when both the client
> and KDC are on the LAN.  I think Kerberized SSH would be the only
> Kerberos related traffic across the Big Bad Internet to the VPS.  Is
> this correct?

See above.

> Can anyone point me to some general reading that any /a ll Kerberos
> n00b should read?  (I've been following How-Tos and gotten a lot to
> work.)

It's worth mentioning that there are turnkey solutions for configuring
entire identity management systems (i.e., including Kerberos) now.  For
instance, we develop FreeIPA ( https://www.freeipa.org/ ), which will
mitigate these threats by default.

Thanks,
--Robbie

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

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Grant Taylor
On 01/07/2019 12:21 PM, Robbie Harwood wrote:
> Always.  But like any security system, you have to set it up right.

Yep.

I'm trying to gain a working foundation of Kerberos to try to avoid
doing blatantly bad things.  I'm also looking to find more information
and learn.

> No, communication isn't in the clear.  It may provide some intuition
> of what Kerberos communicates (though is no longer entirely technically
> accurate) to look at https://web.mit.edu/Kerberos/www/dialogue.html

Interesting read.

I watched a few videos about Kerberos over the holidays.

1)  Link - Basic Kerberos Authentication
      - https://www.youtube.com/watch?v=u7MQoSN19O4
2)  Link - Kerberos Delegation and Protocol Transition
      - https://www.youtube.com/watch?v=UGWP4ewxcTA
3)  Link - Kerberos Authentication on BIG-IP APM
      - https://www.youtube.com/watch?v=NDFJ7m8iaPA
4)  Link - 6.858 Fall 2014 Lecture 13: Kerberos
      - https://www.youtube.com/watch?v=bcWxLl8x33c

#4 is an 80 minute lecture from MIT.  I found it and #1 to be quite
informative about where packets flow between.

> The biggest concern in a new Kerberos deployment is secrets being
> based on passwords.  To varying degrees, this reduces the strength of
> the system as a whole to the strength of the passwords.

Yep.

I suspect the -randkey option when adding a principal is significantly
better than a password.

I wonder if there is any possibility of users using a random key that is
password protected.  Thus using the password unlocking the random key
that is used to secure communications.  -  I suspect that would make
keys used for users as secure as -randkey for services, at least as far
as brute forcing things.  Of course you would need to protect the
encrypted key.  But that's a different issue.

> In the system proposed in the dialogue above, for instance,
> it's possible to observe an exchange and mount an offline
> dictionary attack against it.  More information on
> mitigating that (which isn't too hard) can be found here:
> https://web.mit.edu/kerberos/krb5-devel/doc/admin/dictionary.html#dictionary

That's an interesting read.

I wonder if I should recreate my user principals (the few that exist in
my test REALM) using "+requires_preauth -allow_svr".

I'll do some more reading on the other defenses / mitigations listed.
You might have seen the exchange with Russ A. about FAST.

More reading.  More to learn.

> See above.

Sorry, I can't translate that to what your opinion is about using
Kerberos between a LAN client (with a local KDC) and a web server across
the Internet.  (Thus the client <-> KDC interaction is on the LAN.)

I'll need to re-read dialogue to track what communications is happening
between what entities.

I'm trying to build a mental model / working understanding of what
communications between KDC <-> client <-> server is sensitive and what
is okay to send across the Internet.  I /think/ that client <-> server
is okay as part of SSH.  -  I'm trying to understand if the client <->
server is okay on it's own, or if it's also relying on security offered
by SSH.  Mainly so that I can judge how safe it is to use for other
protocols between the client and server (with or without other encryption).

I think the biggest issue is that I need to get the keytab to the server
in a secure manner.  I would expect that something like scp / sftp would
suffice.

> It's worth mentioning that there are turnkey solutions for configuring
> entire identity management systems (i.e., including Kerberos) now.
> For instance, we develop FreeIPA ( https://www.freeipa.org/ ), which
> will mitigate these threats by default.

I was vaguely aware of FreeIPA.  (I think) I now know more about
FreeIPA.  FreeIPA seems to be a purpose built Linux distribution that
incorporates the technologies listed under Main features section of the
link you provided.

I feel like FreeIPA is analogous to a Lego set that produces one
particular structure using the aforementioned technologies as some of
the Lego bricks.  -  I personally want to learn how to use the Lego
bricks within my existing structures.  I've already got LDAP, Kerberos,
NTP, DNS, and SSSD working (to my satisfaction).  So I'm reluctant to
throw those integrated things out and introduce a new turn key
appliance, namely a FreeIPA (V)M.

I do want to do some more looking at the Dogtag certificate system to
see how it is used and how it integrates with Kerberos.

Thank you for the detailed reply Robbie.



--
Grant. . . .
unix || die


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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Russ Allbery-2
Grant Taylor <[hidden email]> writes:

> I wonder if there is any possibility of users using a random key that is
> password protected.  Thus using the password unlocking the random key
> that is used to secure communications.  - I suspect that would make keys
> used for users as secure as -randkey for services, at least as far as
> brute forcing things.  Of course you would need to protect the encrypted
> key.  But that's a different issue.

If you want to go down this path, I would take a look at PKINIT, which
replaces the initial authentication request using a password-derived key
with X.509 mutual authentication.  You have to figure out a PKI strategy
to give the users certificates, but that then effectively gives you what
you describe: a password-protected random key.

I have also implemented half-assed versions of this, such as putting a
service with permissions to mint Kerberos TGTs for users behind SSH public
key authentication, so that users can use an SSH keypair to get a Kerberos
TGT.

> I /think/ that client <-> server is okay as part of SSH.  - I'm trying
> to understand if the client <-> server is okay on it's own, or if it's
> also relying on security offered by SSH.  Mainly so that I can judge how
> safe it is to use for other protocols between the client and server
> (with or without other encryption).

The client/server exchange uses GSS-API, which is fine on its own and
doesn't rely on the SSH encrypted tunnel to be secure.

> I think the biggest issue is that I need to get the keytab to the server
> in a secure manner.  I would expect that something like scp / sftp would
> suffice.

You may or may not want to think about the chain of trust for the server
(i.e., how do you know that you're scp'ing the keytab to the correct
machine).  In an ideal world, the machine is launched with some existing
credentials (like a TLS private key) that are installed on it securely,
and then you use those credentials to bootstrap other credentials it
needs, such as keytabs.

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

Grant Taylor
On 1/7/19 7:31 PM, Russ Allbery wrote:
> If you want to go down this path, I would take a look at PKINIT, which
> replaces the initial authentication request using a password-derived key
> with X.509 mutual authentication.

I'll definitely be taking a look at PKINIT, SPAKE, HTTPS proxy, and OTP
as they relate to Kerberos.

I want to understand what they are, what they do, and how they do it
from a high level.  That way I can make a (somewhat) informed decision
if I want to integrate them into my sandbox / lab / scratch monkey
environment or not.

> You have to figure out a PKI strategy to give the users certificates, but
> that then effectively gives you what you describe: a password-protected
> random key.

ACK

Thank you for letting me know.  :-)

> I have also implemented half-assed versions of this, such as putting
> a service with permissions to mint Kerberos TGTs for users behind SSH
> public key authentication, so that users can use an SSH keypair to get
> a Kerberos TGT.

I'm intrigued.  But I suspect I should stick with the relatively
straight and narrow while doing due diligence and learning about
Kerberos and how to get rid of my n00b feathers.

> The client/server exchange uses GSS-API, which is fine on its own and
> doesn't rely on the SSH encrypted tunnel to be secure.

I'm glad to have that confirmed.

That supports my understanding that the somewhat sensitive (as in I
don't want it on the open Internet for anyone to see) client <-> KDC is
where I need to play it safer.

> You may or may not want to think about the chain of trust for the server
> (i.e., how do you know that you're scp'ing the keytab to the correct
> machine).

I agree with your thought process.  That's way out in front of me for
now.  I'm looking at testing Kerberos in my (lab) LAN and pontificating
using GSS-API to authenticate things like SSH, and eventually IMAPS &
SMTP (w/ STARTTLS), to select few test VPSs.  This is still very much
exploratory phase with pet systems.  I don't have a good enough
understanding of the Kerberos technology to even think about applying it
to cattle VPSs yet.  Slow steps.  Understand who, what, when, where,
why, and how before running.

> In an ideal world, the machine is launched with some existing credentials
> (like a TLS private key) that are installed on it securely, and then
> you use those credentials to bootstrap other credentials it needs,
> such as keytabs.

Agreed.  When I get there.

For now, it's pet VPSs that I'm already logging into via ssh keys /
certificates and trust (as much as reasonably possible).  I'm 99%
confident that when I push a keytab to the server, that it will be the
server that I'm expecting.

But duly noted on your concern and idea about priming.

Thank you again for your insight Russ.



--
Grant. . . .
unix || die


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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Robbie Harwood
In reply to this post by Grant Taylor
Grant Taylor <[hidden email]> writes:

> On 01/07/2019 12:21 PM, Robbie Harwood wrote:
>
>> The biggest concern in a new Kerberos deployment is secrets being
>> based on passwords.  To varying degrees, this reduces the strength of
>> the system as a whole to the strength of the passwords.
>
> Yep.
>
> I suspect the -randkey option when adding a principal is significantly
> better than a password.
>
> I wonder if there is any possibility of users using a random key that
> is password protected.  Thus using the password unlocking the random
> key that is used to secure communications.  - I suspect that would
> make keys used for users as secure as -randkey for services, at least
> as far as brute forcing things.  Of course you would need to protect
> the encrypted key.  But that's a different issue.
It still reduces to the security of a password (the one locking the
random key).  But as Russ points out, you may be interested in PKINIT if
users choosing strong passwords is a serious worry.

Also!  2FA will mitigate this concern somewhat as well.  krb5 is
prepared to hand off to a RADIUS responder for OTP (freeIPA uses this,
which I know you're not interested in but is meaningful as a PoC); you
can then use something like freeOTP or a physical 2fa token for
acquiring additional credentials.

>> In the system proposed in the dialogue above, for instance,
>> it's possible to observe an exchange and mount an offline
>> dictionary attack against it.  More information on
>> mitigating that (which isn't too hard) can be found here:
>> https://web.mit.edu/kerberos/krb5-devel/doc/admin/dictionary.html#dictionary
>
> That's an interesting read.
>
> I wonder if I should recreate my user principals (the few that exist in
> my test REALM) using "+requires_preauth -allow_svr".
You don't have to recreate them, but yes, it's a good idea to set
+requires_preauth.  Setting -allow_svr will I believe block the use of
U2U and make kvno on user principals no longer work, but this may be
acceptable to you.

>> See above.
>
> Sorry, I can't translate that to what your opinion is about using
> Kerberos between a LAN client (with a local KDC) and a web server across
> the Internet.  (Thus the client <-> KDC interaction is on the LAN.)

Apologies.  I consider Kerberos (with preauth and strong passwords) safe
for internet use, as I imagine the rest of us on here do as well.

> I'm trying to build a mental model / working understanding of what
> communications between KDC <-> client <-> server is sensitive and what
> is okay to send across the Internet.  I /think/ that client <-> server
> is okay as part of SSH.  -  I'm trying to understand if the client <->
> server is okay on it's own, or if it's also relying on security offered
> by SSH.  Mainly so that I can judge how safe it is to use for other
> protocols between the client and server (with or without other encryption).

Kerberos exchanges are not reliant on additional layers of encapsulation
for security.  Russ went into more detail on this I think for SSH.  But
it's all encrypted with pre-shared knowledge, be it passwords or keytabs
or certs (or things derived from those) - except for things that don't
need to be kept secret, like usernames.

> I think the biggest issue is that I need to get the keytab to the server
> in a secure manner.  I would expect that something like scp / sftp would
> suffice.

Yes.  Provisioning is always the hard part in any cryptosystem :)

It's possible to, on the server, kinit and acquire the keytab that way.
But if you're SSHing in already, there isn't really an advantage to
that.

>> It's worth mentioning that there are turnkey solutions for configuring
>> entire identity management systems (i.e., including Kerberos) now.
>> For instance, we develop FreeIPA ( https://www.freeipa.org/ ), which
>> will mitigate these threats by default.
>
> I was vaguely aware of FreeIPA.  (I think) I now know more about
> FreeIPA.  FreeIPA seems to be a purpose built Linux distribution that
> incorporates the technologies listed under Main features section of the
> link you provided.

It's not a Linux distro - it's a tool that can be run on man distros -
but yes.

> I feel like FreeIPA is analogous to a Lego set that produces one
> particular structure using the aforementioned technologies as some of
> the Lego bricks.  - I personally want to learn how to use the Lego
> bricks within my existing structures.  I've already got LDAP,
> Kerberos, NTP, DNS, and SSSD working (to my satisfaction).  So I'm
> reluctant to throw those integrated things out and introduce a new
> turn key appliance, namely a FreeIPA (V)M.

Totally fine!  I also appreciate the need to tinker - but I've also set
up enough realms to be tired of trying to figure out what I did wrong
with LDAP this time :)

Thanks,
--Robbie

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

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Russ Allbery-2
Robbie Harwood <[hidden email]> writes:

> Also!  2FA will mitigate this concern somewhat as well.  krb5 is
> prepared to hand off to a RADIUS responder for OTP (freeIPA uses this,
> which I know you're not interested in but is meaningful as a PoC); you
> can then use something like freeOTP or a physical 2fa token for
> acquiring additional credentials.

I wonder how hard it would be to add WebAuthn as a preauth mechanism for
Kerberos as part of a FAST chain.  HOTP/TOTP don't have the greatest
security properties, even though most Kerberos use cases are inherently
less vulnerable to phishing than the typical web authentication use.

> Apologies.  I consider Kerberos (with preauth and strong passwords) safe
> for internet use, as I imagine the rest of us on here do as well.

Internet use is very common in the Kerberos community.  It is somewhat
vulnerable to weak user passwords, but I'd probably invest my effort in
FAST via anonymous PKINIT to solve that problem instead of network
tunnels.

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

Grant Taylor
In reply to this post by Robbie Harwood
On 1/8/19 6:02 PM, Robbie Harwood wrote:
> It still reduces to the security of a password (the one locking the
> random key).

I agree that the passwords are the weakest link.  But I thought (hoped)
that it would bolster the strength of the (derived) key that Kerberos uses.

> But as Russ points out, you may be interested in PKINIT if users choosing
> strong passwords is a serious worry.

I am interested and will be reading about PKINIT.

I read <~> skimmed RFC 6113 earlier today.  -  I feel like I'm trying to
swim with cloths on.  High level concepts make some sense.  But I'm
still getting enough bearings to be able to make more sense of things
without getting too mired down in details.  -  I'm looking for a
conceptual overview / understanding of what things do at the moment.

It seems as if FAST provides an extension framework that a number of
things can use, including some options to provide encrypted
pre-authentication connections.

I think that PKINIT is another method to derive some of the values that
FAST can use.

> Also!  2FA will mitigate this concern somewhat as well.

I was wondering about 2nd factor authentication.  I have a YubiKey
that's waiting for my attention.

Would I be correct in assuming that (from a Kerberos point of view) the
1st and 2nd factors are used during the kinit process?  Meaning that all
of the SSO functions still work unimpeded?

I think that it's more that I want to set Kerberos up using best
practices as I start using it.  I don't want to start something new
(like build a website) and then find out that I made a bone headed
mistake (like not salting hashed passwords).

Everything I'm doing, Kerberos included, is functionally for me, myself,
and I.  I'm still trying to decide which one has the worst security posture.

> krb5 is prepared to hand off to a RADIUS responder for OTP

I've been meaning to read about RADIUS as I know that it's an integral
component of 802.1X which I want to set up when I find a few spare
Round-Tuits.

> (freeIPA uses this, which I know you're not interested in but is
> meaningful as a PoC);

There's nothing at all wrong with playing with the boxed Lego set to
learn how things are done.  Once I've done that, I tear all the pieces
apart and build my own thing, or add on to my other things.

> you can then use something like freeOTP or a physical 2fa token for
> acquiring additional credentials.

*nod*

> You don't have to recreate them, but yes, it's a good idea to set
> +requires_preauth.  Setting -allow_svr will I believe block the use of
> U2U and make kvno on user principals no longer work, but this may be
> acceptable to you

I need to do some more reading on what user-to-user and kvno are to know
if I care about them.

The main thing that I care about that I'm not sure if it's impacted or
not is .k5login / .k5users.  -  I don't think that would be impacted,
but I don't know enough to confidently say one way or the other.

The little bit of reading that I just did on key version number (kvno)
sounds unrelated to servers / services (what I think of with allow_svr).
  I need to do more reading.

On the surface, I think I'd like to keep kvno functional.

Would -allow_svr have any impact on protocol translation?  (I think
that's the term.)  I.e. when a non-Kerberos aware client logs into IMAPS
with username & password and the daemon translates / gateways / bridges
into Kerberos on the client's behalf?  (I saw something about that in
one of the first three videos I mentioned in a previous message.)

> Apologies.  I consider Kerberos (with preauth and strong passwords)
> safe for internet use, as I imagine the rest of us on here do as well.

:-)

Good.  I'm starting to get similar impression as I read more things.  I
still think I want to keep client <-> KDC on the same LAN.  But I'm
getting more and more comfortable with using Kerberos, via GSSAPI, with
services across the Internet.

> Kerberos exchanges are not reliant on additional layers of encapsulation
> for security.  Russ went into more detail on this I think for SSH.
> But it's all encrypted with pre-shared knowledge, be it passwords or
> keytabs or certs (or things derived from those) - except for things that
> don't need to be kept secret, like usernames.

ACK

> Yes.  Provisioning is always the hard part in any cryptosystem :)
>
> It's possible to, on the server, kinit and acquire the keytab that way.
> But if you're SSHing in already, there isn't really an advantage to that.

Agreed.

I do think that would expose the Kerberos client (the server in this
context) to KDC exchange to the Internet.  Which it sounds like this is
reasonably secure enough.

I was not aware that I could get the keytab via kinit.  I had used
kadmin on clients (in the LAN) to get it.  -  This is why I ask questions.

> It's not a Linux distro - it's a tool that can be run on man distros -
> but yes.

Thank you for the clarification.

> Totally fine!  I also appreciate the need to tinker - but I've also set
> up enough realms to be tired of trying to figure out what I did wrong
> with LDAP this time :)

LOL

Fair enough.

I'm not there (yet).  And I still want to graft the new Kerberos colored
Lego bricks into my existing creations.  (For better or worse.)

> Thanks,

You're welcome.  But it is me that needs to say thank you.  You and Russ
have given me a lot to read and think about.  I appreciate that.  :-)



--
Grant. . . .
unix || die


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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Grant Taylor
In reply to this post by Russ Allbery-2
On 1/8/19 6:22 PM, Russ Allbery wrote:
> I wonder how hard it would be to add WebAuthn as a preauth mechanism
> for Kerberos as part of a FAST chain.  HOTP/TOTP don't have the greatest
> security properties, even though most Kerberos use cases are inherently
> less vulnerable to phishing than the typical web authentication use.

I have no idea.  It sounds interesting though.

> Internet use is very common in the Kerberos community.

Does this include client <-> KDC?

> It is somewhat vulnerable to weak user passwords, but I'd probably invest
> my effort in FAST via anonymous PKINIT to solve that problem instead of
> network tunnels.

Ya.  I like bolstering Kerberos's security via FAST w/ PKINIT more than
the tunnels.  Tunnels just introduce another complexity ~> failure
point.  (Even IPSec Transport Mode.)

My cursory reading makes me think that FAST is what provides the
security (by encrypting more things through the Fast and Secure Tunnel)
using parameters derived via PKINIT.



--
Grant. . . .
unix || die


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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Russ Allbery-2
Grant Taylor <[hidden email]> writes:
> On 1/8/19 6:22 PM, Russ Allbery wrote:

>> Internet use is very common in the Kerberos community.

> Does this include client <-> KDC?

Yes.  A lot of higher education institutions that have used Kerberos for
many, many years have their KDCs directly on the Internet and allow
clients to authenticate from anywhere.

> My cursory reading makes me think that FAST is what provides the
> security (by encrypting more things through the Fast and Secure Tunnel)
> using parameters derived via PKINIT.

PKINIT is just a replacement preauth mechanism, instead of enc-timestamp.
Basically, the client uses an X.509 authentication instead of a proof of
key possession as the preauthentication step to establish a shared session
secret that is used to encrypt the TGT.  (This may not be 100% accurate;
it's been a while since I dug into the protocol.)

FAST is a replacement for the whole preauth step.  It uses some
pre-existing shared session key between the KDC and the client to encrypt
the whole preauthentication exchange.  Inside of that, you can use various
preauthentication mechanisms.

Where they usefully combine is in how to get that pre-existing shared
session key to be able to start using FAST.  This is a chicken-and-egg
problem with traditional Kerberos: you have to authenticate first in order
to authenticate.  You can, for instance, use the local host key (which is
probably randomly generated and therefore safer to use in a direct
exchange with the KDC) to get a session key to start FAST, and then do
preauthentication with the (weaker) password-derived key.

Anonymous PKINIT lets you out of that trap by letting the client
"authenticate" with anonymous Diffie-Hellman to the KDC.  This doesn't
establish any meaningful identity, but it *does* get you a shared session
key, and with that you can start FAST, and use it to protect any
subsequent preauthentication exchange.

Note that you can enable anonymous PKINIT even if you don't otherwise use
PKINIT and don't have any client certificates.  (You ideally do have a KDC
certificate, though, that the clients know about.)

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

Grant Taylor
On 1/8/19 8:35 PM, Russ Allbery wrote:
> Yes.  A lot of higher education institutions that have used Kerberos
> for many, many years have their KDCs directly on the Internet and allow
> clients to authenticate from anywhere.

Oh.  Good!

> PKINIT is just a replacement preauth mechanism, instead of enc-timestamp.
> Basically, the client uses an X.509 authentication instead of a proof
> of key possession as the preauthentication step to establish a shared
> session secret that is used to encrypt the TGT.  (This may not be 100%
> accurate; it's been a while since I dug into the protocol.)
>
> FAST is a replacement for the whole preauth step.  It uses some
> pre-existing shared session key between the KDC and the client to
> encrypt the whole preauthentication exchange.  Inside of that, you can
> use various preauthentication mechanisms.
>
> Where they usefully combine is in how to get that pre-existing shared
> session key to be able to start using FAST.  This is a chicken-and-egg
> problem with traditional Kerberos: you have to authenticate first in
> order to authenticate.  You can, for instance, use the local host key
> (which is probably randomly generated and therefore safer to use in
> a direct exchange with the KDC) to get a session key to start FAST,
> and then do preauthentication with the (weaker) password-derived key.
>
> Anonymous PKINIT lets you out of that trap by letting the client
> "authenticate" with anonymous Diffie-Hellman to the KDC.  This doesn't
> establish any meaningful identity, but it *does* get you a shared
> session key, and with that you can start FAST, and use it to protect
> any subsequent preauthentication exchange.
>
> Note that you can enable anonymous PKINIT even if you don't otherwise
> use PKINIT and don't have any client certificates.  (You ideally do have
> a KDC certificate, though, that the clients know about.)
Thank you for the concise responses.  I will do more reading on FAST,
PKINIT, Anonymous PKINIT.  But now I have a better idea how the pieces
fit together.

Plus, CA thrown in for good measure.

Isn't security fun and simple?  -  What ever happened to the days of
3Rot13.  ;-)



--
Grant. . . .
unix || die


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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Robbie Harwood
In reply to this post by Russ Allbery-2
Russ Allbery <[hidden email]> writes:

> Robbie Harwood <[hidden email]> writes:
>
>> Also!  2FA will mitigate this concern somewhat as well.  krb5 is
>> prepared to hand off to a RADIUS responder for OTP (freeIPA uses
>> this, which I know you're not interested in but is meaningful as a
>> PoC); you can then use something like freeOTP or a physical 2fa token
>> for acquiring additional credentials.
>
> I wonder how hard it would be to add WebAuthn as a preauth mechanism
> for Kerberos as part of a FAST chain.  HOTP/TOTP don't have the
> greatest security properties, even though most Kerberos use cases are
> inherently less vulnerable to phishing than the typical web
> authentication use.
Probably not too bad, but there are some tricky points around RPs and
the like.  There's work underway (blocked on me actually) to add
U2F/FIDO2 as a 2FA mech under SPAKE, though ideally we'd have the SPAKE
draft closer to release before unloading that on the world.

Thanks,
--Robbie

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

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Robbie Harwood
In reply to this post by Grant Taylor
Grant Taylor <[hidden email]> writes:

> On 1/8/19 6:02 PM, Robbie Harwood wrote:
>
>> It still reduces to the security of a password (the one locking the
>> random key).
>
> I agree that the passwords are the weakest link.  But I thought
> (hoped) that it would bolster the strength of the (derived) key that
> Kerberos uses.

Kerberos uses PBKDF2, so probably not.  The thing it would help with is
reducing the availability the password encrypted blob - it becomes
similar to a certificate.

>> Also!  2FA will mitigate this concern somewhat as well.
>
> I was wondering about 2nd factor authentication.  I have a YubiKey
> that's waiting for my attention.
>
> Would I be correct in assuming that (from a Kerberos point of view)
>the 1st and 2nd factors are used during the kinit process?  Meaning
>that all of the SSO functions still work unimpeded?
>
> I think that it's more that I want to set Kerberos up using best
> practices as I start using it.  I don't want to start something new
> (like build a website) and then find out that I made a bone headed
> mistake (like not salting hashed passwords).
>
> Everything I'm doing, Kerberos included, is functionally for me,
> myself, and I.  I'm still trying to decide which one has the worst
> security posture.


>> You don't have to recreate them, but yes, it's a good idea to set
>> +requires_preauth.  Setting -allow_svr will I believe block the use
>> of U2U and make kvno on user principals no longer work, but this may
>> be acceptable to you
>
> I need to do some more reading on what user-to-user and kvno are to know
> if I care about them.

kvno is a number associated with each principal that keeps track of how
many times it's been rekeyed (password change and the like).  It's
useful for debugging to be able to access this information, but you can
also get it out of kadmin.

> The main thing that I care about that I'm not sure if it's impacted or
> not is .k5login / .k5users.  -  I don't think that would be impacted,
> but I don't know enough to confidently say one way or the other.

I don't believe it would be.

> The little bit of reading that I just did on key version number (kvno)
> sounds unrelated to servers / services (what I think of with allow_svr).
> I need to do more reading.

The kvno(1) tool works by acquiring a service ticket to the given
principal.  So for instance, asking `kvno [hidden email]`
acquires for [hidden email] and then inspects the kvno on
the result.

> On the surface, I think I'd like to keep kvno functional.
>
> Would -allow_svr have any impact on protocol translation?  (I think
> that's the term.)  I.e. when a non-Kerberos aware client logs into IMAPS
> with username & password and the daemon translates / gateways / bridges
> into Kerberos on the client's behalf?  (I saw something about that in
> one of the first three videos I mentioned in a previous message.)

I don't believe so (but I haven't actually checked).

>> Yes.  Provisioning is always the hard part in any cryptosystem :)
>>
>> It's possible to, on the server, kinit and acquire the keytab that
>> way.  But if you're SSHing in already, there isn't really an
>> advantage to that.
>
> Agreed.
>
> I do think that would expose the Kerberos client (the server in this
> context) to KDC exchange to the Internet.  Which it sounds like this is
> reasonably secure enough.
>
> I was not aware that I could get the keytab via kinit.  I had used
> kadmin on clients (in the LAN) to get it.  - This is why I ask
> questions.
It would be with kadmin (or ktutil).  Sorry if that was unclear.

Thanks,
--Robbie

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

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Robbie Harwood
In reply to this post by Grant Taylor
Grant Taylor <[hidden email]> writes:

> On 1/8/19 6:02 PM, Robbie Harwood wrote:
>
>> Also!  2FA will mitigate this concern somewhat as well.
>
> I was wondering about 2nd factor authentication.  I have a YubiKey
> that's waiting for my attention.
>
> Would I be correct in assuming that (from a Kerberos point of view)
> the 1st and 2nd factors are used during the kinit process?  Meaning
> that all of the SSO functions still work unimpeded?
Correct.

As an additional note, second factors (and PKINIT etc.) can set what we
call auth indicators:
http://web.mit.edu/kerberos/krb5-latest/doc/admin/auth_indicator.html

Applications can use these to mandate certain authentication properties
(e.g., used 2fa) on requests.

Thanks,
--Robbie

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

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos n00b question.

Jeffrey Hutzelman
In reply to this post by Robbie Harwood
From: [hidden email] <[hidden email]> on behalf of Robbie Harwood <[hidden email]>

Sent: Thursday, January 10, 2019 2:18 PM
To: Grant Taylor; [hidden email]
Subject: Re: Kerberos n00b question.

Grant Taylor <[hidden email]> writes:

>> You don't have to recreate them, but yes, it's a good idea to set
>> +requires_preauth.  Setting -allow_svr will I believe block the use
>> of U2U and make kvno on user principals no longer work, but this may
>> be acceptable to you
>
> I need to do some more reading on what user-to-user and kvno are to know
> if I care about them.

kvno is a number associated with each principal that keeps track of how
many times it's been rekeyed (password change and the like).  It's
useful for debugging to be able to access this information, but you can
also get it out of kadmin.

In this case, the thing that won't work is the 'kvno' program, which obtains and displays the kvno of a principal by fetching a ticket with that principal as the service, and then looking at the kvno in the resulting ticket. Naturally, that won't work for things which you've flagged not to be usable as services.

U2U, on the other hand, will work just fine. It doesn't require allow_svr on either user, because it works by using the session key from a TGT belonging to the target user, rather than by using that user's long-term key from the kdb.


> The little bit of reading that I just did on key version number (kvno)
> sounds unrelated to servers / services (what I think of with allow_svr).
> I need to do more reading.

The kvno(1) tool works by acquiring a service ticket to the given
principal.  So for instance, asking `kvno [hidden email]`
acquires for [hidden email] and then inspects the kvno on
the result.

Yes, exactly this. Of course, in a small installation where you're also the Kerberos admin, you can just use kadmin to examine a principal and find out its kvno.

> On the surface, I think I'd like to keep kvno functional.
>
> Would -allow_svr have any impact on protocol translation?  (I think
> that's the term.)  I.e. when a non-Kerberos aware client logs into IMAPS
> with username & password and the daemon translates / gateways / bridges
> into Kerberos on the client's behalf?  (I saw something about that in
> one of the first three videos I mentioned in a previous message.)

I don't believe so (but I haven't actually checked).

No, that use case will work just fine. But you should avoid it when you can, since one of Kerberos's main advantages is that you don't ever have to give application servers your password (or anything they could use to impersonate you).

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