Can you please help answer this one question (as I have not been able to find the answer in the documents)

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

Can you please help answer this one question (as I have not been able to find the answer in the documents)

Brant, Ernest
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]

* [hidden email]<blocked::mailto:[hidden email]>


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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Can you please help answer this one question (as I have not been able to find the answer in the documents)

Ken Hornstein
>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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Can you please help answer this one question (as I have not been able to find the answer in the documents)

Brant, Ernest
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



/ [hidden email]

-----Original Message-----
From: Ken Hornstein [mailto:[hidden email]]
Sent: 26 January 2017 17:58
To: Brant, Ernest
Cc: [hidden email]
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos