[37838] in Kerberos
Can you please help answer this one question (as I have not been
daemon@ATHENA.MIT.EDU (Brant, Ernest)
Thu Jan 26 12:24:56 2017
From: "Brant, Ernest" <Ernest.Brant@lv.com>
To: "kerberos@mit.edu" <kerberos@mit.edu>
Date: Thu, 26 Jan 2017 17:04:50 +0000
Message-ID: <12B621F760D6DC43981B5F9E619AD0AB8385F959@WHYNXB003.group.net>
Content-Language: en-US
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1415309842702588398=="
Errors-To: kerberos-bounces@mit.edu
--===============1415309842702588398==
Content-Language: en-US
Content-Type: multipart/related;
boundary="_004_12B621F760D6DC43981B5F9E619AD0AB8385F959WHYNXB003groupn_";
type="multipart/alternative"
--_004_12B621F760D6DC43981B5F9E619AD0AB8385F959WHYNXB003groupn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hello
Can you please assist me with the following question as I have read a lot o=
f Kerberos documentation and still cannot find the answer to one question i=
n any of the documents (unless I missed it).
"How does a trusting Kerberos TGS get it's 'session key' to the requester i=
n the trusted domain"
The documents I have read and videos I have watched seem to 'gloss over' th=
is point and do not explain how it is achieved which is fundamental to unde=
rstanding how a UPN (requester) in a trusted realm can access to a resourc=
e in trusting realm
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.
However, this cross-realm TGT is given to the requester via it's 'local' KD=
C (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 'sess=
ion key' into a TGT issued by another KDC (e.g. the trusted KDC in this ins=
tance on the other side of the trust)
This same 'session key' has to be supplied to the requester by way of encry=
pting 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.
This is vital as this 'session key' needs to be 'known' to the trusting KDC=
in order that it can decrypt the authenticator sent by the requester when =
the requester presents this cross-realm TGT and its authenticator
I can only assume one of two things
1) As well as a shared secret (krbtgt hash) used to encrypt the TGT, t=
here is also a shared (and therefore unchanging) shared 'session key' (but =
this would appear to be a security risk)
2) The trusting KDC supplies a session key (different each time) to th=
e trusted KDC by sending it encrypted with the same shared secret used to e=
ncrypt the TGT
Please advise
Ernest Brant
Infrastructure Analyst
Group IT
LV=3D
2nd Floor Pillar B4
Victoria House
Bournemouth, BH1 2HF
* 01202 542067 / 07501 720270
[cid:image001.png@01CF7996.DA7AA600]
* Ernest.Brant@lv.com<blocked::mailto:Ernest.Brant@lv.com>
This email (including any attachment) may contain confidential and/ or lega=
lly privileged information. If you are not the intended recipient, please n=
otify us on +44(0)1202 292333 ext. 30033 and destroy it and any copies. Una=
uthorised access, use, disclosure, storage or copying of this email is not =
permitted and, unless you are the intended recipient, you are not entitled =
to rely on it in any way. Any opinions expressed in this email are those of=
the individual sending it and not necessarily those of LV=3D.
This email is believed to be free of any virus or other defect. However, co=
mmunication by email cannot be guaranteed to be free from defect, error fre=
e or secure. If you choose to communicate with us by email you must realise=
that there can be no guarantee of privacy and you should carry out your ow=
n security checks before opening any email or attachment. LV=3D accepts no =
liability for any loss or damage which may be caused by any lack of privacy=
, software viruses or other defect.
LV=3D reserves the right to monitor and inspect any email (including any at=
tachment) sent to and/or from LV=3D for reasons of security and for monitor=
ing internal compliance with our office policies. LV=3D may use email monit=
oring or blocking software at its discretion. You are responsible for ensur=
ing that any email you send is appropriate and within the bounds of the law=
.
LV=3D and Liverpool Victoria are trade marks of Liverpool Victoria Friendly=
Society Limited and LV=3D and Liverpool Victoria are trading styles of the=
Liverpool Victoria group of companies. The registered office address for a=
ll LV=3D companies is County Gates, Bournemouth, BH1 2NF. Information about=
the LV=3D group of companies can be found via this link www.lv.com/legal/l=
vcompanies<http://www.lv.com/legal/lvcompanies/>
--_004_12B621F760D6DC43981B5F9E619AD0AB8385F959WHYNXB003groupn_--
--===============1415309842702588398==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1415309842702588398==--
