[37839] in Kerberos
Re: Can you please help answer this one question (as I have not been
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Thu Jan 26 12:58:42 2017
Message-Id: <201701261758.v0QHwAjw024145@hedwig.cmf.nrl.navy.mil>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: "Brant, Ernest" <Ernest.Brant@lv.com>
In-Reply-To: <12B621F760D6DC43981B5F9E619AD0AB8385F959@WHYNXB003.group.net>
MIME-Version: 1.0
Date: Thu, 26 Jan 2017 12:58:10 -0500
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>Can you please assist me with the following question as I have read a
>lot of Kerberos documentation and still cannot find the answer to one
>question in any of the documents (unless I missed it).
>
>"How does a trusting Kerberos TGS get it's 'session key' to the
>requester in the trusted domain"
FWIW, I personally prefer the terms "local" and "foreign" when talking about
cross-realm Kerberos, since that's relatively clear.
>I understand how the cross-realm TGT is encrypted with a shared secret
>that the KDCs in both realms (either end of the trust) share, OK so far.
Right.
>However, this cross-realm TGT is given to the requester via it's 'local'
>KDC (e.g. a KDC in their own realm).
>
>Therefore how does the TGS (ticket granting service) 'session key' for
>the KDC in the trusting realm (e.g. the other side of the trust) get
>it's 'session key' into a TGT issued by another KDC (e.g. the trusted
>KDC in this instance on the other side of the trust) This same 'session
>key' has to be supplied to the requester by way of encrypting it with
>the requester's long term key, which explains why it need to be the
>local KDC sending the reply as it knows the requester long term key.
You've got it slightly wrong there. Once you are issued a TGT (via
AS messages), further tickets are acquired via TGS messages, where the
KDC uses the session key from the TGT.
Cross-realm is just done via TGS messages. Perhaps this will be clearer:
- User "foo" gets TGT "krbtgt/LOCAL@LOCAL". Session key encrypted via user's
long-term secret (password) and long-term key for krbtgt/LOCAL@LOCAL (AS
exchange).
- User "foo" gets ticket "krbtgt/LOCAL@REMOTE". Session key encrypted both
using the long-term secret for "krbtgt/LOCAL@REMOTE" (which both LOCAL
and REMOTE KDCs know) and the session key from that was in
"krbtgt/LOCAL@LOCAL". Note: the user is talking to KDC LOCAL, via a
TGS exchange.
- User foo gets a ticket for "service/remote.host@REMOTE". Session key
is encrypted with session key from krbtgt/LOCAL@REMOTE and service long-term
key. User talks to KDC REMOTE for this (TGS exchange).
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
