doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 1 March 2002 An Authentication layering model Robert Moskowitz Trusecure Corporation ICSALabs

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 2 March 2002 Motivation Authentication has grown beyond a small component of security to a self-standing pillar of secure systems design –Monolithic authentication systems are being replaced by componentized systems Develop a layered model for Authentication –flows, channels, algorithms, and entities A clear taxonomy for Authentication This effort is limited to two-party Authentication

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 3 March 2002 The Authentication Model In most authentication systems these layers are not obvious –The channel is frequently not provided The advent of the channel (e.g. EAP) that makes this well defined model valuable Authentication Flow Authentication Channel [optional] Authentication Algorithm Identity & Key

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 4 March 2002 Authentication Flows Three groupings –Unidirectional, Bi-directional, Coupled unidirectional Unidirectional has two state machines –Initiator and Responder Bi-directional as a single state machine –For both the Initiator and Responder –Handles directional reversal and race conditions Coupled unidirectional –2 unidirectional that both must complete before the authentication is finished –Ignores race condition and direction reversal

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 5 March 2002 Unidirectional Versus Bi-directional Unidirectional advantageous –Clear cut Initiator Benefits from smaller Initiator state machine size Bi-directional advantageous –Single state machine –Either party may initiate –Handles race condition –Can ‘emulate’ unidirectional through role enforcement Coupled unidirectional NOT equivalent to bi- directional

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 6 March 2002 Establishing Identities Authentication’s raison d'être is establishing Identities Identities are established by a cryptographic binding Bindings can be based on Symmetric or Asymmetric cryptography

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 7 March 2002 Nature of Cryptographic Bindings Weak binding –Party has the key, but no proof of identity Strong binding –Identity is tied to key Examples of Bindings –Name to Symmetric Key –Two names to Symmetric Key –Name to Asymmetric Key

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 8 March 2002 Using bindings in an authentication algorithm Well-designed algorithm will maximize the trust for each party Examples of an authentication algorithm –Single Identity with key –Two Identities with a single key –Two Identities with keys in a nested algorithm –Two Identities with keys

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 9 March 2002 Authentication Channels An authentication algorithm muxing service Helps further the development and use of good authentication algorithms

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 10 March 2002 What is Mutual Authentication? where the parties authenticate to each other within a single authentication process An authentication process may be called ‘mutual’ and still the following issues are undefined: –Is one or both identities exchanged? –If only one identity is exchanged, is the other identity implied by knowledge of a symmetric key? –Is/are the identities exchange secure? –If two identities are securely exchanged, are they protected with one or two keys? –If two identities, is there one identity exchange, two intertwined exchanges, or two serial or parallel exchanges?

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 11 March 2002 What is Mutual Authentication? Limit the applicability of ‘Mutual Authentication’ to authentication algorithms and how they act on Identity bindings Authentication flows and channels are silent on mutuality –Mutuality is NOT established by a bi-directional or coupled unidirectional flow Appropriate to delineate the requirement of mutual authentication for a system, like in IEEE

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 12 March 2002 What is Mutual Authentication? There are two features that further typify an authentication –Are both identities explicitly included within the algorithm or is one implicit as in AKA. –Is one of the identities not bound to its key, but protected with the other party’s key.

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 13 March 2002 What is Mutual Authentication? the following terminology would be appropriate to describe a particular mutual authentication algorithm –Explicit, Secured Identity Authentication –Implicit, Secured Identity Authentication –Explicit, Unsecured Identity Authentication –Implicit, Unsecured Identity Authentication –Where Explicit means identity is included in the protocol and Secure means the identity is cryptographicly protected

doc.: IEEE /492r0-I Submission Robert Moskowitz, Trusecure/ICSALabsSlide 14 March 2002 Security Associations An SA is a set of policy and key(s) used to protect information The successful authentication creates a unique SA for the two parties Each new authentication creates a new, unique, SA The SA is used to group all the information related to the authentication so that everything can be properly protected within the party and deleted when no longer needed An SA can be bi-directional or unidirectional –One set of keying material in bi-drectional, separate keying material in unidirectional