Re: TGT forwarding when cross-realm auth?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Douglas E. Engert
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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Jeffrey Hutzelman
On Monday, June 06, 2005 10:30:55 AM -0500 "Douglas E. Engert"
<[hidden email]> wrote:

> 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.

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.




Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Ken Hornstein
In reply to this post by Douglas E. Engert
>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.

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


Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Douglas E. Engert
In reply to this post by Jeffrey Hutzelman


Jeffrey Hutzelman wrote:

> On Monday, June 06, 2005 10:30:55 AM -0500 "Douglas E. Engert"
> <[hidden email]> wrote:
>
>> 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.
>
>
> 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.

>
>
>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Douglas E. Engert
In reply to this post by Ken Hornstein


Ken Hornstein wrote:

>>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.
>
>
> 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.

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.

>
> --Ken
>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Ken Hornstein
>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.

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


Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Martin Rex
In reply to this post by Douglas E. Engert
I can't seem to find vadim's original Email, so I'm looking at
what Douglas quoted:

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.

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


Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Matt Crawford
In reply to this post by Ken Hornstein
On Jun 6, 2005, at 14:00, Ken Hornstein wrote:
> 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.

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.



Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Matt Crawford
In reply to this post by Martin Rex

On Jun 6, 2005, at 14:02, Martin Rex wrote:
> 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,

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