3

I have read the description of Kerberos at sites like this very informative one: http://www.roguelynn.com/words/explain-like-im-5-kerberos/ I think I understand generally how it works:

  1. User presents identity to the Authentication Server
  2. Authentication Server gives user a Ticket Granting Ticket (TGT), which includes the TGS session key
  3. User connects to the TGS with the TGS session key
  4. TGS replies with a service session key
  5. User connects to the service using the service session key

(I'm skipping the parts about how the values are encrypted with various secret keys, in order for each machine to verify that the encryption was done by the AS or the TGS, which possesses the secret keys.)

What I don't understand is why it isn't simpler to do it in two steps, with public-key encryption:

  1. User "bennett" authenticates themselves to the AS and generates a temporary public/private key pair. The AS digitally signs bennett's public key saying, "The person using this public key really is bennett, at least for the next 8 hours."
  2. User "bennett" connects to a service, with the certification of their public key digitally signed by the AS, and uses the public/private key pair to sign their request for a service. The service decides whether to allow user "bennett" or not.

Isn't this simpler? What am I missing?

My only idea was that maybe since public-key encryption is slower than secret-key encryption, Kerberos was more efficient for that reason. But I would have thought that the network roundtrips were the slowest part of the operation, and therefore that three roundtrips using secret key encryption would still be slower than two roundtrips using public key encryption. Is that not the case?

Bennett
  • 653
  • 3
  • 9
  • 2
    Keep in mind that Kerberos is a Very Old protocol. At the time asymmetric crypto was way more expensive compared to symmetric than it is now. – Steve Aug 24 '18 at 18:32
  • @Steve thanks. If you'd submitted that as an answer, I would have accepted it since that entirely answers the question and that's all I really needed to know :) – Bennett Aug 26 '18 at 06:07

2 Answers2

1

It might be right that asymmetric cryptography has much easier steps than secret-key encryption, but there are efficiency barriers such as CPU cycles, complexity of the asymmetric cryptography algorithm and network bandwidth.

Asymmetric algorithms use much more complex mathematics than symmetric algorithm to carry out their functions, which require more processing time and can be extra hit to the Kerberos performance. In addition, asymmetric cryptography must include extra randomness (such as initialization vector, nonce) which makes encrypting messages sometimes bigger than the actual plaintext data size - depends on data size, key size and complexity of the cryptography algorithm used.

RFC4556 describes protocol extensions (PKINIT). These extensions provide a method for integrating public key cryptography into the initial authentication exchange. However, there are some security considerations mentioned such as:

  1. The security of the overall system is significantly weakened by using insufficient random inputs.

  2. Kerberos error messages are not integrity protected; as a result, the domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered with by an attacker so that the set of domain parameters selected could be either weaker or not mutually preferred.

  3. In order to trust a KDC certificate that is certified by a CA as a KDC certificate for a target realm, the client MUST verify that the KDC certificate's issuing CA is authorized to issue KDC certificates for that target realm. Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established.

  4. PKINIT allows the use of the same RSA key pair for encryption and signing when doing RSA encryption-based key delivery. This is not recommended usage of RSA keys and by using DH-based key delivery, this is avoided.

  5. When the Diffie-Hellman key exchange method is used, additional pre-authentication data may be dropped or added by attackers without being detected by either the client or the KDC - which open the door for insertion of malicious data without being detected.

For more information check these links:

Community
  • 1
Hussain Mahfoodh
  • 169
  • 8
  • You wrote "Kerberos always scales more efficiently in symmetric encryption than it is in asymmetric encryption" and then quoted from the RFC but I don't think the quote from the RFC supports what you're claiming. The RFC says that having a centralized key store scales better than having peer-to-peer keying (because then you just need one key per client and one per server, i.e. O(m+n), instead of one key per client-server pair, i.e. O(m*n). It's not about whether symmetric scales better than asymmetric. Asymmetric keys would also scale as O(m+n) since each machine only needs one pair. – Bennett Aug 24 '18 at 06:12
  • "Not to mention that that some versions of Kerberos - such as Version 5 - is set up to reject ticket requests from any host whose clock is not within the specified maximum clock skew of the KDC, where the default value for maximum clock skew is 300 seconds, or five minutes. Using asymmetric cryptography here can be clearly infeasible." What does the clock skew have to do with making asymmetric cryptography infeasible? – Bennett Aug 24 '18 at 06:13
  • @Bennett You are correct. I found this paper that support your comment. https://arxiv.org/pdf/1308.4895.pdf (The answer has been edited) – Hussain Mahfoodh Aug 24 '18 at 09:44
0

I think you should probably read this question first: why kerberos?

As for why three transactions not two, here are my opinions:

Presuming that user "bennett" wants to use a printer in the office.

  1. AS provides authentication for the user/client, as you said, "The person using this public key really is bennett", and AS gives a TGT for bennett to get access to TGS; And bennett can send a request to get access to printer server with sending this TGT to TGS;
  2. TGS provide some kind of authorization check if bennett can have access to Server/Service, and if passed, TGS sends back a ticketST for bennett to get access to Server;

To be clear, AS provides authentication login to this realm (area including users and servers), and TGS provide authorisation check in this realm for users: Can bennett get access to the printer?

So, can three combine into two? maybe, but it may cause some security problems.

It's more like a TCP question (three handshakes). For example, KDC auth bennett and sends ticketST directly to user bennett, then KDC would never know if the user received the ticket correctly.

But with AS_exchange and TGS_exchange, TGS can check the connection is working after checking of the ticketTGS.

So I don't think Steve's answer is that correct. (not the matter about time, but security)

schroeder
  • 123,438
  • 55
  • 284
  • 319
shawn Smith
  • 1
  • 1
  • More specifically,the core of this topic is why AS_TX and TGS_TX can't combine into one.And this is why: the Client send AS_TX to get its identity credentials so that he/she never has to enter passwords to log in once he/she wants to use a service.The first tx is for the Clients' identity auth. As for the TGS_TX,it's for auth of the Service use. – shawn Smith Jul 19 '22 at 07:36