For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Dani_Gallardo_1's avatar
Dani_Gallardo_1
Icon for Nimbostratus rankNimbostratus
Jul 28, 2016

APM SSO - Kerberos double hop delegation issue

Hi,

 

We are using APM per-app vpn for allowing mobile devices to access internal applications via VPN. Authentication is based on username/password and device certificate.

 

Some applications are doing SSO with Kerberos and it is working fine in a normal scenario, when only one delegation is performed (by the APM). In this scenario: Client credentials are delegated by F5 to the final application

 

However, we have another application (Alfresco) which by itself already performs Kerberos delegation to forward user credentials between different application components.

 

When accessing Alfresco via APM, then double hop delegation is done and it is not working. After taking some network traces we see that KDC returns a TGS ticket with ok-as-delegate flag but the SPNEGO packet sent from the F5, sends the flag "DO NOT DELEGATE" in the authenticator part.

 

Theorically, when the client (F5) receives a TGS with ok-as-delegate, GSSAPI should set the GSS_C_DELEG_FLAG.

 

Alfresco receives the AP-REQ packet and fails when checking the delegation information, honoring the client.

 

It looks like F5 Kerberos' client is not behaving as expected. We would like to know if there is any way to make sure the F5 kerberos client can set the Delegation Flag when receiving a TGS token with ok-as-delegate flag from the KDC.

 

Thanks in advance.

 

application delivery
BIG-IP Access Policy Manager (APM)
kerberos
security
SSO

3 Replies

  • Nick_Koch_18978's avatar
    Nick_Koch_18978
    Icon for Nimbostratus rankNimbostratus
    Aug 01, 2016

    We are also experiencing the same scenario with Hitachi HCP Anywhere. Waiting to hear a response from F5 on the issue.

     

    • Antonio_Macia_R's avatar
      Antonio_Macia_R
      Icon for Nimbostratus rankNimbostratus
      Aug 11, 2016

      After opening a case with F5 we confirmed that they deny by default the double delegation. The RFC leaves this behaviour as optional, implementation dependant. F5 decided to not allow the double delegation and there is no way to change this except filling a "Request For Enhancement"

       

      Find below the official response:

       

      This is not a bug. There is no RFC stating that a GSSAPI client must delegate if OK-AS-DELEGATE flag is set in a Service ticket. There are GSSAPI implementations that do not honor the OK-AS-DELEGATE flag.

       

      OK-AS-DELEGATE is a Microsoft extension added to RFC4120 that allows the administrator of a Kerberos realm to communicate with a particular service that is trusted for delegation. It can be set on AD with the TD userAccountControl bits.

       

      This Kerberos flag is just an indication or recommendation by KDC to the GSSAPI client that it can request delegation for that service.

       

      From RFC4120 (5.3 Tickets -> flags): ok-as-delegate: This flag indicates that the server (not the client) specified in the ticket has been determined by policy of the realm to be a suitable recipient of delegation. A client can use the presence of this flag to help it decide whether to delegate credentials (either grant a proxy or a forwarded TGT) to this server. The client is free to ignore the value of this flag.

       

      GSS-API leaves the determination of whether delegation is desired to the client application turning on "deleg_req_flag" (GSS_C_DELEG_FLAG)

       

      From RFC2743 (1.2.9: Delegation): The GSS-API allows delegation to be controlled by the initiating application via a Boolean parameter to GSS_Init_sec_context(), the routine that establishes a security context.

       

      However, the simple delegation control provided by GSS-API should always be able to over-ride other mechanism-specific delegation controls; if the application instructs GSS_Init_sec_context() that delegation is not desired, then the implementation must not permit delegation to occur.

       

      RFC5896 adds a new input flag "deleg_policy_req_flag" (GSS_C_DELEG_POLICY_FLAG) to request delegation to the given target only when approved by central policy.

       

      If the initiator sets the deleg_policy_req_flag (and not deleg_req_flag), the Kerberos GSS-API mechanism MUST only delegate if OK-AS-DELEGATE is set [RFC4120] in the service ticket. Other policy checks MAY be applied. If the initiator sets deleg_req_flag (and not deleg_policy_req_flag), the behavior will be as defined by [RFC2743]. If the initiator set both the deleg_req_flag and deleg_policy_req_flag, delegation will be attempted unconditionally.

       

      A Request For Enhancement (RFE) could possibly be requested, if you are interested in this, I can follow up with the RFE template to be filled.

       

Related Content