Hello 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" The documents I have read and videos I have watched seem to 'gloss over' this point and do not explain how it is achieved which is fundamental to understanding how a UPN (requester) in a trusted realm can access to a resource 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' 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. 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, there 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 the trusted KDC by sending it encrypted with the same shared secret used to encrypt the TGT Please advise Ernest Brant Infrastructure Analyst Group IT LV= 2nd Floor Pillar B4 Victoria House Bournemouth, BH1 2HF * 01202 542067 / 07501 720270 [cid:image001.png@01CF7996.DA7AA600] * ernest.br...@lv.com<blocked::mailto:ernest.br...@lv.com> 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
