One document matched: draft-moskowitz-eap-auth-model-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 02:55:50 |