mopdf.com

F5 Technical BriefKerberos Constrained Delegationand Protocol Transition in SmartCard PKI ArchitecturesUsing the F5 BIG-IP Local Traffic Manager to supportfederation of cross-domain service access in a Smart CardPKI-enabled architecture.by Lori MacVittieTechnical Marketing Manager, Application Services

Technical BriefKerberos Constrained Delegation and Protocol Transition in Smart Card PKI ArchitecturesContentsIntroduction3Constrained Delegation Model4Order of Operations5How it Works6Conclusion8References92

Technical BriefKerberos Constrained Delegation and Protocol Transition in Smart Card PKI ArchitecturesIntroductionKerberos has long been considered to reside at the top of the networkauthentication protocol tree as the most secure and, unfortunately, most complexauthentication system. This comes not from the way in which Kerberos is designed,but rather from the complexity of the systems that have grown up around Kerberosthat support identity management, especially when applied across organizationalboundaries.The introduction of smart cards as a means to address the inherent weaknessesin password-based identity management architectures has provided for strongersecurity in organizations adopting such tactics. However, it has also createdadditional challenges in implementing secure architectures relying on Kerberos forauthentication. One of the negative effects of smart cards on organizations was theinability to leverage the functions of an Application Delivery Controller (ADC) in theinfrastructure because the ADC was unable to obtain a ticket for services on behalfof the client.Kerberos delegation, as specified by version 5 of the protocol, resolved thisthrough two new extensions to the authentication protocol: Protocol transitionand constrained delegation. Protocol transition allows a service using Kerberos forauthentication to obtain a Kerberos service ticket to itself on behalf of a user orproxy without requiring the user or proxy to be part of the Kerberos environment.This is an important feature as it allows users to send a request to a service usingcredentials that are not acceptable for Kerberos authentication such as a smartcard, which presents a client certificate as credentials. This method creates auser token for authenticated users, which is used by a service with the necessaryimpersonation privileges to ultimately obtain a service ticket for the desired services.The constrained delegation extension allows a service to obtain service ticketsrestricted to a list of specific services on the network once it has been presentedwith the appropriate service ticket, which may have been obtained through protocoltransition. Constrained delegation is a security-limited version of native delegation asit allows administrators the ability to restrict delegates to a specific set of services.This model also resolves the issue raised by the federation of domains acrossorganizational boundaries, both external and internal. This capability is achievedthrough the implementation of Kerberos Protocol Transition (KPT). KPT worksacross a forest of domains as long as there exists a full transitive trust betweenall participating domains. The integration of domains across these boundaries isinherently complex and scales poorly, and in some cases is not permitted due to3

