Subject: Re: TGT forwarding when cross-realm auth?

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 06 Jun 2005 10:30:55 -0500

Thats not the way it works, as others have pointed out. Currently delegation
is an an all or nothing thing. The user's full TGT is delegated with no
restrictions.

This is one of the areas where Kerberos needs improvement as it becomes
more and more popular, some way to limit the damage of a stolen
delegate ticket is needed, as I pointed out in a presentation in the
last ietf-krb-wg that I co-chaired.

vadim wrote:

> Hallo everybody,
> 
> First time in my life I managed to establish trust between two realms,
> realm A and realm B. Trust is one-way, where B trusts A. 
> 
> Now when I do ssh from unix box from realm A to unix box in realm B, my
> TGT from realm A gets forwarded to box in realm B. My principal remains
> me@A.
> 
> This is however not the functionality I am looking for. Instead of
> forwarding krbtgt/A@A, I would like to get krbtgt/B@B in my credential
> cache on unix box in realm B once ssh'ed in it from unix box in realm A.
> And I would my principal to become me@B instead of me@A.
>

You don't have to go as far as to get krbtgt/B@B, but could forward a
krbtgt/B@A while still keeping the user as me@A.

If you are willing you could make some modifications to the
client side that would forward the krbtgt/B@A ticket rather then what
it does now forwarding a krbtgt/A@A.  The krbtgt/B@A is good only for
services in realm B and any other realms that trust A via B.

Even if you had trust setup both ways it would not be allow a
a krbtgt/A@B to be issued using the krtgt/B@A this as it would violate
the cross-realm trust assumptions because the user is still me@A.
Realm A expects the user@A to use the krbtgt/A@A for services in in A.

> Reason one I am looking for such functionality is 
> 
> 1) we (realm A) do not trust realm B and do not want credentials from
> realm A to be saved on that filesystem.
> 
> 2) we however still want users to login from A to B without entering
> passwords.
> 
> Could you please tell me how I could get such functionality?
> 
> thanx a lot and best regards, vadim tarassov.
> 

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Jun 2005 12:48:47 -0400

> Realm A expects the user@A to use the krbtgt/A@A for services in in A.

Note that this protection does not live entirely in realm B.  A proper KDC 
for realm A will not honor a krbtgt/A@B ticket for me@A, even if the realm 
B KDC were to issue one.

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 06 Jun 2005 13:24:52 -0400

>last ietf-krb-wg that I co-chaired.

We've actually done that here a bit (it hasn't been done with protocol
changes, however ... it was done by using existing information in the
ticket and changes to the application servers).  Our work depends on
our requirements, however .... I'm not sure there's a one-size-fits-all
approach.

--Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 06 Jun 2005 13:17:19 -0500

Jeffrey Hutzelman wrote:

> Note that this protection does not live entirely in realm B.  A proper 
> KDC for realm A will not honor a krbtgt/A@B ticket for me@A, even if the 
> realm B KDC were to issue one.

Yes, That is what I thought I said.

--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 06 Jun 2005 13:24:45 -0500

> our requirements, however .... I'm not sure there's a one-size-fits-all

There probably is not a one-size-fits all, but there needs to be some
way to delegate with reduced capabilities. Using full delegation is
a major concern, and will limit the usefulness of Kerberos. It must
also be simple for the user to specify intent or it will not be used properly.

A related problem is the application server when it receives a ticket
does not know must about the delegation that has been done to get the ticket,
other then what realms where involved. There is no way to see
what hosts or sites where involved.

--

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 06 Jun 2005 15:00:36 -0400

>also be simple for the user to specify intent or it will not be used properly.

Note that our solution wasn't really about delegation management; it
was more along the lines of making authorization decisions based on
Kerberos ticket parameters.

I see some practical problems with delegation-limitation:

- Even if it was simple for users to specify their intent, I can't imagine
  most users would specify anything less than "full delegation", for
  the same reason most users would never change their passwords if
  they didn't have to - it's a pain in the ass.

- In the real-world attacks that I've seen against Kerberos, I don't think
  that delegation limiting would have prevented any attacks (it might
  have prevented a very small number, but the problems I've seen have mostly
  been trying to distinguish between real users and attackers).

--Ken

---

From: Martin Rex <[email-masked]>
Date: Mon, 6 Jun 2005 21:02:25 +0200 (MET DST)

I can't seem to find vadim's original Email, so I'm looking at
what Douglas quoted:

> And I would my principal to become me@B instead of me@A.

There seems to be a misunderstanding about what Kerberos interrealm
trust means.

At the protocol level user1@B is always an entirely different principal
as user1@A, and that does *NOT* change when KDC keys are exchanged to
set up interrealm trust.

What could be done on a particular machine is that user1@A and user1@B
are both mapped to the same local account, but that does not affect
in any way the fact that both user1@A and user1@B are totally independent
Kerberos principals.

-Martin

---

From: Matt Crawford <[email-masked]>
Date: Mon, 06 Jun 2005 14:24:47 -0500

>   they didn't have to - it's a pain in the ass.

This is pretty much the reason why the "grid" X.509 delegation never 
developed any fine-grained options.  The general user won't know what 
authorization will be needed and can't be bothered to adopt something 
that (in his view) only makes life harder.

---

From: Matt Crawford <[email-masked]>
Date: Mon, 06 Jun 2005 14:27:02 -0500

On Jun 6, 2005, at 14:02, Martin Rex wrote:
> are both mapped to the same local account,

And if so, it's through someone's deliberate action, not through the 
action of some default rule.