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]