Hello Ken Thank you very much for taking the time to reply, that is very generous of you to take the time.
I got it now :) I was reading some further information earlier this morning on the various cyphers used in the various exchanges (e.g. RC4 AES) then I had a 'light bulb moment' which matches with what you explained :) Suddenly it occurs to me the remote KDC does not have to 'generate' the 'session key' it just has to be able to 'read it' + trust the key it is reading is genuine (not from a man in the middle attack). My initial mental block was due to the fact when I think of 'session keys' I think if something 'always generated on the host (e.g. server or client) to which you communicate directly, then it hit me as above! So local KDC creates a new session key (places in the remote TGT which is then encrypted with a shared secret (krbtgt@LOCAL&@REMOTE, not sure if that is the correct way to write it). Plus same session key is encrypted with the requesters long-term key) sent back to the client in the remote TGT reply. Then when client presents this remote TGT (plus its authenticator) to remote KDC, remote KDC can obtain session key (as it knows the shared secret) and use this to decrypt the client's authenticator, then create a TST (ticket service ticket) with a new session key which the remote KDC can encrypt with the session key "it now shares with the client" (and that was the bit I was stuck on before)...etc. Thanks again and best regards Ernest Brant Infrastructure Analyst Group IT LV= 2nd Floor Pillar B4 Victoria House Bournemouth, BH1 2HF B 01202 542067 / 07501 720270 / ernest.br...@lv.com -----Original Message----- From: Ken Hornstein [mailto:k...@cmf.nrl.navy.mil] Sent: 26 January 2017 17:58 To: Brant, Ernest Cc: kerberos@mit.edu Subject: Re: Can you please help answer this one question (as I have not been able to find the answer in the documents) >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 This email (including any attachment) may contain confidential and/ or legally privileged information. If you are not the intended recipient, please notify us on +44(0)1202 292333 ext. 30033 and destroy it and any copies. Unauthorised 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=. This email is believed to be free of any virus or other defect. However, communication by email cannot be guaranteed to be free from defect, error free 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 own security checks before opening any email or attachment. LV= accepts no liability for any loss or damage which may be caused by any lack of privacy, software viruses or other defect. LV= reserves the right to monitor and inspect any email (including any attachment) sent to and/or from LV= for reasons of security and for monitoring internal compliance with our office policies. LV= may use email monitoring or blocking software at its discretion. You are responsible for ensuring that any email you send is appropriate and within the bounds of the law. LV= and Liverpool Victoria are trade marks of Liverpool Victoria Friendly Society Limited and LV= and Liverpool Victoria are trading styles of the Liverpool Victoria group of companies. The registered office address for all LV= companies is County Gates, Bournemouth, BH1 2NF. Information about the LV= group of companies can be found via this link www.lv.com/legal/lvcompanies<http://www.lv.com/legal/lvcompanies/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
