Subject: Re: Crossrealm Referal

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 18:32:19 -0500

In xrealm referrals in AS_REPs there is no encryption involved. The
referring KDC simply sends back an error saying "go to this other realm
and ask for this other principal".

Still, either that works and the client gets a TGT which it can then
validate (*), or it doesn't or it gets an invalid TGT.

A valid TGT completes the chain and the process is secure.

(*) validate as in: use the TGT to get a ticket for a service principal
whose key is available to the client.

Nico

On Thu, Feb 15, 2001 at 02:44:55PM -0800, John Brezak wrote:
> I agree. Since the AS-REP is encrypted with the user's key, the bad KDC
> (either original or referral target), must know the user's secret for
> this attack to work. You can't spoof that - or am I missing something?
> 
> In the AS-REQ NC case, the intermediates can pass the as-req around
> through referrals, but when one KDC responds with the AS-REP, the user
> still must decrypt it to validate the authenticity.
> 
> > -----Original Message-----
> > From: Nicolas Williams [mailto:[email-masked]] 
> > Sent: Thursday, February 15, 2001 2:10 PM
> > To: John Brezak
> > Cc: Ken Raeburn; [email-masked]
> > Subject: Re: Crossrealm Referal
> > 
> > 
> > Well, I'm of the opinion that there is no such bug. Derek 
> > Atkins and Ken Raeburn can fill you in better than I can. But 
> > I'll try anyways. :)
> > 
> > Ken Raeburn and Derek Atkins believe that an attacker with a 
> > valid Kerberos account in one domain, knowing the password 
> > for that account,
> > can:
> > 
> >  - login to a host as another principal in a different realm
> >  - SPOOF the AS_REP from the KDC of the other realm, substituting a
> >    cross-realm referral to the attackers actual acount
> > 
> >    (trust relationships between the two realms are assumed)
> > 
> >  - the host will authenticate the attacker as his real id
> >  - the host will authorize the attacker as the other principal
> > 
> > I submit that the last item would be the result of an 
> > implementation bug ONLY, and NOT the result of a bug in the 
> > AS_REP cross-realm referral.
> > 
> > In fact, if this could happen, it could happen even without 
> > Kerberos principal name canonicalization!!!!!!!!!!
> > 
> > Like so:
> > 
> >  - login to a host as another principal in the same realm as the
> >    attacker's account
> >  - SPOOF the AS_REP from the KDC of the other realm, substituting an
> >    AS_REP with a valid ticket for the attacker's real account
> > 
> >  - the host will authenticate the attacker as his real id
> >  - the host will authorize the attacker as the other principal
> > 
> > Clearly this does not happen.
> > 
> > But this isn't accepted.
> > 
> > Nico
> > 
> > 
> > On Thu, Feb 15, 2001 at 01:21:07PM -0800, John Brezak wrote:
> > > I can't seem to find the description of a security bug in xrealm 
> > > AS-REP referrals - can someone summarize this in this thread?
> > > 
> > > -----Original Message-----
> > > From: Nicolas Williams [mailto:[email-masked]]
> > > Sent: Thursday, February 15, 2001 9:15 AM
> > > To: Ken Raeburn; [email-masked]
> > > Subject: Re: Crossrealm Referal
> > > 
> > > 
> > > BTW, we can certainly test your theory of a security bug in xrealm 
> > > AS_REP referrals.
> > > 
> > > Implementations which do not support PN canon should not be 
> > vulnerable 
> > > (they should drop spoofed AS_REPs that are xrealm referrals).
> > > 
> > > Implementations which do support PN canon should not be vulnerable 
> > > (they should log in the user as the canonical user, not as 
> > the spoofed 
> > > alias with no further priviledges and access than the 
> > canonical user 
> > > would have had if he/she had logged in as him/herself to 
> > begin with).
> > > 
> > > Nico
> > > 
> > > 
> > > On Thu, Feb 15, 2001 at 09:13:33AM -0500, Nicolas Williams wrote:
> > > > Fine. When is the next IETF meeting?
> > > > 
> > > > Nico
> > > > 
> > > > On Thu, Feb 15, 2001 at 08:24:35AM -0500, Ken Raeburn wrote:
> > > > > Sam Hartman <[email-masked]> writes:
> > > > > > I disagree with Nicolas's characterization of the AS
> > > > > > canonicalization discussion.  I do not believe that 
> > consensus was 
> > > > > > reached, or if consensus was reached, he was not part of that 
> > > > > > consensus.  From my vantage, it looked like both sides were 
> > > > > > starting to repeat the same arguments over and over 
> > again, and 
> > > > > > that several participants realized that no progress 
> > was being made
> > > 
> > > > > > and stopped.  Silence is not always consensus.  I think the AS
> > > > > > issues will only be resolved by an in-person meeting 
> > or if that is
> > > 
> > > > > > impossible a conference call.  I believe that email has been
> > > > > > ineffective so far at reaching agreement and we must 
> > either agree 
> > > > > > to disagree or try other channels.
> > > > > 
> > > > > I think you're right -- and if Martin and John are 
> > going to be at
> > > > > the next IETF, that may give us a good opportunity.
> > > > > 
> > > > > Ken
> > > > --
> > > --
> > --
> > 
--

