Subject: risks of reused passwords in Kerberos

From: Ken Raeburn <[email-masked]>
Date: Sun, 8 Apr 2007 18:55:23 -0400

This started as a contemplation of potential security issues related  
to the kerberos-referrals draft.  I was mainly considering what an  
attacker might do to an innocent user by triggering canonicalization  
or referral processing.  Of course, in that case, the user is still  
going to type the same password, so two accounts had to be available  
with keys generated from the same password.  Not the smartest  
approach for the user, but it would be unrealistic of us to think  
that it doesn't happen.  Then I got to thinking about other potential  
risks in such cases...

So far I've come up with three cases to focus on.

My conclusions aren't particularly surprising, given the other work  
that's been happening in the working group:
  * protect the AS exchange with something besides the user's password
  * add PFS
  * if you can't protect the AS exchange, be suspicious of responses

----------------

(Background info: The "Zanarotti attack" refers to a situation in  
which the attacker has access to a login prompt on the client machine  
as well as the network, and is attempting to gain access to the  
machine.  With no additional means of protection employed, a forged  
AS-REP message generated by the attacker can be successfully  
decrypted using a password typed on the client machine by the  
attacker.  Thus, decrypting the AS-REP message, by itself, is not  
proof of identity. If the client system has a host key, the login  
program can attempt to authenticate the user to the host itself by  
requesting a ticked for the host service from the TGS, if the initial  
ticket was a TGT.  But if the client host has no shared secret with  
the KDC, then RFC 4120 provides no way for it to verify the user's  
identity.)

Assume a user has accounts in two realms, and (carelessly, perhaps,  
but realistically) uses the same password in both.  Also assume that  
the user has not changed his password while either realm has been  
compromised by the attacker.  (For the sake of argument, I would  
include a properly authorized administrator of a realm "turning to  
the dark side" as a compromise of that realm.)

Assume the user is attempting to authenticate to a service using his  
realm1 identity, and tricking the user into accessing the service  
with credentials other than those the user intended to use is a  
security vulnerability.  The service may be in realm1 or some other  
non-compromised realm.

First attack scenario:

A man-in-the-middle attacker intercepts the request and fires off a  
request to a KDC for realm2.  The response is sent to the user,  
possibly modified by the attacker to add a salt string specification  
so that the user's software will generate the key for user@realm2.

The response from the attacker to the user does not include a copy of  
the client principal name or realm encrypted in the user's key, so  
after decryption, the user does not know that the credentials are for  
the wrong principal.  However, in an AP-REQ message (including one  
incoporated in the PA-TGS-REQ part of a TGS exchange), the included  
ticket will list the realm2 identity for the user, and the  
authenticator constructed by the client software will include the  
realm1 identity the client thinks it is using, and the combination  
will be rejected by the server.

In the normal "login" case, where it is recommended that acquired  
credentials be verified by authenticating to a local service on the  
client host (to prevent the Zanarotti attack), this attack could be  
detected quickly, even if the KDC is spoofed in the TGS exchange too,  
because the attacker will not know the key stored on the host.  
However, Kerberos also supports acquiring a service ticket instead of  
a TGT in the AS exchange (and in some implementations some sensitive  
services may require it), so verification by the client software may  
not be possible until the AP-REQ message is sent and rejected.

However, with the extensions outlined in the referrals draft, the  
client's idea of its own identity will be provided by the KDCs (or in  
this case, possibly by the attacker).

In the client name canonicalization case -- where I think we'd need  
to assume the two accounts with the same password are actually in the  
same realm -- the PA-CLIENT-CANONICALIZED information will be  
returned with the response from the KDC.  This field includes the  
requested name the KDC saw from the client, and the new name, both  
protected by a checksum.  The client thus can confirm that the  
request to the KDC wasn't tampered with (at least in terms of  
changing the client name), if we can assume that the keys themselves  
haven't been compromised.

In the client referral case, all the client receives is an  
unprotected KRB-ERROR message pointing it to the new realm name.  No  
new client name can be provided by the KDC, but if a spoofed reply  
(or a legitimate reply to a spoofed query) points the user to realm2,  
and the client name used is accepted by the realm2 KDC as well as the  
realm1 KDC, a proper AS-REP will be issued using the user's realm2  
key (which may require the attacker to insert a salt string in the  
reply message).  I'm going to look more closely at that in future  
email, directed more at work on the referrals draft.

If some additional means is used to protect the KRB-ERROR response,  
the response can be trusted -- at least, if one trusts the KDC  
providing the response, but that's a different analysis.

Second attack scenario:

The attacker mounts a man-in-the-middle attack as above, but has also  
compromised a KDC in realm2, and thus can construct a ticket that  
claims the user is in realm1, encrypted in the user's key in realm2.  
Since the service keys for realm1 are not available to the attacker,  
however, services in realm1 cannot be convinced to accept these  
credentials.  (Genuine services in realm2, or any realm to which the  
client in realm1 would normally authenticate indirectly through  
realm2, can be spoofed, though the attacker already has that  
capability with the long-term keys from the database.)

If the attacker can spoof all the application traffic, however, with  
the keys available, the attacker can spoof any service that isn't  
verified through some external means (certificates, non-Kerberos  
shared secrets).

The local verification described above for the "login" case can  
defend against this attack when acquiring a TGT, if the local host's  
key is in realm1, or in a third realm for which the correct transited  
realm path from a realm1 user would not go through realm2 (and the  
verification code or the local KDC properly implements checks of the  
transited path).  But again, a TGT isn't always being acquired.

I think this strongly argues for using a KDC's public key or the  
client system's host key to protect the AS exchange whenever possible.

Third attack scenario:

The attacker has recorded traffic to the password-changing service,  
and later compromises the KDC.  While the KDC may not be storing the  
passwords that produced the stored keys, due to the lack of PFS in  
the password-changing protocol, the attacker can later extract any  
passwords that were sent encrypted, and from those potentially  
compromise the users' accounts in other realms where the same or  
similar passwords were used.  Many other protocols based on Kerberos  
will also fail to provide PFS, but most aren't specifically for  
carrying passwords.

One could argue that the AP exchange is where PFS should be added,  
and I'd tend to agree; I'm just pointing out the password-changing  
service as a particularly sensitive vulnerability point in a Kerberos  
infrastructure.