Hacker is able to sniff the traffic between the editor, the KDC and the network scanner during the key exchange. Is he/she able to decrypt the sniffed data key?
2
-
Err... the primary goal of Kerberos has always been allow secure authentication over unsecure channels. So unless a flaw in implementation, having the full trace of all exchanged packets is not enough to extract any secret. That being said, AFAIK Kerberos has no provision for data encryption so I cannot guess what you exactly mean with data key.– Serge BallestaJul 9, 2019 at 7:39
-
It does have a provision for transmitting arbitrary data encrypted using the krb-priv messaging constructs. Just not protecting data at rest.– SteveJul 9, 2019 at 18:44
Add a comment
|
1 Answer
Kerberos is designed to provide secure authentication over insecure networks, and uses pre-agreed (during enrolment) or randomly generated symmetric keys to encrypt data between the KDC and the client.
Provided your choice of encryption algorithms are sound, this will ensure that an attacker cannot decrypt the data without brute-forcing the encryption algorithm.
Kerberos can use a variety of cipher algorithms to protect data. A Kerberos encryption type (also known as an enctype) is a specific combination of a cipher algorithm with an integrity algorithm to provide both confidentiality and integrity to data.
Clients make two types of requests (KDC-REQ) to the KDC: AS-REQs and TGS-REQs. The client uses the AS-REQ to obtain initial tickets (typically a Ticket-Granting Ticket (TGT)), and uses the TGS-REQ to obtain service tickets.
The KDC uses three different keys when issuing a ticket to a client:
The long-term key of the service: the KDC uses this to encrypt the actual service ticket. The KDC only uses the first long-term key in the most recent kvno for this purpose.
The session key: the KDC randomly chooses this key and places one copy inside the ticket and the other copy inside the encrypted part of the reply.
The reply-encrypting key: the KDC uses this to encrypt the reply it sends to the client. For AS replies, this is a long-term key of the client principal. For TGS replies, this is either the session key of the authenticating ticket, or a subsession key.
