pre-authentication attacks

[Ben H]

I was reading up a bit on the history of pre-authentication after hearing a
speaker I generally put all faith into mention something about pre-auth
which I didn't think was accurate (namely that's its use was to help
determine available encryption types...something which I can find no
evidence of).

In any event, my understanding is that pre-auth is used to prevent an
entity from requesting a TGT without credentials and therefore not being
able to brute force the encryption.

However, there are tools out there which are able to also perform
brute-force attacks against the pre-auth timestamp. In order to do this
however, it would require the ability to listen on the wire between a
client and a KDC. Something that may be trivial in certain circumstances
(compromising a single application box could provide a sniff of all users
authenticating to the KDC).

That being said, assuming that all traffic to the KDC is encrypted,
pre-authentication would seem to be superior as I can't request a ticket
without credentials from an insecure location. If however, we assume that
all traffic between a client and a KDC may be compromised, is
pre-authentication superior?

We don't even need to make repeated attempts for a pre-auth required, we
simply need to listen on the wire for when user's authenticate.
Isn't a known entity like a UTC timestamp eaiser to brute force against
than the encrypted TGT?

[Tom Yu]

Post by Ben H
I was reading up a bit on the history of pre-authentication after hearing a
speaker I generally put all faith into mention something about pre-auth
which I didn't think was accurate (namely that's its use was to help
determine available encryption types...something which I can find no
evidence of).

The ETYPE-INFO and ETYPE-INFO2 "preauth" types are hints from the KDC to
the client as to what enctypes to use for further preauth or for
decrypting the AS-REP. They happen to take advantage of the protocol
"hole" provided by the preauth elements in the protocol, but they do not
exemplify the intended use of preauth.

Post by Ben H
In any event, my understanding is that pre-auth is used to prevent an
entity from requesting a TGT without credentials and therefore not being
able to brute force the encryption.

I think the intention was to prevent just anyone on the entire Internet
from requesting ciphertext use for a dictionary attack unless they could
first demonstrate knowledge of the key.

Post by Ben H
However, there are tools out there which are able to also perform
brute-force attacks against the pre-auth timestamp. In order to do this
however, it would require the ability to listen on the wire between a
client and a KDC. Something that may be trivial in certain circumstances
(compromising a single application box could provide a sniff of all users
authenticating to the KDC).
That being said, assuming that all traffic to the KDC is encrypted,
pre-authentication would seem to be superior as I can't request a ticket
without credentials from an insecure location. If however, we assume that
all traffic between a client and a KDC may be compromised, is
pre-authentication superior?

I believe you're thinking primarily of encrypted-timestamp preauth. It
adds some protection from attackers who are not network-omniscient, but
not very much when an attacker can capture all traffic entering and
leaving the KDC. There are stronger preauth protections than
encrypted-timestamp, e.g., FAST (RFC 6113), that can replace or
strengthen the use of password-derived keys, and we are considering
adding more.

Post by Ben H
We don't even need to make repeated attempts for a pre-auth required, we
simply need to listen on the wire for when user's authenticate.
Isn't a known entity like a UTC timestamp eaiser to brute force against
than the encrypted TGT?

The encryption schemes used for encrypted-timestamp (and in much of
Kerberos) are authenticated encryption, so it is easy to verify that the
correct key was guessed.

[Greg Hudson]

Post by Ben H
That being said, assuming that all traffic to the KDC is encrypted,
pre-authentication would seem to be superior as I can't request a ticket
without credentials from an insecure location. If however, we assume that
all traffic between a client and a KDC may be compromised, is
pre-authentication superior?
We don't even need to make repeated attempts for a pre-auth required, we
simply need to listen on the wire for when user's authenticate.
Isn't a known entity like a UTC timestamp eaiser to brute force against
than the encrypted TGT?

A Kerberos EncryptedData message contains an integrity tag in the RFC
3961 cipherext, so one can brute-force an EncKDCRepPart just about as
easily as a PA-ENC-TIMESTAMP. The encrypted timestamp is a little
shorter, but that shouldn't change the constant factor much since the
attacker also has to do string-to-key for each candidate password.

Here's a summary of Kerberos offline password attack properties:

* Without preauth_required (or without disallow_svr), an attacker can
simply request a ciphertext encrypted in the long-term key and conduct a
brute-force attack against the EncKDCRepPart.

* With preauth_required and disallow_svr, an attacker must be able to
observe traffic from a legitimate client to be able to conduct a
brute-force attack. The attacker also doesn't get to choose the enctype
of the long-term key used, unless the attacker can also modify the
etype-info2 padata in the preauth_required reply as seen by the client.

