Constrained Delegation : Can Service A decrypt service B’s service ticket ?

Question

Hi There,

I was going through the MS-SFU ( Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol Specification) document and I need some help in understanding Constrained Delegation (S4U2Proxy) better.

 

[ Section 5 Security Considerations

The S4U2proxy extension allows a service to obtain a service ticket to a second service on behalf of a user. When combined with S4U2self, this allows the first service to impersonate any user principal while accessing the second service. This gives any service allowed access to the S4U2proxy extension a degree of power similar to that of the KDC itself.]

Here is the scenario

1.       Constrained delegation is configures in Win2003 AD domain Controller for the user “Proxy” and   proxy service “A”.

2.       Service A acquires its service ticket on behalf of the user U ( using S4U2Self)

3.       Service A also acquires the service ticket for Service B on behalf of the user U ( using S4U2proxy).

 

Here is my question

1.       Can Service A decrypt service B’s service ticket ?

2.       If yes, how will service A get the service key of service B ?

 

Regards,

Mohan

Answer 1

Hi, Mohan,

  Thanks for your question regarding Constrained Delegation.  I will work on it and get back to you as soon as I complete the investigation.


Regards,

---

Hongwei Sun -MSFT

Answer 2

 Hi, Mohan,

    For your  question,  in Kerberos, any service ticket can only be encrypted/decrypted using the long-term key that is derived from shared secret only known to KDC and the service that a ticket was created for.  In your case, only Service B can decrypt the service ticket to itself.   Server A will present the service ticket to Service B untouched.     Please see 1.1  RFC 4120 (http://www.ietf.org/rfc/rfc4120.txt)  for more details.

 

   Furthermore,  even the service ticket for Service B is for user U,  Service A ,which is requesting the service ticket on behalf of the user from KDC, still owns the session key to retrieve the service ticket from TGS-REP.  Please see the processing logic of S4UProxy in  3.1.4.2  MS-SFU (http://msdn.microsoft.com/en-us/library/cc246071(PROT.10).aspx)

 

  Please let us know if you have more questions.

Thanks!

---

Hongwei Sun -MSFT

Answer 3

Hi Hongwei Sun,

Thanks for your response.

I have 2 follow-up question.

>Furthermore,  even the service ticket for Service B is for user U,  Service A ,which is requesting the service ticket on behalf of the user from KDC, still owns the session key to retrieve the service >ticket from TGS-REP.  Please see the processing logic of S4UProxy in  3.1.4.2  MS-SFU (http://msdn.microsoft.com/en-us/library/cc246071(PROT.10).aspx)


1. U (User) ---------------------------> Service A ( CIFS Proxy) --------------------------> Service B ( CIFS server)
I understand with KCD ( Kerberos Constrained Delegation) , service A can establish a security context ( session key and service tkt) with Service B on behalf of the user. I was wondering if there is a way to establist another security context between user U and Service A ?
How will service A authenticate user U and create another security context   ?

2. >Section 5 Security Considerations
>The S4U2proxy extension allows a service to obtain a service ticket to a second service on behalf of a user. When combined with S4U2self, this allows the first service to >impersonate any user principal while accessing the second service. This gives any service allowed access to the S4U2proxy extension a degree of power similar to that of the >KDC itself.

What does "This gives any service allowed access to the S4U2proxy extension a degree of power similar to that of the KDC itself" mean ?
I understand that service A can acquire a serive ticket and session key ( when s4u2self is combined with s4u2proxy) for any other allowed service X and impersonate any user. But is there a way for Service A (Proxy) to behave like a KDC and authenticate the user using the acquired serive ticket and session key ?

Thanks
Mohan

Answer 4

Hi, Mohan,

  I will review your question and post a response soon.

Thanks!

---

Hongwei Sun -MSFT

Answer 5

Hi Mohan,

 

I hope I understood your questions correctly. If not, please accept my apologies and give me some more insight so I can have a better understanding of them.

 

 

Question #1:

 

The fact that ServiceA is allowed to behave as a proxy and use S4U2Proxy and S4USelf does not prevent the service and the user from communicating by usual Kerberos means.

 

User U could still request a TGS to the KDC to access ServiceA as usual provided that the environment is set for such procedure.

 

S4USelf is primarily used in cases where the USER does not authenticate with ServiceA using Kerberos in the first place but other means of authentication.

 

 

Question #2:

 

The analogy done in the document is to make sure that the audience understands that this functionality allows certain actions from the services that if they are compromised can affect several other services in the network instead of just themselves.

 

ServiceA can authenticate the User by any means established between them. The fact that ServiceA can act as a Proxy for the User to access other services implies that ServiceA can obtain TGSs from the KDC on behalf of the user. If constraint delegation is enabled, then ServiceA can only obtain tickets to access specific services impersonating the user.

On the other hand, KDC’s job is to authenticate users and to provide the above mentioned tickets to access the services that are registered.

 

 

 

Please let me know if you need further assistance.

 

Thanks and regards,

---

SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team

Answer 6

Hi Mohan,

I would like to know if the information provided answers your questions.

Thanks and regards,

---

SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team