How exactly does cross-realm auth work with KDCs?

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

How exactly does cross-realm auth work with KDCs?

Victor Sudakov
Dear Colleagues,

Could you please clarify the following for me.

I have set up two realms, FIRST.EXAMPLE and SECOND.EXAMPLE, to trust
each other. Then

1. I run kinit on host1.first.example and obtain a
krbtgt/[hidden email] for the principal [hidden email]

2. I ssh from host1.first.example to host1.second.example, and my
credentials are forwarded there. The forwarded krbtgt at
host1.second.example still belongs to the principal [hidden email]

3. When I want to ssh further to host2.second.example, which KDC is my
ssh client supposed to contact for the host/host2.second.example
ticket: the one in FIRST.EXAMPLE or SECOND.EXAMPLE?

Looks like it's trying to contact the KDC in FIRST.EXAMPLE, but there
is no route to this KDC from host1.second.example, and everything
breaks.

Is it expected behaviour?

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How exactly does cross-realm auth work with KDCs?

Greg Hudson
On 03/13/2016 01:10 PM, Victor Sudakov wrote:
> 3. When I want to ssh further to host2.second.example, which KDC is my
> ssh client supposed to contact for the host/host2.second.example
> ticket: the one in FIRST.EXAMPLE or SECOND.EXAMPLE?

Your client contacts the FIRST.EXAMPLE KDC to get a
krbtgt/[hidden email] ticket, then contacts a
SECOND.EXAMPLE KDC and presents the cross-realm TGT to get a ticket for
host/[hidden email].  (The client principal remains
[hidden email] for all of these tickets.)

(The exact sequence of requests depends on whether your client knows
that host2.second.example belongs in the SECOND.EXAMPLE realm.  If it
doesn't know that, then the client will ask the FIRST.EXAMPLE KDC for a
ticket for host/[hidden email] and get back a
"referral" in the form of a ticket for krbtgt/[hidden email].)

> Looks like it's trying to contact the KDC in FIRST.EXAMPLE, but there
> is no route to this KDC from host1.second.example, and everything
> breaks.

Cross-realm Kerberos requires client connectivity to the KDCs in both
realms (or all realms when there is more than one hop to the target
realm).  KDCs don't talk to KDCs in other realms or act as traffic
forwarders for clients.

Reply | Threaded
Open this post in threaded view
|

Re: How exactly does cross-realm auth work with KDCs?

Victor Sudakov
Greg Hudson wrote:

> On 03/13/2016 01:10 PM, Victor Sudakov wrote:
> > 3. When I want to ssh further to host2.second.example, which KDC is my
> > ssh client supposed to contact for the host/host2.second.example
> > ticket: the one in FIRST.EXAMPLE or SECOND.EXAMPLE?
>
> Your client contacts the FIRST.EXAMPLE KDC to get a
> krbtgt/[hidden email] ticket, then contacts a
> SECOND.EXAMPLE KDC and presents the cross-realm TGT to get a ticket for
> host/[hidden email].  (The client principal remains
> [hidden email] for all of these tickets.)

So there is absolutely no way the client on host1.second.example could
avoid contacting the the FIRST.EXAMPLE KDC? You know, the
FIRST.EXAMPLE realm is in the internal (protected by firewall)
network, and the SECOND.EXAMPLE realm is outside.

> (The exact sequence of requests depends on whether your client knows
> that host2.second.example belongs in the SECOND.EXAMPLE realm.  

It does from DNS.

> If it
> doesn't know that, then the client will ask the FIRST.EXAMPLE KDC for a
> ticket for host/[hidden email] and get back a
> "referral" in the form of a ticket for krbtgt/[hidden email].)
>
> > Looks like it's trying to contact the KDC in FIRST.EXAMPLE, but there
> > is no route to this KDC from host1.second.example, and everything
> > breaks.
>
> Cross-realm Kerberos requires client connectivity to the KDCs in both
> realms

I see. This is sad.
Why is the cross-realm TGT not forwarded too? If it were
forwarded, we could present it to the SECOND.EXAMPLE KDC, right?

> (or all realms when there is more than one hop to the target
> realm).  KDCs don't talk to KDCs in other realms or act as traffic
> forwarders for clients.
>

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How exactly does cross-realm auth work with KDCs?

Greg Hudson
On 03/13/2016 02:26 PM, Victor Sudakov wrote:
> So there is absolutely no way the client on host1.second.example could
> avoid contacting the the FIRST.EXAMPLE KDC? You know, the
> FIRST.EXAMPLE realm is in the internal (protected by firewall)
> network, and the SECOND.EXAMPLE realm is outside.

I misread your question somewhat (I thought the ssh in step 2 was to a
host in FIRST.EXAMPLE).

You are right that in theory this could work, with some changes.  I
think you're right that delegating a cross-realm TGT along with a local
TGT in step 2 would be sufficient in your scenario.  It's possible that
GSS krb5 mechs could do this automatically whenever delegating creds to
a server in a different realm; I will make a note to look into that.

Another possibility is for step 2 to get a ticket from
[hidden email] to krbtgt/[hidden email] and
delegate that.  (It's possible to get a ticket like this from the
SECOND.EXAMPLE KDCs just by requesting one using the cross-realm TGT.)
This choice would probably require manual client configuration, but it
essentially isolates the target session from the FIRST.EXAMPLE realm,
which is desirable in some cases.  I know some people would like to
introduce this feature, so it might be possible in the future.

Unfortunately, I don't know of an immediate workaround.  I'm less
familiar with Heimdal than with MIT krb5, so it's possible that there is
one that I don't know about.
Reply | Threaded
Open this post in threaded view
|

Re: How exactly does cross-realm auth work with KDCs?

Victor Sudakov
Greg Hudson wrote:

> On 03/13/2016 02:26 PM, Victor Sudakov wrote:
> > So there is absolutely no way the client on host1.second.example could
> > avoid contacting the the FIRST.EXAMPLE KDC? You know, the
> > FIRST.EXAMPLE realm is in the internal (protected by firewall)
> > network, and the SECOND.EXAMPLE realm is outside.
>
> I misread your question somewhat (I thought the ssh in step 2 was to a
> host in FIRST.EXAMPLE).
>
> You are right that in theory this could work, with some changes.  I
> think you're right that delegating a cross-realm TGT along with a local
> TGT in step 2 would be sufficient in your scenario.  It's possible that
> GSS krb5 mechs could do this automatically whenever delegating creds to
> a server in a different realm; I will make a note to look into that.
>
> Another possibility is for step 2 to get a ticket from
> [hidden email] to krbtgt/[hidden email] and
> delegate that.  (It's possible to get a ticket like this from the
> SECOND.EXAMPLE KDCs just by requesting one using the cross-realm TGT.)
> This choice would probably require manual client configuration, but it
> essentially isolates the target session from the FIRST.EXAMPLE realm,
> which is desirable in some cases.  I know some people would like to
> introduce this feature, so it might be possible in the future.
>
> Unfortunately, I don't know of an immediate workaround.  I'm less
> familiar with Heimdal than with MIT krb5, so it's possible that there is
> one that I don't know about.

Greg, thanks a lot for hearing me. There are so few people around with
enough Kerberos expertize to even understand what I am asking. Talking
to you was a pleasure, and a bit of hope.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]