ITU Workshop on “ICT Security Standardization
for Developing Countries”
(Geneva, Switzerland, 15-16 September 2014)
Step-up authentication a key enabler
of mobile on-line trust
Progress report of ITU-T and OASIS Trust Elevation work
Abbie Barbir Ph.D.,
Chair OASIS Trust Elevation TC
abarbir@live.ca
Geneva, Switzerland, 15-16 September 2014
Mobile Authentication
Talk/slides represents findings From OASIS and ITU work
Mobile going main stream
•
Adoption of mobile devices for business is on the rise
Organizations are rushing to mobile their applications
•
Mobile devices are used for providing authentication to applications
•
•
Threats to Mobile
•
•
•
•
•
•
•
•
Data exposure from lost, stolen, or returned devices
Mobile malware / Zero day attacks
Security risks from 3rd party applications
OS vulnerabilities
Network exposure (Wifi, NFC etc..)
App stores issues
Immature tools and debugging s/w
Mobile Authentication
•
Contextual based Authentication is emerging
Adoption of cloud based services continuous to grow
Biometric Authentication is on the rise
•
Using the device as a token
•
•
Geneva, Switzerland, 15-16 September 2014
2
Trends of Mobile Authentication
Emerging Needs and Capabilities
• Support of context based access
• Fine(r) access control
• Map user (including device) identity and (may be
per app) authentication credentials to SLA
• Need to understand and compare user behavior
across many devices
• Ability to categorize user access to different devices
• Be able to set access control based on degrees of
validated device identity
• Fine grain endpoint IdM
• Ability to identify, terminate and restrict access
per application/device and other factors.
Geneva, Switzerland, 15-16 September 2014
3
Challenges of Mobile Authentication
User
experience
Device
Profile
Authentication
Convenience
User
Behaviour
Profile
Risk based
polices
Possible
Fraud
Results
Risk
Analysis
Pass
Fail
Mobile App Considerations
•
Application architecture
•
Offline vs. online access
•
Storage of information on device
•
Various mobile OS
•
Device ownership: BYOD or Corp Liable
•
Challenges to SSO on Mobile
•
No standardized SSO
•
Native Mobile apps vs. Web
•
Better user experience
•
Leverage local device capabilities
•
SaaS vendor-provided apps
authenticate to SaaS backend
systems
•
Web App
•
Browsers lack access to native
device E.g. Camera,
•
Browsers tend to be
underpowered UI for small form
factor devices
Verify
Perform
Step up AuthN
Mobile app security challenges:
• Broader coverage beyond VPN needed
• Check for malicious behavior and threats
at app layer
• Continuous data monitoring and auth
OASIS Trust ElevationTC
• Defining a set of standardized protocols to elevate
trust in an electronic identity
Trust Elevation
Increasing the trust a relying party has that the online entity
accessing its resources is the (person or device) it claims to be
Reducing the risk that a relying party assumes that the online
entity accessing its resources is not the person or device it
claims to be
TC Deliverables
Deliverable One: Collect current and imminent trust elevation
methods
Deliverable Two: Analysis of collected methods
Deliverable Three: General principles and techniques to
elevate trust in a transaction
Deliverable Four: Trust Elevation Protocol and Markup
Language
Authentication Categories
• Physical Biometric
•
Browsing patterns
• immutable and unique
•
Time of access
what
•
Facial
recognition
•
Type of device
Who You
you
Trust
elevation
(step-up
Authentication):
•
Iris
Scan/Retinal
Scan
•
Used in Combination
Are
Do
•
Fingerprint
Palm
Scan/Voice
withfrom
other the
methods
•Biometric
Increasing the strength of trust (Auth) by adding factors
• Liveliness biometric factors
same
or different
categories
trust authentication
elevation methods
don’t
include:to
Pulse.
• It
is a big
mistake
assume thatofstrong
alwaysthat
result
when
•
CAPTCHA;
etc
share themultiple
same vulnerabilities
combining
authentication
attributes/factors.
• Location; Time of
• Behavioral
Biometric
•• Only
There
are
five
categories
of
trust
elevation
methods
access;
by combining
of different kinds (that is, different
factors) with
• based onattributes
person’s physical
behavioural
activity
patterns
• who(non-overlapping)
you are (biometrics,
attributes),
Subscriber identity
different
sets ofbehavioral
vulnerabilities
is there •a significant
increase
•
Keyboard
signature
module
(SIM)
•
what
you
know
(shared
secrets,
public
and
relationship
in resistance to
• attack
Voice and, thus, in authentication strength
• Frequency of access;
knowledge),
Context
what
• you
User
Name(devices,
and Password
• Source and endpoint
•
what
have
tokens
(UN/PW), A passphrase,
a PIN - hard, soft, OTP),
you
attributes
• what• you
typically
docombinations
(described by ITU-T x1254,identity
behavioral
Very
often used
know
with KBA
habits that
are methods.
independent of physical biometric attributes)a nd
• Knowledge Based
• the context
(location,
time, party, prior relationship, social
Authentication
(KBA)
Mostly used to provide
•
Static/Dynamic
relationship
and source).KBA
Secondary Attributes
• Elevation• can
be
within
the
classic
four
X.1254
ITU-T LoA
One Time Password (OTP)
what
• Smart card
you
• X.509 and PKI
• Rarely used alone
have
• Used in combination with
UN/PW and a PIN
6
Mobile Application Threat Model
External Services
(Can be Malicious)
Malicious user
bypassing Mobile
client
Mobile Device
Local App Storage
Local Key Chain
Mobile
App
User
Can be
Malicious
Malicious
Mobile App
Device
File System
Enterprise
Server and
Services
Spoofing Users to the Mobile App
•
Borrowed/Stolen Device
•
Other Malicious Application
Spoofing: Web Services to Mobile App
•
Borrowed Device
•
Other Malicious App
Tampering: Mobile App
•
Borrowed/Stolen Device
•
Other Malicious Application
Disclosure: Device Data Stores or Residual Data
•
Borrowed/Stolen Device
•
Malicious App Functionality
Attacks from Mobile Web Services
•
Disclosure: Mobile App to Web Service
•
Attacks from Local Network
Other Malicious App
•
Denial of Service: Mobile App
•
Elevation of Privilege: Mobile App or WS
Tackling mobile security risks
Device
•
•
•
•
Centric
MDM
Device Policy
Data Encryption
Containers
Data Centric
• Limit Data on
Device
• Traffic Encryption
• Virtualization
Application Centric
• Server Side
protection
• Development
• App Store
• Platforms
Balancing act between risk and convenience
Trust Elevation Core Model
User Accesses
Online
Resource with
identity
and/or
attribute data
(may consist
of credential)
Resource
Assesses
Trustworthiness
of Asserted
Identity
According to
Policy
Resource
Determines
Insufficient
Trustworthin
ess
rejection
Resource Engages PreviouslyDetermined Trust Elevation
Process
access resource for
the transaction
reapplication of yet
another trust elevation
cycle
9
4th Deliverable “TE” Protocol and Markup Language
What we considered so far?
•
OAuth, OpenID Connect, UMA, OATH, SAML
What we found

