Security Analysis of Webbased Identity Federation Apurva Kumar

Security Analysis of Web-based Identity Federation Apurva Kumar IBM Research – India deeper

Context Analyzing security of web-based ‘transaction protocols’ presents new challenges. These protocols are characterized by: • User interacting with multiple service providers using a browser. • Trust between service providers. • Usage of well-known mechanisms like SSL/TLS. Examples include: web single sign-on, identity linking, third party delegation. In this paper, we focus on web based federation workflow used to link user accounts across domains. . 2 © Copyright IBM Corporation 2011

Challenges Techniques for analyzing cryptographic protocols need to be adapted for the web: • Support for principals without identifying keys. • Support for principal without global identities • Support for reasoning about user actions. • Need to provide primitives for standard mechanisms like SSL/TLS. • Need to support attacks specific to browser-based communication, e. g. CSRF. Why Dolev-Yao model is not ideally suited for web protocols • web protocol analysis can be greatly simplified using a much more restrictive model designed for secure (SSL/TLS) communication. • inducing an honest principal into unintentionally sending messages (including secrets) to a server chosen by the attacker, manipulating redirection URLs etc. 3 © Copyright IBM Corporation 2011

Two contrasting styles Inference Construction: Use inference in specialized logics to reason about belief established by a protocol. • Advantages: Efficiently computable formulations, High abstraction level, establish what a protocol achieves. • Drawbacks: Difficult to analyze protocols vulnerable to certain types of active attacks. Do not automatically generate attack traces. Examples: BAN logic [BAN], [AT], [GNY], [AUTLOG], [SETHEO], [EVES] Attack Construction: Construct attacks by modeling an intruder and algebraic properties of the messages being transmitted. Use model checkers to find flaws. • Advantages: More rigorous and cover wider range of attacks. Generate counterexamples/attack traces. • Drawbacks: State-space explosion problem. Complex intruder model. Examples: [DOL], [LOW], [STRAND], [AVISPA], [PROVERIF], [SCYTHER]. 4 © Copyright IBM Corporation 2011

Motivation for Hybrid Approach In the absence of identifying keys and global identities, users are identified by actions they have recently performed. Secrets are used to associate actions with users. Establishing security of web protocols involves two key elements: • Establishing agreement between service providers about context of the transaction. This can be achieved using a BAN style belief analysis. • Ensuring that tokens identifying users cannot be stolen or misused. Model checking approaches have been extensively used to study secrecy property 5 © Copyright IBM Corporation 2011

Overview of Hybrid Approach In the first stage of analysis, we use an extension of BAN in which some common web mechanisms have been formalized. For the second stage, we use a generic model for web protocols using Alloy – a SAT based model analysis tool – to analyze secrecy. Conclusions from belief analysis are used to further constrain the protocol model. Results in simplifications that drastically reduce the search-space needed to be explored by the model-checker. 6 © Copyright IBM Corporation 2011

Overview of Hybrid Approach Protocol Spec Idealization BAN fomulae Forward chaining using BAN logic. Correspondence about session and token parameters. Ignore terms that represent neither secrets nor nonces. Counter Example 7 Retain only those messages that require possession of keys that are not public. Alloy Analyzer Goal Spec Alloy model incorporating results of BAN analysis. Simplified Spec General Protocol Model in Alloy © Copyright IBM Corporation 2011

Inference Rules: BAN Operators Believes | , Sees , |~ Says, |=> Controls Message Origin Nonce Verification Jurisdiction Rule 8 8 © Copyright IBM Corporation 2011

New Inference Rules § Rules to associate actions with users. 9 9 © Copyright IBM Corporation 2011

Goals for Web Protocols Establishing agreement about tokens identifying actions. • Web protocols use tokens to communicate actions across domains. • A token is associated with parameters representing the action as well as the context in which the action was performed. • Agreement about token between service providers. • Agreement about service provider end-points. Associating user instances with actions. • Establishing at a service provider that an action has been performed by an identified user. • Adversary model should take into account browser-based attacks. 10 © Copyright IBM Corporation 2011

Alloy Based Web Protocol Model Principals: Server and User with honest sub-classes HServer and HUser Messages: Set of cookies, set of tokens, sender, receiver, redirect URL. Protocol trace: sequence of messages. Examples of constraints on messages and traces. • A message from an honest user to a server must include all cookies shared previously by server Constraint A • Correct handling of an HTTP redirect by an honest user (Constraint B). A B 11 © Copyright IBM Corporation 2011

The Single Sign-On Workflow 12 © Copyright IBM Corporation 2011

The Account Linking Workflow 13 © Copyright IBM Corporation 2011

Attack on Account Linking Workflow 14 © Copyright IBM Corporation 2011

Conclusions A novel hybrid strategy for analysis of web protocols. A framework for reasoning about user actions. Demonstration of the approach though an extremely important cross-domain ID management workflow. We identify insecurity in the account linking workflow. . • The issue has gone unnoticed in previous SAML analyses. • Shows that definition of authentication can be considerably different when the same protocol is used for different goals. We propose fix for the workflow and discuss implementation in leading web protocols: SAML and Open. ID. 15 © Copyright IBM Corporation 2011