* The AES enctypes have an intentionally expensive string-to-key
function, making brute-force password attacks more expensive by a
significant but constant factor.

* The RC4 enctype doesn't use the salt, making brute-force password
attacks easier since a string-to-key table can be constructed which
applies to all principals.

* FAST prevents brute-force password attacks as long as the attacker
does not know the armor ticket key. It is not as easy to deploy FAST as
we would like.

* PKINIT prevents brute-force password attacks by not using a
password-derived long-term key.

* Microsoft has a Kerberos-over-HTTPS standard called MS-KKDCP which we
will be implementing in MIT krb5 1.13. This will allow Kerberos traffic
to be encrypted, with the KDC authenticated by a standard web server TLS
certificate, at the expense of a lower load ceiling on the proxy server.

[Russ Allbery]

Post by Greg Hudson
* The AES enctypes have an intentionally expensive string-to-key
function, making brute-force password attacks more expensive by a
significant but constant factor.

The one caveat I'll add to this, though, is that "intentionally expensive"
changes over time. Current crypto best practices would use about 3x as
many rounds as the AES enctype specifies as the default, and would use
per-principal salt.

The Kerberos protocol permits the server to tell the client both the salt
and the rounds, so you could dynamically adjust the rounds and use
per-principal salt within the protocol (or, even better, randomize the
salt on every password change). However, I don't know if anyone
implements the tools required to manage this properly, or if typical
clients would cope.

Post by Greg Hudson
* The RC4 enctype doesn't use the salt, making brute-force password
attacks easier since a string-to-key table can be constructed which
applies to all principals.

Also, the hash function is relatively trivial, so even without a rainbow
table a brute force attack is much easier.

Post by Greg Hudson
* FAST prevents brute-force password attacks as long as the attacker
does not know the armor ticket key.

...but of course the attacker can still attempt to brute-force the armor
ticket key, which is why it's important for that key to be completely
random to force the attacker to search the full key space, or to negotiate
it using something like PKINIT.

[Ben H]

