An Authentication Functional Layering Model July 2003 Internet Draft R. Moskowitz Document: draft-moskowitz-eap-auth-model- ICSAlabs 00.txt Expires: January 2004 August 2003 An Authentication Functional Layering Model Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract There is considerable confusion surrounding authentication styles and the nature of the resulting trust. This paper is an attempt to develop categories of authentication methods and present examples of each. In so doing, it develops an Authentication Functional Layering Model. It will look at the components of authentication, the flows, channels, algorithms, and entities. The taxonomy presented here is new; it has been created to facilitate discussion and understanding. Only two-party authentications are presented here. Conventions used in this document Moskowitz Expires - April 2003 [Page 1] An Authentication Functional Layering Model July 2003 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction...................................................2 2. The Authentication Model.......................................2 3. Authentication flows...........................................3 3.1 Unidirectional versus Bi-directional.......................4 4. Establishing Identities........................................5 5. Nature of Cryptographic Bindings...............................5 5.1 Examples of Bindings.......................................6 6. Using bindings in an authentication algorithm..................6 6.1 Examples of an authentication algorithm....................6 7. Authentication Channels........................................7 8. What is Mutual Authentication?.................................7 9. Security Associations..........................................9 10. Applying the 4 layer Authentication Model.....................9 11. SUMMARY......................................................10 IANA Considerations..............................................10 Security Considerations..........................................10 APPENDIX A û Layers Summary......................................10 References.......................................................11 Acknowledgments..................................................11 Author's Addresses...............................................11 1. Introduction Authentication processes have grown in an environment of need, and none have been architected with forethought to a classification of the components of authentication. Most authentication processes are monolithic. A number of them support at least a few authentication algorithms and/or identity bindings. Only now, with IEEE 802.1X and EAP is there intent to design a process of clearly delineated authentication components. This paper provides a clear model for the layers within authentication and describes the main attributes of each layer. It should make it possible to develop authentication systems that meet the policies and usage required. This is uniquely different from proving the assertions in an authentication system. 2. The Authentication Model Moskowitz Expires - April 2003 [Page 2] An Authentication Functional Layering Model July 2003 Authentication exists to establish trust between two parties, or authentication entities. These entities consist of an identity and a key. Authentication is established by performing a cryptographic operation on the parties' identities and keys. The cryptographic operation, or authentication algorithm, establishes the nature of the trust between the parties. A network transport, or authentication flow provides the connection between the parties for the authentication algorithm. Some authentication flows support a standardized authentication control mechanism, or channel, to simplify the support for multiple algorithms. The model can be represented graphically as follows: +------------------------------------------------------------------+ | Ident & Key | Ident & Key | Ident & Key | Ident & Key | +------------------------------------------------------------------+ | Auth Algorithm | Auth Algorithm | Auth Algorithm | +------------------------------------------------------------------+ | Authentication Channel [optional] | +------------------------------------------------------------------+ | Authentication Flow | +------------------------------------------------------------------+ Fig 1. The layers of Authentication In most authentication systems the layers are tightly coupled and there is no channel provided. Actually, it is the advent of an authentication channel that is making it possible to loosely couple the layers and provide for a wide spectrum of authentication solutions. In the layered model, not every combination is viable. The layered model will provide the framework for follow-on work to classify various combinations of flows, channels, algorithms and entities and the trust model they provide. 3. Authentication flows The authentication flow is the actual mechanism that moves the authentication information between the two parties. A flow is a protocol that is manifested at some layer of the ISO communication model. There are three groupings of authentication flows: unidirectional, bi-directional, and coupled unidirectional. In unidirectional there is one party that must always initiate the authentication. In bi- directional although one party always initiates the authentication, there is no pre-determined role of initiator and responder, and the roles can reverse at any time. There is a clear distinction between unidirectional and bi-directional authentication. In unidirectional, there are unique state machines for the Initiator Moskowitz Expires - April 2003 [Page 3] An Authentication Functional Layering Model July 2003 and the Responder. In bi-directional, there is one state machine that can either be the authentication initiator or responder. This single state machine handles direction reversal and race conditions (when both parties initiate or both try to force being the responder). Coupled unidirectional is a situation where there are two unidirectional flows that have to complete before either flow is considered done. Tight coupling creates an environment much like bi- directional authentication and handles the race condition by ignoring it. It does not handle direction reversals, expecting each party to fully assume both Initiating and Responding roles. Examples of unidirectional authentication protocols include IEEE 802.1x, and TLS. Examples of bi-directional authentication include IKE and HIP. IEEE 802.1aa is used in coupled unidirectional flows for IEEE 802.11i AdHoc authentication. 3.1 Unidirectional versus Bi-directional Even though unidirectional flows are decidedly originator biased, they can be implemented such that either party can be the Initiator or the Responder. Doing so produces a coupled unidirectional flow. This is not as effective an architecture as a bi-directional flow, but within some situations it can be made to work as in the use of IEEE 802.1x for IEEE 802.11 AdHoc authentication. Using unidirectional authentication in this manner requires a separate solution to role reversal and race condition handling. The Initiator state machine tends to be simpler than either the Responder or bi-directional machines. This small size may make unidirectional authentication an attractive approach in small computing systems. There is an important consideration in running two unidirectional flows, each in the opposite direction. Are the flows truly coupled? That is, do they both have to complete successfully for the authentication to be successful? If there is no fate sharing with the two flows, then they are nothing more than two unidirectional flows. A separate state machine running at some higher level as in the case with IEEE 802.11i may provide the desired fate sharing. A bi-directional flow should handle role-reversal. Role-reversal is where one party always needs to be the initiator or responder in the flow. An example of role-reversal is if a bi-directional flow was used for bridge trunk authentication and the trunk is between a Provider and a Subscriber bridge (IEEE 802.1ad). Either party may force the direction change in the flow. Thus role-reversal allows for support of unidirectional operation within a bi-directional flow. When both parties need to take the same role, a deadlocked condition is the result and the flow should terminate gracefully. Moskowitz Expires - April 2003 [Page 4] An Authentication Functional Layering Model July 2003 Bi-directional flows also handle race conditions that can occur by simultaneous flow initiation by each party or as a result of a role- reversal race. The flow will either resolve the race condition, allowing one party to proceed as the initiator or gracefully terminate the flow. Role-reversal and race condition handling, as well as the single state machine are attractive features of bi- directional flows. 4. Establishing Identities Authentication is all about validating the identity of one or both parties in a conversation or session. In a trusting world, a party announcing its identity to the other party in the conversation can accomplish the authentication. Such an approach is accepted as inadequate in most data communication sessions. This is due to the lack of "out of band" verification information like facial recognition or situational information. In data communications the equivalent of facial recognition could be a MAC or IP address, and situational information could be a CAT5 or fiber cable. All of these data items are generally not trusted anymore as identity verification information. Thus in data communications sessions, identification identities are established by 'binding' them to a cryptographic operation. The use of cryptography in identity binding can fall into two categories, symmetric and asymmetric cryptographic bindings. In symmetric binding, the two parties have a prior established secret that is used in a cryptographic operation to bind the identity to the party. Classic passwords logins are NOT an example of symmetric bindings as no cryptographic operation is performed with them and the identity; they are only a second-level identity, thus no more trustworthy than a MAC address or a piece of CAT5 cable. In asymmetric binding, the party wishing to be identified performs a cryptographic operation to bind its identity to its private key in a manner that the other party can verify the identity with a previously obtained pubic key for the first party. 5. Nature of Cryptographic Bindings There are two approaches to bindings. A weak binding only involves a cryptographic operation to establish that the party has the symmetric key or the private asymmetric key. EAP-SecureID (EAP method 15) is an example of a weak binding. A strong binding includes the identity within the cryptographic operation so there is no possibility of spoofing the identity. The strong binding concept can be used in a symmetric keyed operation to bind both partiesÆ identities to a single key. Moskowitz Expires - April 2003 [Page 5] An Authentication Functional Layering Model July 2003 5.1 Examples of Bindings Name to Symmetric key A party has a name and a symmetric key. The name and key are shared with the other party for authentication to that party. The key is used to bind the name to the other party in the authentication flow. Two names to a Symmetric key Each party has a name, but there is a single symmetric key. The names are shared with the other party (along with the shared key) for that authentication to that party. The key is used to bind BOTH parties name in the authentication flow. Name to Asymmetric key A party has a name and an asymmetric key pair. The public value is shared with the other party for authentication to that party. The private value is used to bind the name to the other party in the authentication flow. 6. Using bindings in an authentication algorithm The authentication algorithm itself establishes the identity proofs desired by the parties in the authentication. It takes advantage of the underlying authentication flow and the Identity/Key bindings. A well-designed algorithm will maximize the trust for each party. The authentication algorithm will take one or two identity to key bindings and combine them in a manner to create the desired trust between the parties. 6.1 Examples of an authentication algorithm Single Identity with key This algorithm establishes one party's identity to the other party. Depending on how the key is distributed and managed it may provide the key owner with assurance of the other party. TLS without a client certificate, MSCHAPv2, and EAP-MD5 are all examples of this class of algorithm. Two Identities with a single key Depending on how the key is distributed and managed this process can uniquely identify each party to the other. Both identities are exchanged and protected by the single key. CMP's PKIprotection with Moskowitz Expires - April 2003 [Page 6] An Authentication Functional Layering Model July 2003 a shared secret (RFC 2510) and IKE with pre-shared secret use this class of algorithm. Two Identities with keys in a nested algorithm This is a two step algorithm. First an exchange establishes one party's identity to the other party. Then the reverse is done within a channel protected by the first exchange. This is common in many uses of TLS, where a weak authentication is protected by TLS. PEAP and TTLS are specific examples of this class of algorithm. Two Identities with keys IKE with certificates, HIP, and TLS with client certificates are examples of this class of algorithm. Within a single exchange, both identities and keys are exchanged. 7. Authentication Channels It is frequently desirable to support multiple authentication algorithms within a class of authentication flows. To this end, any authentication control mechanisms can be standardized within a common channel. EAP (Extensible Authentication Protocol) is the most prevalent authentication channel in use. It is used over both PPP and IEEE 802.1X and it supports a large collection of authentication algorithms. The commonality provided by the channel approach to authentication control helps further the development and use of good authentication algorithms in many environments. 8. What is Mutual Authentication? The term 'Mutual Authentication' has been used in IEEE 802 and IETF documents to define where the parties authenticate to each other within a single authentication process. Mutual authentication is normally seen as two separate identity bindings within one authentication algorithm, but EAP methods like AKA claim mutual authentication with a single identity binding based on joint state held by both parties. IKE with pre-shared key also produces a mutual authentication within its single exchange. Mutuality in a single authentication process can be achieved in many ways with different assumptions on trust. As such it is valuable to define different terminology here. In fact the use of æMutualÆ in this context is problematic as a single flow, consisting of 2 nested authentication algorithms, can be attacked to the detriment of the authenticating parties as with PEAP/MSCHAPv2. Moskowitz Expires - April 2003 [Page 7] An Authentication Functional Layering Model July 2003 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? To resolve these issues, it is best to 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. It is appropriate to delineate the requirement of mutual authentication for a system, like in IEEE 802.11. Describing an authentication algorithm as mutual or not mutual may be acceptable in some instances, in others instances is too general a classification. To that end there are three 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. . Does each party performs a unique identity/key proof of the other party The latter case can best be described as: Bilateral authentication Bilateral authentication goes beyond mutuality to a firm assertion of the relation of the authentication validation of the two parties. Examples of Bilateral authentication algorithms are those based on exchanging the x.509 certificates of the two parties and nested algorithms like PEAP/MSCHAP. The following terminology would be appropriate to describe a particular mutual authentication algorithm typified by the first two cases. Explicit, Secured Identity Authentication Implicit, Secured Identity Authentication Explicit, Unsecured Identity Authentication Moskowitz Expires - April 2003 [Page 8] An Authentication Functional Layering Model July 2003 Implicit, Unsecured Identity Authentication The secured identity term only applies when the identity is protected with that identityÆs key, not when it is delivered with the key within a tunnel established by the other identity. In Explicit, Unsecured Authentication, at least one of the identities is not so protected. Explicit and secured identities would be the strongest class of algorithm, but in some risk models implicit and/or unsecured identities may be adequate. AKA is an example of an Implicit, Secured Identity Authentication. 9. Security Associations A security association (SA) is a set of policy and key(s) used to protect information. As such, the successful authentication creates a unique SA for the two parties. In fact each new authentication creates a new, unique, SA. SAs are named, at least within the party. In some cases, naming is easy where an SA identity is included in the authentication process or exchange. In other cases an artificial label is needed for the SA. A common practice is to create the label by hashing something unique from the exchange (like the generated session key) along with the partiesÆ identities and some text string. 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. The SA name may be used as an index into a table of active SAs. The SA name may be used as a hint in a protocol to an existing authentication. An SA can be bi-directional as in IEEE 802.11i or simplex as in IPsec. In the case of IPsec, IKE creates both SAs in the single exchange. The importance of distinction of bi-directional or unidirectional SAs is the keying material. Each SA has its own keying material. So in bi-directional, the same keying material has to be used for both directions whereas in unidirectional, there is can be uniquely created keying material to use in each direction. 10. Applying the 4 layer Authentication Model Previously all development of authentication systems were empirical, that is no attempt was made to analyze the components of an authentication system and how they would apply to the particular situation. Now that we have a 4 layer authentication model, it is valuable to hold all new work up to this standard. Moskowitz Expires - April 2003 [Page 9] An Authentication Functional Layering Model July 2003 11. SUMMARY There are three components that make up our authentication systems: the flows, the exchanges or processes, and the Identity/key bindings. There are alternatives for each of these, allowing for many different combinations to make an authentication system. There is no one right authentication system, though there are systems that are mismatched to the environment where they are used. IANA Considerations There are no IANA considerations. Security Considerations This paper describes the functional layers in Authentication Protocols. The purpose is to present a clear functional model for authentication so that better authentication technologies will be designed. APPENDIX A û Layers Summary Identity & Key Symmetric Name to symmetric key Two names to one symmetric key Asymmetric Name to asymmetric key Authentication Algorithm Single identity with key establish one partyÆs identity to another party Two identities with a single key establish both parties' identities to the other party in one keyed operation Two identities with two keys in a nested algorithm trust between two parties in two operations second key protected by first key in second operation Two identities with two keys trust between two parties in one operation 'Mutual' modifier Explicit, Secured Identity Implicit, Secured Identity Explicit, Unsecured Identity Implicit, Unsecured Identity Authentication Channel EAP Authentication Flow Moskowitz Expires - April 2003 [Page 10] An Authentication Functional Layering Model July 2003 Unidirectional One party always the initiator. Separate state machines for initiator and responder Bi-directional One party always initiates, but no predefined initiator Same state machine running on initiator and responder Coupled Unidirectional Two unidirectional flows must complete before flow is complete Both entities take on initiator and responder role during flows Both initiator and responder state machines running on each party References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Acknowledgments This document is the result of work in the IEEE 802.1 LinkSec Study Group. Author's Addresses Robert Moskowitz ICSAlabs, A Divison of TruSecure Corporation 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA Email: rgm@icsalabs.com Moskowitz Expires - April 2003 [Page 11]