---

From: "John Brezak" <[email-masked]>
Date: Thu, 15 Feb 2001 14:44:55 -0800

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 15 Feb 2001 19:35:29 -0500 (EST)

> this attack to work. You can't spoof that - or am I missing something?

You are.  In this scenario, the user at the keyboard is cooperating with a
rogue KDC to gain access to a machine.  The login software on the machine
is the "good guy", and the user and rogue KDC are both "bad guys".

Under this scenario, the rogue KDC can return a "valid" ticket for the
user, since it knows the attacker's secret.  But that ticket cannot be
validated, because the rogue KDC does _not_ know the hosts's secret.  With
referrals, it gets more complicated, because the referral itself is not
authenticated.  So an attacker can type in a local user name, transmit a
fake AS_REP which refers the host to a KDC in a realm which he controls
(and which shares keys with the host's realm), and return a valid ticket
for a user in that realm.

Making this attack not work requires either that we assume a level of
"trust" associated with the exchange of cross-realm keys, or that the
referral be authenticated, or that the host be careful to verify that the
validated ticket it got back is for a principal authorized to log in as
the local account to which access will be granted.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Feb 2001 10:35:25 -0500

But the attack cannot work.

The attacker, Stinky@FRIEND-REALM tries to log in to client fool.fqdn as
Binky@LOCAL-REALM. The client has a keytab with a valid key for
host/fool.fqdn@LOCAL-REALM. The attacker spoofs the AS_REP from
LOCAL-REALM and subtitutes a referral to Stinky@FRIEND-REALM.

Here's the possibilities:

 - client did not request canonicalization, client drops spoofed
   response.

   Result: ATTACK FAILED.

 - client gets TGT for Stinky@FRIEND-REALM in other realm but cannot
   validate the ticket against host/fool.fqdn@LOCAL-REALM due to a lack
   of trust relationship between the realms.

   Result: user not authenticated. ATTACK FAILED.

 - client gets TGT for Stinky@FRIEND-REALM, client uses said TGT to get
   a service ticket (*) for host/fool.fqdn@LOCAL-REALM and validates
   said service ticket.

   Result: client authenticates attacker with the attacker's identity
   in the TGT, Stinky@FRIEND-REALM; client should authorize the
   attacker based on his real identity, not Binky@LOCAL-REALM.

   ATTACK FAILED.

(*) This involves obtaining cross-realm tickets, so LOCAL-REALM must
trust FRIEND-REALM or this won't work, meaning the attack won't work.

I'm assuming the attacker knows his own password, of course. If he
doesn't then any TGTs obtained by the client won't decrypt.

****

The attack that Ken and Derek claim is possible has nothing to do with
cryptography or with the protocol, but with the client being stupid and
authorizing Stinky@FRIEND-REALM to access Binky@LOCAL-REALM.

Clearly that would be a bug in the client, not the protocol!

Nico

--