Subject: RE: Crossrealm Referal

From: "John Brezak" <[email-masked]>
Date: Thu, 15 Feb 2001 13:21:07 -0800

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: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 17:09:39 -0500

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

--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Feb 2001 11:17:04 -0500

On Fri, Feb 16, 2001 at 11:09:12AM -0500, Derek Atkins wrote:
> Nicolas Williams <[email-masked]> writes:
> 
> I think I see the disconnect here.  There is an implicit assumption
> made that the kerberos client (library) will return a ticket that
> matches the requested principal name.  There is no way to do this
> securely for AS_REQ messages; the only way is to require all
> applications to check the name out-of-band.  It is unsafe (and unwise)
> to require all applications to perform this check on behalf of
> kerberos.

The OOB check is this: use the returned TGT to obtain a service ticket
to a service for which there is a valid key in a local keytab, then
validate that service ticket.

> -derek

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 16 Feb 2001 11:09:12 -0500

>    AS_REP with a valid ticket for the attacker's real account

This doesn't work because kerberos specifically checks that the
principal name in the ticket matches the requested principal name.  In
this particular "attack", the name in the ticket does not match the
requested name, therefore the kerberos client knows that this is
spoofed.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Feb 2001 11:18:15 -0500

> requested name, therefore the kerberos client knows that this is

Right. Let me correct the "it could happen even without Kerberos
principal name canonicalization" bit: it could happen even without a
cross-realm referral.

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 16 Feb 2001 11:23:54 -0500

> validate that service ticket.

Negative.  That test is insufficient.  You are correct that this check
_will_ protect you against the 'fake AP_REP' attack (the second attack
you describe).  However in the attack I and Ken are worried about
(which you did a good job of explaining :) this OOB check will pass,
and _that_ is the problem.  You are now requiring all kerberos
applications to perform yet more checks on the TGT.

-derek

---

From: Derek Atkins <[email-masked]>
Date: 16 Feb 2001 11:48:30 -0500

> principal name canonicalization" bit: it could happen even without a

True, this can happen without a referral, however historically it is
the kerberos library performing this name check, not the application.
The kerberos library checks that requested PN == received PN.  If it
doesn't match, then it returns an error to the application, and if it
succeeds it continues under the assumption that the TGT is valid (the
library doesn't know how to verify it yet).  The application then
needs to check that the TGT is valid (by requesting a host/f.q.d.n
ticket and checking that it can decrypt it), but the library cannot do
this on its own.

With unauthentic AS_REP referrals you are violating the first step, so
the library cannot even be assured that the ticket is the one
requested.

-derek

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Feb 2001 12:14:30 -0500

> applications to perform yet more checks on the TGT.

The "OOB check will pass", yes, BUT, the client knows then the
attacker's real identity. It should use that identity to log in the
attacker, not the identity the attacker wants.

What is wrong with that?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Feb 2001 12:16:48 -0500

> > principal name canonicalization" bit: it could happen even without a

Let me correct even further: it could happen even without a cross-realm
referral if the client requests canonicalization. I.e., the client
support Kerberos PN canon, but the attacker spoofs the AS_REP and does
not substitute a referral, just a valid AS_REP with a valid TGT.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 16 Feb 2001 13:11:57 -0500 (EST)

> not substitute a referral, just a valid AS_REP with a valid TGT.

No, it can't, because a valid TGT contains data encrypted in the TGS's
key, which the attacker does not know.  The attack works only if the
attacker knows the TGS key of some realm with which cross-realm
authentication is possible.

Also, note that trading secrets for cross-realm authentication does not
imply any sort of "trust" in the foreign realm's administrators, any more
than signing someone's PGP key implies that you believe they are an honest
person.  In fact, "some realm with which cross-realm authentication is
possible" doesn't have to inlclude only realms with which an explicit key
exchange has been done -- it could include realms for which PKCROSS can
be used.

-- 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 13:19:59 -0500

> authentication is possible.

The previous iteration of this thread, back in December, made this
clear. The attacker has access to his home realm and the client's realm
trusts that realm.

> exchange has been done -- it could include realms for which PKCROSS can

My point is similar: just because the attacker asked to log in as one id
and faked out the client to authenticate him as his real id doesn't mean
the client must authorize the attacker to access the account he wanted
to.

Derek and Ken argue otherwise.

Nico
--

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 16 Feb 2001 12:45:43 -0800

In any case, it's not the name in the AS reply ticket that counts. It's the
client name, client realm, (and/or possibly authorization information for a
DCE or Win2K implementation) in the service ticket targetted at the
workstation that matters for logon. And how the workstation maps it to a
local account for logon is a local matter, but the mapping should not be
based on the client name alone.

Jonathan