Thanks for the information, I will have to delve into some of it in more
detail (I don't yet have a good grasp on FAST) or necessarily understand
cryptography to the extent i fully grasp the expensive string-to-key
functions.

It seems however, that for the most part my assumption that in a closed
network (enterprise network, not across the Internet), assuming a potential
attacker has access to the traffic flowing to KDC, pre-authentication has
minimal advantages. Brute-forcing the encrypted-timestamp may be only
marginally quicker than the integrity tag in the ciphertext (If I read Greg
correctly, I need to research this tag) . But the preauthentication gives
the added protection of allowing the server to choose/enforce the
encryption type used.

That being said, if say AES were the only allowable encryption type used on
such a network, the advantages here would be significantly less substantial
and if we assumed easy access to the network, and standard encrypted-timestamp
preauth, then the advantages of this pre-auth are negligible at best to no
pre-auth at all?

I ask this mostly as a high-level theory question now, understanding (also
at a high level) the other concepts and solutions discussed above. I hope
to dig deep enough to fully understand these other implications, but want
to ensure I understand the original implementations first.

Post by Russ Allbery

Post by Greg Hudson
* The AES enctypes have an intentionally expensive string-to-key
function, making brute-force password attacks more expensive by a
significant but constant factor.

The one caveat I'll add to this, though, is that "intentionally expensive"
changes over time. Current crypto best practices would use about 3x as
many rounds as the AES enctype specifies as the default, and would use
per-principal salt.
The Kerberos protocol permits the server to tell the client both the salt
and the rounds, so you could dynamically adjust the rounds and use
per-principal salt within the protocol (or, even better, randomize the
salt on every password change). However, I don't know if anyone
implements the tools required to manage this properly, or if typical
clients would cope.

Post by Greg Hudson
* The RC4 enctype doesn't use the salt, making brute-force password
attacks easier since a string-to-key table can be constructed which
applies to all principals.

Also, the hash function is relatively trivial, so even without a rainbow
table a brute force attack is much easier.

Post by Greg Hudson
* FAST prevents brute-force password attacks as long as the attacker
does not know the armor ticket key.

...but of course the attacker can still attempt to brute-force the armor
ticket key, which is why it's important for that key to be completely
random to force the attacker to search the full key space, or to negotiate
it using something like PKINIT.
--
Russ Allbery (eagle at eyrie.org) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

[Russ Allbery]

But the preauthentication gives the added protection of allowing the
server to choose/enforce the encryption type used.

I don't believe this is the case. Whether or not pre-authentication is
enabled, the server always has the ability to choose or enforce the
encryption type used.

The difference in the pre-authentication case is that the *attacker*
cannot choose a weak enctype that the server is willing to accept by
claiming that the attacker is a client that only supports weak enctypes.
Instead, the attacker has to work from network capture information from a
real client, and real clients will always attempt to negotiate the
strongest encryption type they support.

That being said, if say AES were the only allowable encryption type used
on such a network, the advantages here would be significantly less
substantial and if we assumed easy access to the network, and standard
encrypted-timestamp preauth, then the advantages of this pre-auth are
negligible at best to no pre-auth at all?

Pre-authentication essentially requires the attacker to be capable of
being a passive man-in-the-middle in order to launch an off-line
brute-force attack. If there is no security risk benefit in shifting the
attacker profile from "anyone who can connect to the KDC" to "passive
man-in-the-middle," then yes, encrypted timestamp pre-authentication isn't
really doing anything for you.

That being said, I am rather dubious that you can construct a reasonable
scenario where that change has no benefit. A typical enterprise closed
network use case is *not* such a scenario. With encrypted timestamp, the
attacker can still only attack clients for which it has network capture
data, which means that unused accounts are not vulnerable to off-line
brute-force, and any limitation on the attacker's ability to see all
network traffic (and, in practice, there will be many limitations for most
likely attacker scenarios) will give you more security by reducing the
principal space the attacker can launch off-line attacks against.

[Ben H]

Russ,

I understand and agree with your first statements regarding the enctype. I
was proposing a scenario where the environment was restricted to only AES
types, so a client which only supported DES would not be allowed in any
event.
Assuming the server preferred AES, but accepted DES if requested, then
clearly the pre-auth has the advantage. Of course, even in a pre-auth
scenario, couldn't I have a rogue client or modify the kerberos
configuration (or run a second configuration) on a client that I have
configured to support only a weak enctype?

Regarding your second statements - I'm not sure I fully grasp your
meanings. I am certainly not doubting that there are advantages to the
pre-auth. The point you make about unused accounts is a good one.
If an enterprise is secured enough to prevent the passive man-in-the-middle
attacks then the advantage is clear. My argument is mostly taking the vein
that if this were compromised (switch password discovered, network tap, no
ip-sec, compromise of a system on isolated network, etc.) that any
principal's logon traffic which passed to the KDC is a possible target for
a pre-auth attack. Of course I might not simply be able to request a TGT
for admin at domain.com, but there is a good chance some administrator
credentials will flow on a daily basis to the KDC, no?

So while I may be trivializing these other protections, my experience tells
me that often there are enough overlooked aspects of a network's security
that gaining the advantage here is not as difficult as it might seem.
In the best of all possible worlds, enc timestamp pre-auth has a clear
advantage - but in practice I am trying to determine what that advantage
truly is.

I believe we are probably on the same page here, but if you feel I am still
missing your point (and you care to make it again), please elaborate.

Post by Russ Allbery

But the preauthentication gives the added protection of allowing the
server to choose/enforce the encryption type used.

I don't believe this is the case. Whether or not pre-authentication is
enabled, the server always has the ability to choose or enforce the
encryption type used.
The difference in the pre-authentication case is that the *attacker*
cannot choose a weak enctype that the server is willing to accept by
claiming that the attacker is a client that only supports weak enctypes.
Instead, the attacker has to work from network capture information from a
real client, and real clients will always attempt to negotiate the
strongest encryption type they support.

That being said, if say AES were the only allowable encryption type used
on such a network, the advantages here would be significantly less
substantial and if we assumed easy access to the network, and standard
encrypted-timestamp preauth, then the advantages of this pre-auth are
negligible at best to no pre-auth at all?

Pre-authentication essentially requires the attacker to be capable of
being a passive man-in-the-middle in order to launch an off-line
brute-force attack. If there is no security risk benefit in shifting the
attacker profile from "anyone who can connect to the KDC" to "passive
man-in-the-middle," then yes, encrypted timestamp pre-authentication isn't
really doing anything for you.
That being said, I am rather dubious that you can construct a reasonable
scenario where that change has no benefit. A typical enterprise closed
network use case is *not* such a scenario. With encrypted timestamp, the
attacker can still only attack clients for which it has network capture
data, which means that unused accounts are not vulnerable to off-line
brute-force, and any limitation on the attacker's ability to see all
network traffic (and, in practice, there will be many limitations for most
likely attacker scenarios) will give you more security by reducing the
principal space the attacker can launch off-line attacks against.
--
Russ Allbery (eagle at eyrie.org) <http://www.eyrie.org/~eagle/>

[Russ Allbery]

Post by Ben H
I understand and agree with your first statements regarding the enctype.
I was proposing a scenario where the environment was restricted to only
AES types, so a client which only supported DES would not be allowed in
any event.

Ah, yes, in that model, the distinction between whether the attacker can
request a particular enctype or can only use those from real clients
doesn't really matter.

Post by Ben H
Assuming the server preferred AES, but accepted DES if requested, then
clearly the pre-auth has the advantage. Of course, even in a pre-auth
scenario, couldn't I have a rogue client or modify the kerberos
configuration (or run a second configuration) on a client that I have
configured to support only a weak enctype?

Sure, but once you can compromise the Kerberos client, there's no point in
doing any sort of brute-force attack. Just install a keystroke logger and
steal the password directly.

Post by Ben H
My argument is mostly taking the vein that if this were compromised
(switch password discovered, network tap, no ip-sec, compromise of a
system on isolated network, etc.) that any principal's logon traffic
which passed to the KDC is a possible target for a pre-auth attack.

This is true, but to get *all* the traffic you have to assume a network
tap on the KDC network. Now, that may be a concern, but in most
enterprise situations a network tap near a client is far more likely than
a network tap near the KDC. The latter requires compromising the core of
the data center network, whereas the latter is almost trivial if you have
any clients using wireless hotspots or the like.

Post by Ben H
Of course I might not simply be able to request a TGT for
admin at domain.com, but there is a good chance some administrator
credentials will flow on a daily basis to the KDC, no?

At Stanford, lots and lots of Kerberos traffic comes from all over the
place, but administrative credentials come from far fewer places. So
there are a lot of points of network traffic recording vulnerability for
any principal, but much fewer for admin credentials. It's possible to do
a much better job than we do and always use VPN for admin actions, which
can reduce that window even further.

Of course, in the long run, we would want to always use FAST for admin
credentials, at which point it mostly doesn't matter.

Post by Ben H
So while I may be trivializing these other protections, my experience
tells me that often there are enough overlooked aspects of a network's
security that gaining the advantage here is not as difficult as it might
seem. In the best of all possible worlds, enc timestamp pre-auth has a
clear advantage - but in practice I am trying to determine what that
advantage truly is.

I think you're right and we're largely on the same page. Passive
man-in-the-middle is not a particularly onerous requirement, and security
measures that are vulnerable to passive man-in-the-middle are not
considered particularly strong. I don't think that encrypted timestamp
pre-auth carries whole lot of security weight.

That said, you also get it for free with any Kerberos implementation, so
some of my response is just there to say that you should always turn on
pre-auth, since there's basically no reason not to and it does help some.
(And yet some sites don't.)

But what you really want is FAST, PKINIT, or (even better than either for
a lot of use cases) some sort of hypothetical PAKE pre-auth mechanism.

[Ben H]

Great - thanks - I agree with pretty much all of that. My questions was
again more of a theoretical "what does it really provide?" and are those
benefits worth any possible risk.
I think that Greg's answer that enc time pre-auth is only slightly more
negligible to brute force than without it and the advantages we discussed
(although not always in place) helps me buy into pre-auth as a good thing
overall as it does reduce the overall footprint.

I still need to research FAST which will be on my list after I finish
review of the original RFCs again.

Post by Russ Allbery

Post by Ben H
I understand and agree with your first statements regarding the enctype.
I was proposing a scenario where the environment was restricted to only
AES types, so a client which only supported DES would not be allowed in
any event.

Ah, yes, in that model, the distinction between whether the attacker can
request a particular enctype or can only use those from real clients
doesn't really matter.

Post by Ben H
Assuming the server preferred AES, but accepted DES if requested, then
clearly the pre-auth has the advantage. Of course, even in a pre-auth
scenario, couldn't I have a rogue client or modify the kerberos
configuration (or run a second configuration) on a client that I have
configured to support only a weak enctype?

Sure, but once you can compromise the Kerberos client, there's no point in
doing any sort of brute-force attack. Just install a keystroke logger and
steal the password directly.

Post by Ben H
My argument is mostly taking the vein that if this were compromised
(switch password discovered, network tap, no ip-sec, compromise of a
system on isolated network, etc.) that any principal's logon traffic
which passed to the KDC is a possible target for a pre-auth attack.

This is true, but to get *all* the traffic you have to assume a network
tap on the KDC network. Now, that may be a concern, but in most
enterprise situations a network tap near a client is far more likely than
a network tap near the KDC. The latter requires compromising the core of
the data center network, whereas the latter is almost trivial if you have
any clients using wireless hotspots or the like.

Post by Ben H
Of course I might not simply be able to request a TGT for
admin at domain.com, but there is a good chance some administrator
credentials will flow on a daily basis to the KDC, no?

At Stanford, lots and lots of Kerberos traffic comes from all over the
place, but administrative credentials come from far fewer places. So
there are a lot of points of network traffic recording vulnerability for
any principal, but much fewer for admin credentials. It's possible to do
a much better job than we do and always use VPN for admin actions, which
can reduce that window even further.
Of course, in the long run, we would want to always use FAST for admin
credentials, at which point it mostly doesn't matter.

Post by Ben H
So while I may be trivializing these other protections, my experience
tells me that often there are enough overlooked aspects of a network's
security that gaining the advantage here is not as difficult as it might
seem. In the best of all possible worlds, enc timestamp pre-auth has a
clear advantage - but in practice I am trying to determine what that
advantage truly is.

I think you're right and we're largely on the same page. Passive
man-in-the-middle is not a particularly onerous requirement, and security
measures that are vulnerable to passive man-in-the-middle are not
considered particularly strong. I don't think that encrypted timestamp
pre-auth carries whole lot of security weight.
That said, you also get it for free with any Kerberos implementation, so
some of my response is just there to say that you should always turn on
pre-auth, since there's basically no reason not to and it does help some.
(And yet some sites don't.)
But what you really want is FAST, PKINIT, or (even better than either for
a lot of use cases) some sort of hypothetical PAKE pre-auth mechanism.
--
Russ Allbery (eagle at eyrie.org) <http://www.eyrie.org/~eagle/>

[Simo Sorce]

Post by Russ Allbery

Post by Greg Hudson
* The AES enctypes have an intentionally expensive string-to-key
function, making brute-force password attacks more expensive by a
significant but constant factor.

The one caveat I'll add to this, though, is that "intentionally expensive"
changes over time. Current crypto best practices would use about 3x as
many rounds as the AES enctype specifies as the default, and would use
per-principal salt.
The Kerberos protocol permits the server to tell the client both the salt
and the rounds, so you could dynamically adjust the rounds and use
per-principal salt within the protocol (or, even better, randomize the
salt on every password change). However, I don't know if anyone
implements the tools required to manage this properly, or if typical
clients would cope.

The FreeIPA project uses random salts since when we started, it seem all
clients we know of cope just fine.
We do not change rounds, so I can't speak about changing that.

Simo.

[Greg Hudson]

Post by Simo Sorce

Post by Russ Allbery
The Kerberos protocol permits the server to tell the client both the salt
and the rounds, so you could dynamically adjust the rounds and use
per-principal salt within the protocol (or, even better, randomize the
salt on every password change). However, I don't know if anyone
implements the tools required to manage this properly, or if typical
clients would cope.

The FreeIPA project uses random salts since when we started, it seem all
clients we know of cope just fine.

We have explored using random salts by default in MIT krb5 in the past.
http://k5wiki.kerberos.org/wiki/Projects/Random_Salt_Generation#Complications
describes the reasons why we didn't go ahead with it at that time. They
aren't insurmountable, but they require additional resource investment.
FreeIPA presumably works around all of these issues except for the
ktutil ktadd issue, which it can reasonably ignore.

In 1.10 (issue #6964) we added support for the "special" salt type as an
input salt type for kadmin cpw, supported_enctypes, etc.. (The
"special" type already existed but didn't work as an input.) Currently
it generates a 16-byte ASCII salt containing 64 bits of entropy; there
isn't currently any way to adjust that.

Post by Simo Sorce
We do not change rounds, so I can't speak about changing that.

As far as I know, no KDC implementation has any support for changing the
number of PBKDF2 rounds, although clients generally have code to handle
it. Note that in the absence of FAST or KKDCP or similar, an active
attacker could defeat this measure by altering the string-to-key
parameters in the preauth-required error as seen by the client. (We do
not currently accept s2k parameters which reduce the number of rounds
from the default.)

An active attacker could also induce the client to use an enctype with a
faster or weaker string-to-key function. Clients can defend against
this by removing all enctypes older than AES from default_tkt_enctypes,
e.g.:

[libdefaults]
default_tkt_enctypes = DEFAULT -des -des3 -rc4

but of course it would create interop issues if we simply changed our
hardcoded defaults.