Technical BriefKerberos Constrained Delegation and Protocol Transition in Smart Card PKI Architecturessecurity reasons. Thus it had previously been the case that users whose identitiesare not authenticated to a domain controller through which tickets to the desiredservice can be issued cannot access those services. Previous solutions to thisdilemma have been to deploy proxy authentication tiers, which are costly to managedue to the manual nature of mapping user identities to domain identities, and donot scale well in use.Supporting smart card PKI and federated access without exorbitant costs andadditional tiers of infrastructure can now be achieved by leveraging a constraineddelegation model and Kerberos Protocol Transition support using the F5 BIG-IP Local Traffic Manager (LTM) with the F5 Advanced Client Authentication (ACA)module.Constrained Delegation ModelMicrosoft has created a Kerberos v5 extension called S4U (Services for Users) thatcompromises two parts:S4U2Self - Allows a service to obtain a service ticket to itself on behalf of aclient. This is usually used with a client certificates. S4U2Self is the KerberosProtocol Transition extensionS4U2Proxy - Allows a service to obtain service tickets to arbitrary serviceson behalf of the user with only the user’s service ticket to itself. The servicesare constrained by the administrator. S4U2Proxy is the Kerberos ConstrainedDelegation extension.Leveraging Kerberos Protocol Transition, client machines do not need to be inthe domain and can use any browser; they are not restricted to using InternetExplorer . This is possible because the intermediary providing access to the servicesin the domain proxies the requests for the client. The beauty of Kerberos ProtocolTransition is that passwords are no longer required, which allows for the use ofsmart cards for client authentication. The intermediary as a member of the domain,transitions the client request from a non-Kerberos model (smart cards and clientcertificates) to the required Kerberos model (username, domain membership. It isthen possible to access—if authorized—services across domains regardless of theclient type and mode of authentication.In addition, the use of a constrained delegation model in conjunction with aprotocol transition implementation eliminates the need for application-specific4

Technical BriefKerberos Constrained Delegation and Protocol Transition in Smart Card PKI Architecturespasswords, as identity is proven and services subsequently authenticated based oncredentials stored within a client certificate or smart card.This type of delegation is preferable in an environment in which an ADC—orother intermediary interacting with Kerberos-based infrastructures—is leveraged.Kerberos Protocol Transition has added benefits in its ability to more easily supportfederation of cross-domain users and services, as the mapping of user credentialsoccurs only at the intermediary and does not require one-to-one mappings of everydomain to every other domain.Not only does this solution significantly reduce the costs associated with deployingan infrastructure capable of supporting smart card users across multiple domains,but it can also scale up the Active Directory infrastructure while unifying theenvironment. This unification simplifies auditing and change control, whichtranslates into operational efficiencies that reduce both time and budgetaryexpenditures.Order of OperationsThe introduction of a PKI-based authentication infrastructure can be problematic forarchitectures relying upon an ADC for load balancing and SSL offload. This is dueto the way in which the ADC interacts with the services and security infrastructure,as an intermediary that essentially becomes the “client” in the “client-server”architecture used to implement Kerberos-based infrastructures. In such scenarios,the ADC does not have access to the client’s certificate used to authenticate againstan Active Directory Kerberos service, so it cannot be authorized to automaticallyaccess applications it manages via expected mechanisms.When the BIG-IP LTM with ACA is configured to support Kerberos, it acts on behalfof the client, essentially becoming the authenticated client for services. This isaccomplished by taking advantage of Microsoft’s Kerberos extension, S4U1 (Servicesfor Users).Figure 1 on the following page shows the logical flow of the constrained gazine/cc188757.aspx15

Technical BriefKerberos Constrained Delegation and Protocol Transition in Smart Card PKI ArchitecturesAD 2CRLFigure 1: Logical flow of the Kerberos protocol transition and constrained delegation model1. T he client attempts to access service using a SSL client certificate or smart cardcredentials.2. The BIG-IP system verifies the credentials are still valid.3. T he BIG-IP system obtains a service ticket for the user (S4U2Self). It alsoobtains a service ticket for configured back-end server (S4UProxy).4. The BIG-IP system forwards the user’s service ticket to the desired service.How it WorksIn constrained delegation architectures, a virtual server on the BIG-IP system - actingas a Kerberos service principal - joins a Kerberos (Active Directory) realm. The userconnects to a BIG-IP HTTPS virtual IP address requiring a client certificate. The clientcertificate is accepted and verified against the appropriate security mechanisms. Theclient certificate is then mapped to a user name based on the Subject AlternativeName: User Principal Name field.The BIG-IP system then uses the S4U2Self Kerberos protocol extension to fetch aservice ticket for the user from the KDC (Key Distribution Center). The initial ticketis used to retrieve another service ticket to a constrained service such as MicrosoftOutlook Web Access or SharePoint . This ticket is encoded into a one-time GSS(General Security Services API, which Microsoft calls the SSPI) token, base64encoded in the “WWW-Authenticate: Negotiate” request header and passed ontothe service.6

Technical BriefKerberos Constrained Delegation and Protocol Transition in Smart Card PKI ArchitecturesBoth tickets are stored in a credential cache on disk on the BIG-IP system. Anencrypted cookie is inserted into the response with a unique pointer to the filebased credential cache. When the user revisits the site, the cookie is decrypted andthe credential cache is consulted to generate a new onetime token that is used toauthenticate the user to the desired service.Each subsequent request must have a new confounder in the token, which meansa single token cannot be reused. Each request requires that a new GSS token begenerated from the cache, although only the first generation requires invocation ofexternal KDC eFigure 2: Step-by-step flow of authentication on the first request made by a user in a Kerberosconstrained delegation architecture.1. A request for a service is made via an SSL-enabled connection to the BIG-IPsystem. An iRule intercepts the client certificate.2. The ACA module verifies the client certificate is valid.3. The ACA module extracts Service Principal Name.4. T he User Principal Name and a service ticket to the BIG-IP system are passed tothe KDC. The user’s service ticket is returned to the BIG-IP (S4U2Self).5. The service ticket is placed in a credential cache file.6. T he service ticket is encoded and then sent to the requested service in the HTTPheaders.7. A long with the response from the service, a cookie with the encrypted credentialcache name is returned to the client.7