Kerberos Protocol? Is this correct?

Question

I'm reading what Kerberos : The Definitive Guide, the original paper from Xerox (Needham - Schroeder) , MIT site and Wikipedia. I'm having some challenges putting the protocol together. Is this correct? Is there some other documentation on it?

I tried to follow the Xerox Articles "Protocol 1" closer as they seem to show the protocol in more detail. I omit the PKE, case (pkinit) for now that will be another post.

Kerberos 5 : Needham - Schroeder Protocol

A = Client Principal A, B = Server Principal B, AS = Authentication Server, I = time, A->B : {G, H, I} = A sends message to B with contents {...}. {B}^{KA} = Key A encrypts {B}. CK_AB = conversations session key between A and B.

Requesting a ticket to another service, start with TGS Ticket Granting Server.

Client Authentication to AS:

1. Initial request when client has no tickets or tickets are expired, B = "krbtgt/REALM@REALM" client principal (Ticket Granting Server TGS), use kinit sends to KDC.
2. A -> AS : {A, B, I_a, I_max} : AS_REQ
3. AS verifies that B principal exists and time stamp I is close to local time. Grants ticket or throws error In AS_RESP. Assume no error here.
4. Authentication server responds with timestamp I, B/TGS Principal, Session Key CK_AB for A and B, Ticket Granting Ticket (TGT) encrypted with KB_KTGS.
5. AS -> A : {I_a, I_max, B, CK_AB, {CK_AB, A, I_a, I_max}^{KB}}^{KA} : AS_REP
6. Ticket Granting Ticket TGT = {CK_AB, A, I_a, I_max}^{KB}, and CK, I can be stored in client's local credential cache. See below on caching protocol change.
7. Make request to Ticket Granting Server TGS using the authenticator {CK_AB, A, I_a, I_max}^{KB}.
8. A->B : {CK_AB, A, I_a, I_max}^{KB} : TGS_REQA
9. Now continue with Reply Attack Prevention.

This is as documented by Xerox paper:

10. B->A : {I_b}^{CK_AB} : TGS_REQB : Where B/TGS and I_b is the ticket lifetime
11. A->B : {I_b - 1}^{CK_AB} : TGS_REQB

This is as documented by The Definitive Guide:

10. A->B : {1_b}^{CK_AB} : TGS_REQB
11. B->A : {1_b + 1}^{CK_AB} : TGS_REQB

Client A Service Authorization request to TGS to access service from C:

12. A->B: {A, C, I_a, {CK_AB, A, I_a, I_max}^{KB}}^CK_AB : TGS_REQC

13. TGS/B creates new session key for A and C to communicate CK_AC is created and sent in reply.

14. B->A: {CK_AC, I_c, {CK_AC, A, A_IP, I}^{KC}}^CK_AB : TGS_REP

Client A Service Request to C:

15. Client has session key {CK_AC, I_c, {CK_AC, A, I}^{KC}}^CK_AB

16. Client sends Authenticator to Application Server

17. A->C: {A, C, I_a, {CK_AC, A, I}^{KC}}^CK_AC : AP_REQ

18. Server provides requested services to client. : AP_REP

Steps if CK is kept in client credential cache, reduces protocol steps to 3. Reduces compute on AS to generate {I_a, B, CK, {CK,A}^KB}^KA and client to decrypt and network traffic:

1. A->B : {CK_AB, A}^KB, {I_A2}^CK_AB
2. B->A : {I_A2 - 1, I_B}^CK_AB
3. A->B : {I_B - 1}^CK_AB

Answer 1

A->B : {I_b - 1}^{CK} : TGS_REQB

As far as I understand, the choice between I_b + 1 or I_b - 1 is arbitrary by the protocol designer, as they both equally prove that A was able to decrypt I_b using CK.

I don't remember this being part of the TGS exchange, but it is also part of the AS exchange (as part of the "pre-authentication" or "preauth" feature in Kerberos 5), where the client doesn't receive a ticket immediately – it has to reply with I_a + 1 to prove that it knows K_A and can decrypt I_a. Although technically this is optional in the protocol, it is generally enforced for any "password" AS_REQs.

TGS changes session key CK to CK_b?

Not exactly. The CK is not global state; it belongs to the ticket that it was issued with. The full name of 'CK' was originally "conversation key". So it isn't that the CK is "changed", but rather there are multiple CKs co-existing, as there are multiple conversations going on.

During the AS exchange you received a ticket for the TGS service with its accompanying CK_A_B, and later during the TGS exchange you received a ticket for the other service with its accompanying CK_A_C.

So you should divide your example process into three "conversations":

1. The AS exchange (A↔AS) uses the client's long-term key K_A to obtain a single ticket and its accompanying CK. This ticket is usually the TGT (i.e. ticket for the TGS).

   The initial AS exchange is special in that there's no pre-existing CK to protect it, so it's only protected by the client's long-term key K_A.

2. The TGS exchange (A↔B_TGS) uses the 'krbtgt' service ticket (and its accompanying CK_A_B_TGS conversation key) to obtain a ticket for the final service (with its accompanying CK).

3. Further exchanges (A↔C, A↔D…) use the obtained service ticket (and its accompanying CK_A_C conversation key) to authenticate to the whatever final service.

If the client needs a different service ticket, it repeats step 2 and re-uses the previous TGT and CK_A_B_TGS (allowing it to skip step 1).

But it is also possible in Kerberos to use the AS exchange to obtain a ticket for any service, in which case step 2 would be skipped. This is generally rare but is used e.g. for the 'kadmin' or 'kpasswd' protocols, both of which use AS_REQ to directly get tickets for the respective services (for policy enforcement reasons).

As another example, the XNS Authentication Protocol (of the Xerox XNS platform), which predated Kerberos, didn't yet have separate AS/TGS and the user's long-term key ("strong key") was directly used to request all service tickets.

A_IPADDR

Modern Kerberos implementations generally no longer include IP addresses inside tickets – mainly due the unpredictability of NATs. MIT Kerberos still has the option, but it's hardly used if ever.