Options

Kerberos Question

gojericho0gojericho0 Member Posts: 1,059 ■■■□□□□□□□
Once a client sends a session ticket to the server and the session is established is there anything to prevent a man in the middle attack? Is the time window periodically checked during the session?

Comments

  • Options
    agustinchernitskyagustinchernitsky Member Posts: 299
    Hello,

    From my understanding, the nice thing about kerberos is that passwords are never sent. So, once the KDC grants service ticket, there are no risks... Of course, you can always do man in the middle, but you won't capture passwords from kerberos...

    look at this:

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/security/kerberos.mspx
  • Options
    sprkymrksprkymrk Member Posts: 4,884 ■■■□□□□□□□
    The MTM attack would have to take place during the transmission of the session ticket. If that open window is missed, then theoretically a MTM attack would not be possible. Remember however, when the KDC issues the session ticket, it is encrypted with the clients private key (each client has it's own corresponding private key stored locally and a copy on the KDC), so client 1 gets a session key encrypted with client 1's private key, and client 2 gets the SAME session key, but encrypted using client 2's private key. Once they both have the session key they can communicate securely with that key This session key is unique per conversation and has a limited lifetime.
    The other way Kerberos is susceptible is if the KDC is compromised and the secret keys are stolen.
    All things are possible, only believe.
  • Options
    gojericho0gojericho0 Member Posts: 1,059 ■■■□□□□□□□
    Thanks for the responses
    sprkymrk wrote:
    Once they both have the session key they can communicate securely with that key This session key is unique per conversation and has a limited lifetime.

    So once a session has been established with a server, is the session key continuously sent to authenticate the user during the duration of the session or, only resent when the session time limit has expired?
  • Options
    gojericho0gojericho0 Member Posts: 1,059 ■■■□□□□□□□
    Thanks that second link helps a lot!
  • Options
    agustinchernitskyagustinchernitsky Member Posts: 299
    The session key is reused if its in the cache and if it is valid... if not, the wrk station requests the TGT of the KDC a new session key.

    Good to know it helps... the first link wasn't so clear... icon_sad.gif
  • Options
    sprkymrksprkymrk Member Posts: 4,884 ■■■□□□□□□□
    gojericho0 wrote:
    Thanks for the responses
    sprkymrk wrote:
    Once they both have the session key they can communicate securely with that key This session key is unique per conversation and has a limited lifetime.

    So once a session has been established with a server, is the session key continuously sent to authenticate the user during the duration of the session or, only resent when the session time limit has expired?
    The session key is not "continuously" sent. It is sent once, then all communication is encrypted with that session key until the key expires or the conversation is ended. Default key life is 8 hours, which means that if data is captured during transit, the key will likely have changed by the time the attacker can crack it.
    All things are possible, only believe.
  • Options
    gojericho0gojericho0 Member Posts: 1,059 ■■■□□□□□□□
    That was the part I was misunderstaning. I just thought the encryption was done during authentication and session establishment. I did not realize data was encrypted after the session is established. That makes much more sense now.

    Thanks Again!
  • Options
    agustinchernitskyagustinchernitsky Member Posts: 299
    Oppss! I read Session Ticket and not session Key... Silly me! The session key or "logon key" is transfered to the work station when the users logins and gets the TGT & TGS. Then it uses the session key to communicate... until it expires or the session closes.

    All tickets are encrypted...
Sign In or Register to comment.