Cartes Asia Dem 2010 V2


Published on

Presentation from Initiative for Open Authentication at Cartes Asia in March 2010

  • If my dear you want to know about our company’s OTP Token, contact me at once, thanks:
    +86-135 1099 9024
    Are you sure you want to  Yes  No
    Your message goes here
  • Cooperate with OTP Tokens, please contact me:;
    +86-135 1099 9024
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • [Bob]
  • [Bob]
  • [Bob]
  • [Bob]
  • [Bob]
  • [Siddharth] [ Talk about the 4 focus areas viz. Client Framework Validation Framework Provisioning Framework Common Data models] This slide provides a high level view of the OATH reference architecture. Client Framework: The client framework enables a range of authentication methods, tokens, and protocols to be supported when deploying strong authentication across an enterprise or service provider infrastructure. The client framework allows for standards-based integration of multiple forms of strong authentication implemented using either existing or new authentication token technologies, and communicated using standard authentication protocols. Provisioning Framework: The provisioning and management module is responsible for provisioning and managing the entire lifecycle of software modules and/or security credentials to an authentication device. The purpose of this process is to bring the device from a “ clean state ” to a state where it can be used as an authentication token e.g. provisioning of certificates, or provisioning of an instance of an OTP token in software or a connected token. The goal of the Provisioning architecture is to accommodate secure and reliable delivery of software and/or security credentials to any client device, using standards-based provisioning protocols or programmatic interfaces. Validation Framework : The validation framework is responsible for validation of the different types of authentication credentials. Various applications that need authentication (such as VPN gateways or web applications) communicate with the validation module using standard validation protocols to authenticate the end-user. The goal of the Validation framework is to enable vendors to write custom validation modules and enables enterprises to deploy multiple types of authenticators in the same infrastructure. User Store: User store is responsible for storing all end-user profile information. This will include information such as a unique user identifier (username); profile information such as address, first name, last name, etc.; application specific attributes; and finally it may also store some authentication information such as password, token information, etc. User store is typically an LDAP directory or in some cases it could be a database.
  • [Stu, #5]
  • [Siddharth] Question (before showing the picture) – How many folks in the audience have multiple authentication technologies deployed in their infrastructure??? The OATH Validation framework is an architecture that will enable vendors to write custom validation modules and enables enterprises to deploy multiple types of authenticators in the same infrastructure. Additionally, the validation framework will enable organizations to deploy multiple protocol handlers such as RADIUS, OCSP, WS-Security, etc. The OATH validation framework will benefit the organization that deploys strong authentication by enabling use of multiple authentication methods in the same infrastructure, thereby enabling phased rollout of strong authentication solutions across a wider set of applications and user groups. As shown in the figure above, the validation framework will consist of the following sub-modules: • Protocol Handler framework: This framework will enable deployment of multiple protocol handlers • Validation Handler framework: This framework will enable deployment of multiple validation handlers. Validation handlers: Each validation handler will support validation of a particular instance or flavor of an authentication method e.g. HOTP, RSA SecurID, etc. • Infrastructure Layer: The infrastructure layer will provide some of the common functionality that can be used by the various other components in the validation system. Salient Features • Multiple authentication methods • Multiple validation protocols • Multiple validation clients • Standardized Configuration • Framework for logging operational and audit events
  • [Bob]
  • Adoption requires fundamental shift from proprietary to open solutions Interoperable hardware and software components Built on existing technology and protocol – 90% of the work is already done Enable customers to leverage current application and network infrastructure The only way to build a more secure internet Push complexity to the cloud and increase scalability Requires collaborative effort to address this challenge Collaboration among authentication credential providers to create an open platform for stand alone and embedded credentials Endorsed and supported by leading network and application product providers Examples of this again – PC v Mac, Token Ring v IP, more examples here
  • [Bob]
  • [Stu, Q3] Architecture purpose: technical framework and roadmap for creating a set interoperable modules for strong auth. Audience: architects and IT managers, for use by both vendor community and user organizations looking to deploy auth solutions. Questions to ask - So, how many people have heard or actually downloaded the OATH reference architecture?
  • [Stu, #8]
  • [Stu, #8]
  • [Stu, #8]
  • Cartes Asia Dem 2010 V2

    1. 1. Initiative for Open Authentication Interoperability without Sacrificing Security Donald E. Malloy, Jr. NagraID Security Cartes Asia March 18 th 2010
    2. 2. The Open Authentication Reference Architecture (OATH) initiative is a group of companies working together to help drive the adoption of open strong authentication technology across all networks. Q1
    3. 3. Why the need for OATH <ul><li>Fraud continues to grow </li></ul><ul><li>10 Million Americans were victims of fraud last year </li></ul><ul><li>This amounts to over $300M of online fraud last year alone </li></ul><ul><li>Hacking into web sites and stealing passwords continue to be a main focus of fraudsters </li></ul>
    4. 4. Issues Facing IT Managers
    5. 5. OATH History <ul><li>Created 5 years ago to provide open source strong authentication. </li></ul><ul><li>It is an industry-wide collaboration that.. </li></ul><ul><li>Leverages existing standards and creates an open reference architecture for strong authentication which users and service providers can rely upon, and leverage to interoperate. </li></ul><ul><li>Reduces the cost and complexity of adopting strong authentication solutions. </li></ul>Q1
    6. 6. OATH : Background <ul><li>Networked entities face three major challenges today. </li></ul><ul><li>Theft of or unauthorized access to confidential data. </li></ul><ul><li>The inability to share data over a network without an increased security risk limits organizations. </li></ul><ul><li>The lack of a viable single sign-on framework inhibits the growth of electronic commerce and networked operations. </li></ul>Q1
    7. 7. OATH : Justification <ul><li>The Initiative for Open Authentication (OATH) addresses these challenges with standard, open technology that is available to all. </li></ul><ul><li>OATH is taking an all-encompassing approach, delivering solutions that allow for strong authentication of all users on all devices, across all networks. </li></ul>Q1
    8. 8. OATH Membership (Partial) Q2
    9. 9. Standardized Authentication Algorithms HOTP OCRA T-HOTP <ul><li>Open and royalty free specifications </li></ul><ul><li>Proven security: reviewed by industry experts </li></ul><ul><li>Choice: one size does not fit all </li></ul><ul><li>Event-based OTP </li></ul><ul><li>Based on HMAC, SHA-1 </li></ul><ul><li>IETF RFC 4226 </li></ul><ul><li>Based on HOTP </li></ul><ul><li>Challenge-response authentication </li></ul><ul><li>Short digital signatures </li></ul><ul><li>Time-based HOTP </li></ul>
    10. 10. Token Innovation and Choice Multi-Function Token (OTP & USB Smart Card) Soft OTP Token OTP Token OTP embedded in credit card OTP soft token on mobile phones HOTP applets on SIM cards and smart-cards OTP embedded in flash devices HOTP 50+ shipping products Q11
    11. 11. OATH Reference Architecture: Establishing ‘common ground’ <ul><ul><li>Sets the technical vision for OATH </li></ul></ul><ul><ul><li>4 guiding principles </li></ul></ul><ul><ul><ul><li>Open and royalty-free specifications </li></ul></ul></ul><ul><ul><ul><li>Device Innovation & embedding </li></ul></ul></ul><ul><ul><ul><li>Native Platform support </li></ul></ul></ul><ul><ul><ul><li>Interoperable modules </li></ul></ul></ul><ul><ul><li>v2.0 </li></ul></ul><ul><ul><ul><li>Risk based authentication </li></ul></ul></ul><ul><ul><ul><li>Authentication and Identity Sharing </li></ul></ul></ul>Q4
    12. 12. OATH Authentication Framework 2.0 Provisioning Protocol Authentication Protocols Authentication Methods Token Interface Validation Protocols Client Framework Provisioning Framework Validation Framework User Store Token Store HOTP Challenge/ Response Certificate Applications (VPN, Web Application, Etc.) Validation Services Provisioning Service Credential Issuer(s) Time Based Bulk Provisioning Protocols Risk Evaluation & Sharing Risk Interface Q4 Authentication and Identity Sharing Models Authentication Token Client Applications
    13. 13. Credential Provisioning <ul><li>Token manufacturer offline model </li></ul><ul><li>Portable Symmetric Key Container standard format (PSKC Internet-Draft) </li></ul><ul><li>Dynamic real-time model </li></ul><ul><li>Dynamic Symmetric Key Provisioning Protocol (DSKPP Internet-Draft) </li></ul><ul><li>OTA provisioning to mobile devices, or online to PC/USB </li></ul><ul><li>IETF KeyProv WG </li></ul><ul><li>Current RFC submissions </li></ul>Q5
    14. 14. OATH Roadmap CHOICE of AUTHENTICATION METHODS APPLICATION INTEGRATION & ADOPTION <ul><li>HOTP </li></ul><ul><li>OCRA </li></ul><ul><li>T-HOTP </li></ul>CREDENTIAL PROVISIONING & LIFECYCLE <ul><li>PSKC </li></ul><ul><li>DSKPP </li></ul><ul><li>Certification </li></ul><ul><li>program </li></ul><ul><li>WS Validation </li></ul><ul><li>Auth & Identity </li></ul><ul><li>Sharing work </li></ul>
    15. 15. Objectives <ul><li>Understand the full lifecycle support needed for strong authentication integration </li></ul><ul><li>Learn different approaches to supporting strong authentication in your applications </li></ul><ul><li>Take away with the best practices for enabling strong authentication in applications </li></ul>
    16. 16. Certification Program <ul><li>The OATH Certification Program </li></ul><ul><ul><li>Intended to provide assurance to customers that products implementing OATH standards and technologies will function as expected and interoperate with each other. </li></ul></ul><ul><ul><li>Enable customers to deploy ‘best of breed’ solutions consisting of various OATH ‘certified’ authentication devices such as tokens and servers from different providers. </li></ul></ul><ul><li>Introduced 2 Draft Certification Profiles at RSA </li></ul><ul><ul><li>Tokens – HOTP Standalone Client </li></ul></ul><ul><ul><li>Servers – HOTP Validation Server </li></ul></ul><ul><li>10 Additional Profiles to be introduced throughout the year </li></ul>
    17. 17. One Time Password Devices <ul><ul><li>Initial Applications </li></ul></ul><ul><ul><ul><li>Financial – Most Governments have demanded more than static passwords </li></ul></ul></ul><ul><ul><ul><li>Online Authentication </li></ul></ul></ul><ul><ul><ul><li>Physical Access </li></ul></ul></ul><ul><ul><li>Subsequent Applications </li></ul></ul><ul><ul><ul><li>Contactless Payment </li></ul></ul></ul><ul><ul><ul><li>Secure Network Access </li></ul></ul></ul><ul><ul><ul><li>E-wallet application </li></ul></ul></ul>
    18. 18. Layered Approach to Security <ul><ul><li>Applications </li></ul></ul><ul><ul><ul><li>OTP </li></ul></ul></ul><ul><ul><ul><li>Pin Activation </li></ul></ul></ul><ul><ul><ul><li>Challenge/Response </li></ul></ul></ul><ul><ul><ul><li>Physical Access </li></ul></ul></ul><ul><ul><ul><li>Contactless Payment </li></ul></ul></ul><ul><ul><ul><li>Secure Network Access </li></ul></ul></ul><ul><ul><li>Cards will be used for single sign on and multi applications </li></ul></ul>
    19. 19. Typical Application Scenario <ul><li>Transaction authentication & Signing </li></ul><ul><li>Log on to Bank’s web site </li></ul><ul><li>Give user name and password </li></ul><ul><li>Bank sends a challenge number used to create pin </li></ul><ul><li>User enters number into card and new secure pass code is generated </li></ul><ul><li>User then submits this new number to the bank’s web site </li></ul><ul><li>Transaction is then authorized by the bank </li></ul>
    20. 20. Recommended Validation Framework
    21. 21. Authentication Integration Architecture <ul><li>Direct authentication integration over standard protocol </li></ul><ul><li>Plugin based authentication integration </li></ul>
    22. 22. Plugin Based <ul><li>Enable two-factor authentication in your existing third party authentication server for user password </li></ul><ul><ul><li>Your application codes don’t need to change </li></ul></ul><ul><ul><li>Out of box strong authentication support in your existing third party authentication server </li></ul></ul><ul><ul><ul><li>Integration Connectors available from authentication solution vendors, e.g. RSA, VeriSign </li></ul></ul></ul><ul><ul><ul><ul><li>e.g. CDAS plugin for IBM Tivoli Access Manager </li></ul></ul></ul></ul><ul><ul><li>Develop your customized plugin for your existing third party authentication server </li></ul></ul>
    23. 23. Open Source Implementation <ul><li>RADIUS Client </li></ul><ul><ul><li>Java </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul><ul><ul><li>.NET </li></ul></ul><ul><ul><li>C/C++ </li></ul></ul><ul><li>Authentication Server with OTP Support </li></ul><ul><ul><li>Radius server </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul><ul><ul><ul><li>Need to add OTP auth plugin </li></ul></ul></ul><ul><ul><li>Triplesec </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul>
    24. 24. References and Resources <ul><li>Initiative for Open AuTHentication (OATH) </li></ul><ul><ul><li> </li></ul></ul><ul><li>HOTP: An HMAC-Based One-Time Password Algorithm – RFC 4226 </li></ul><ul><ul><li> </li></ul></ul><ul><li>OATH Reference Architecture </li></ul><ul><ul><li> </li></ul></ul><ul><li>Other draft specifications </li></ul><ul><ul><li> </li></ul></ul>
    25. 25. How to Get Involved <ul><li>Visit the OATH website </li></ul><ul><ul><li>Download Reference Architecture v2 </li></ul></ul><ul><ul><li>Download and review draft specifications </li></ul></ul><ul><li>Engage - contribute ideas, suggestions </li></ul><ul><ul><li>Review public draft specifications </li></ul></ul><ul><ul><li>Get involved in developing specifications </li></ul></ul><ul><li>Become a member! </li></ul><ul><ul><li>3 levels - Coordinating, Contributing, Adopting </li></ul></ul><ul><ul><li>Become an active participant </li></ul></ul>
    26. 26. Driving a fundamental shift from proprietary to open solutions! <ul><li>An industry-wide problem mandates an industry wide solution </li></ul><ul><ul><li>Strong Authentication to stop identity theft across all the networks </li></ul></ul><ul><li>A reference architecture based on open standards </li></ul><ul><ul><li>Foster innovation & lower cost </li></ul></ul><ul><ul><li>Drive wider deployment across users and networks </li></ul></ul><ul><li>Minimal bureaucracy to get the work done! </li></ul>Summary
    27. 27. Questions & Answers Thank You!
    28. 28. <ul><li>Backup Slides… </li></ul>
    29. 29. OATH Timeline A humble beginning! Common OTP Algorithm HOTP Steady Progress … <ul><li>OATH Reference Architecture 1.0 </li></ul><ul><li>New HOTP devices - Membership expansion </li></ul><ul><li>- Public Roadmap release </li></ul><ul><li>Roadmap Advances </li></ul><ul><li>Portable Symmetric Key Container </li></ul><ul><li>Challenge-Response Mutual Authentication </li></ul><ul><li>Provisioning Protocol </li></ul><ul><li>- Risk-based Authentication </li></ul><ul><li>Authentication Sharing </li></ul><ul><li>IETF KeyProv </li></ul><ul><li>Interop Demo </li></ul>OATH Reference Architecture 2.0 Q3
    30. 30. Risk Based Authentication Architecture <ul><ul><li>Risk-based authentication </li></ul></ul><ul><ul><ul><li>Convenient authentication for low risk transactions </li></ul></ul></ul><ul><ul><ul><li>Stronger authentication for higher risk transactions </li></ul></ul></ul><ul><ul><li>OATH will define standardized interfaces </li></ul></ul><ul><ul><ul><li>Risk Evaluation </li></ul></ul></ul><ul><ul><ul><li>Sharing fraud information (ThraudReport) </li></ul></ul></ul>Q7
    31. 31. Authentication and Identity Sharing <ul><li>Promotes use of single credential across applications </li></ul><ul><ul><li>Force multiplier! </li></ul></ul><ul><li>Multiple approaches </li></ul><ul><ul><li>One size does not fit all </li></ul></ul><ul><li>Models that leverage identity sharing technologies </li></ul><ul><ul><li>Liberty, SAML, OpenID, etc. </li></ul></ul><ul><li>Models to enable sharing of 2 nd factor authentication only </li></ul><ul><ul><li>Simpler liability models </li></ul></ul>
    32. 32. Authentication Sharing – Centralized Token Service model <ul><li>Token is validated centrally in the validation service </li></ul><ul><ul><li>Same token can be activated at multiple sites </li></ul></ul><ul><li>Easy integration for application web site(s). </li></ul><ul><ul><li>Can leverage OATH Validation Service work! </li></ul></ul>Q8
    33. 33. Authentication Sharing – Distributed Validation Model <ul><li>Inspired by ‘DNS’ </li></ul><ul><li>Rich set of deployment models </li></ul><ul><ul><li>Standalone system can join the network by publishing token discovery information </li></ul></ul><ul><li>There needs to be a central Token Lookup Service. </li></ul><ul><ul><li>OATH considering developing Token Lookup protocol . </li></ul></ul>Q8
    34. 34. Authentication Sharing – Credential Wallet <ul><li>Shared device </li></ul><ul><ul><li>Multiple credentials </li></ul></ul><ul><li>Credentials are dynamically provisioned onto the device. </li></ul><ul><ul><li>Leverage OATH Provisioning specifications. </li></ul></ul>Q8
    35. 35. Identity Federation & OATH <ul><li>Enables user to use same identity across website(s) </li></ul><ul><ul><li>Traditional federation (Liberty) </li></ul></ul><ul><ul><li>User-centric models (OpenID, CardSpace) </li></ul></ul><ul><li>Single Identity becomes more valuable </li></ul><ul><ul><li>Needs to protected using strong authentication </li></ul></ul>OATH: promote the user of strong authentication with these technologies!