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

© Copyright IBM Corporation 2011 Context 2 Analyzing security of web-based ‘transaction protocols’ presents new challenges. User interacting with multiple service providers using a browser. Trust between service providers. Usage of well-known mechanisms like SSL/TLS. These protocols are characterized by: 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..

© Copyright IBM Corporation 2011 Challenges 3 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. Techniques for analyzing cryptographic protocols need to be adapted for the web: 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. Why Dolev-Yao model is not ideally suited for web protocols

© Copyright IBM Corporation 2011 Two contrasting styles 4 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. Inference Construction: Use inference in specialized logics to reason about belief established by a protocol. Examples: BAN logic [BAN], [AT], [GNY], [AUTLOG], [SETHEO],[EVES] Advantages: More rigorous and cover wider range of attacks. Generate counter- examples/attack traces. Drawbacks: State-space explosion problem. Complex intruder model. Attack Construction: Construct attacks by modeling an intruder and algebraic properties of the messages being transmitted. Use model checkers to find flaws. Examples: [DOL], [LOW], [STRAND], [AVISPA], [PROVERIF], [SCYTHER].

© Copyright IBM Corporation 2011 Motivation for Hybrid Approach 5 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 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 Establishing security of web protocols involves two key elements:

© Copyright IBM Corporation 2011 Overview of Hybrid Approach 6 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.

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

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

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

© Copyright IBM Corporation 2011 Goals for Web Protocols 10 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. Establishing agreement about tokens identifying 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. Associating user instances with actions.

© Copyright IBM Corporation 2011 Alloy Based Web Protocol Model 11 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. 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). Examples of constraints on messages and traces. A B

© 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 15 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. 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 identify insecurity in the account linking workflow.. We propose fix for the workflow and discuss implementation in leading web protocols: SAML and OpenID.