OAuth, OpenID and UMA are services that manage
authorization. These services may utilize Trust Elevation
before or after executing their service.

SAML can Support Step UP also

OATH is an open framework for strong authentication;
primarily focused on device credential and authentication
interfaces. It does not have a standard format for trust
elevation (or am I missing something?)
What we proposed
 Would support existing authentication and authorization
specification but will remain independent of them.
 Would ensure existing identity assertion frameworks are
supported
 Would be in XML and JSON formats
Trust Elevation Sequence
OASIS Trust Elevation Story
1. End-User accesses online resource using a device with an asserted identity
and/or attributes.
2. Device sends End-User’s identity and/or attribute data to Relying Party (RP)
3. RP requests an Identity Provider (IdP) to assess the asserted identity.
4. RP validates each and every asserted attributes, if they are available, using an
Attribute Provider (AP). The AP could be independent, part of RP or part of a
third party. RP may involve multiple APs in a single transaction to validate
various attributes.
5. RP engages LoA Assessor (LA) to assess LoA for the verified identity and/or
attributes strength.
6. RP determines if the asserted identity and attributes offer sufficient
trustworthiness. For sufficient trustworthiness, present the resource [13, 14].
For insufficient trustworthiness, follow Trust Elevation steps [7 - 12]. If there is
no opportunity to elevate trust, then reject the request [13, 14]
7. RP engages Trust-Elevation Method Determiner (MD) to determine the best
possible type of method be used for Trust Elevation. The MD is a repository of
predetermined Trust Elevation methods for transactions involving various
combinations of type of devices, RPs, IdPs, APs and LAs. The MD could be
independent, part of RP or part of a third party.
8. RP, based on feedback from MD, requests valid authentication factors through
the device. The device could provide factors with/without End-User
Intervention.
Trust Elevation Sequence - Story
9. RP requests an Identity Provider (IdP) to assess the asserted
identity.
10. RP validates each and every asserted attributes, if they are
available, using an Attribute Provider (AP). The AP could be
independent, part of RP or part of a third party. RP may
involve multiple APs in a single transaction to validate
various attributes.
11. RP engages LoA Assessor (LA) to assess LoA for the verified
identity and/or attributes strength.
12. RP determines if the asserted identity and attributes offer
sufficient trustworthiness. For sufficient trustworthiness,
present the resource . For insufficient trustworthiness, follow
Trust Elevation steps If there is no opportunity to elevate
trust, then reject the request
13. RP presents information to device
14. Device present information to End-User
Conclusions and Recommendations
Step up Authentication will play a critical role in mobile space
OASIS and ITU are working to Create a generalizable framework
for implementing non-credential-based, online authentication
best practices based on current and near-future implementations
Expands and extends options for multi-factor authentication
implementations
Mobility
It is all about App security
Application fine grain Auth N/Z for one or more Apps
Move from static to continuous Auth
Fine grain policy enforcement
Cloud … Cloud ….Cloud
Challenging but in progress
More opportunities for simplification and innovation
Geneva, Switzerland, 15-16 September 2014
14