Strong Authentication - Open Source

Editor's Notes

• #16: [Bob]
• #17: [Bob]
• #18: [Bob]
• #19: [Bob]
• #20: [Bob]
• #26: [Siddharth] [sv] updated based on current status. This picture shows the work items that OATH plans to deliver in 2006. Each work item is discussed in detail in a future slide.
• #27: Client OTP API – start TFG meeting, and work on it VALID spec – discuss in TFG for update
• #33: [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.
• #35: [Stu, #5]
• #39: [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
• #43: [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?
• #46: [Stu, #8]
• #47: [Stu, #8]
• #48: [Stu, #8]
• #50: 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
• #53: [Bob]
• #54: [Bob]