Return to Answer

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.

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

So you should consider AS and TGS as two semi-distinct entities (even though they're a single program), and divide your example process into three "conversations":

1. The AS exchange (A↔B_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.

Normally the client repeats step 2 for each new service ticket it wants to obtain, reusing the already cached TGT and CK_A_B_TGS (allowing it to skip step 1).

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 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). That makes it even more important to treat the AS_REQ/REP and TGS_REQ/REP as independent stages.

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->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.

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.

During the AS exchange you received a ticket for the TGS service with its accompanying CK_A_B_TGS, 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↔B_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.

It is 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 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). That makes it even more important to treat the AS_REQ/REP and TGS_REQ/REP as independent stages.

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->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.

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

So you should consider AS and TGS as two semi-distinct entities (even though they're a single program), and divide your example process into three "conversations":

1. The AS exchange (A↔B_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.

Normally the client repeats step 2 for each new service ticket it wants to obtain, reusing the already cached TGT and CK_A_B_TGS (allowing it to skip step 1).

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 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). That makes it even more important to treat the AS_REQ/REP and TGS_REQ/REP as independent stages.

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->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.

However, from what I remember, this isn't part of the TGS exchange; rather it's part of the AS exchange, as part of the "pre-authentication" or "preauth" feature in Kerberos 5.

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.

During the AS exchange you received a ticket for the TGS service with its accompanying CK_A_B_TGS, 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↔B_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.

It is 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 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). That makes it even more important to treat the AS_REQ/REP and TGS_REQ/REP as independent stages.

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->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.

During the AS exchange you received a ticket for the TGS service with its accompanying CK_A_B_TGS, 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↔B_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.

It is 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 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). That makes it even more important to treat the AS_REQ/REP and TGS_REQ/REP as independent stages.

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.