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 OpenID.
15
© Copyright IBM Corporation 2011