| Proposed resolution to Issue 180: Conversation Overview | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Wed, 29 Oct 2003 20:52:10 -0600 (CST) | |
The text of Issue 180 is enclosed below. The proposed resolution is as
follows:
Add Pasi Eronen as an author.
Replace the text of section 1.3 with the following:
1.3. Conversation Overview
Where EAP key derivation is supported, EAP authentication is
typically a component of a four phase exchange:
Discovery (phase 0)
EAP authentication (phase 1a)
Access authorization (phase 1b)
Service authentication (phase 2)
In the discovery phase (phase 0), the EAP peer and authenticator
locate each other. This may include a conversation in which
they contact each other, and then exchange some information about the
service to be provided. For example, one of the parties may
indicate its willingness to provide a service (and to perform
the EAP authenticator role), and the other party requests
access to that service (assuming the EAP peer role).
Next, the EAP peer and EAP server authenticate each other
(phase 1a) and derive a shared key (the AAA-Key). Where
a backend authentication server is present, the authenticator
forward EAP packets between the peer and backend authentication
server (EAP server). This enables deployment of new
authentication methods without requiring new code on the
authenticator.
Partially overlapping with this exchange is a second exchange
(phase 1b), between the authenticator and the backend
authentication server. In this exchange, the authenticator
and backend authentication server authenticate each other
via the AAA protocol, and the authenticator sends to the backend
authentication server information about the service requested
by the peer (in the form of AAA protocol attributes). When
phase 1a completes, the backend authentication server indicates
to the authentication whether the service is to be provided
(Accept/Reject), more detailed information on the service to
be provided (AAA authorization attributes), and keying material
(the AAA-Key) to be used in the derivation of Transient Session
Keys (TSKs).
Service authentication (phase 2) always occurs after the
completion of EAP authentication (phase 1a) and access authorization
(phase 1b). Some or all of the following features may be supported:
[1] Network selection. Where multiple networks are advertised
by an authenticator, it is necessary for the peer
to explicitly indicate its desire to connect to one or more
of the advertised networks. Since EAP does not include
explicit network selection functionality, this function
needs to be handled outside of EAP.
[2] Secure association. On wireless networks, it may be
desirable to enable "make before break" by allowing an
EAP peer to authenticate and derive keys with an EAP
server prior to its arrival at an authenticator. In
such a situation, the successful completion of EAP
authentication and key derivation does not necessarily
imply that the peer wishes to be connected to the
authenticator that it has been communicating with.
Rather, this commitment is signaled by the peer in a
separate step, as part of service authentication (phase 2).
The joining of the peer to a network is known as "association"
and where the associated packets are integrity protected
and authenticated, the exchange is known as a
"secure association".
[3] Mutual proof of possession of the AAA-Key. This demonstrates
that both the EAP peer and authenticator have been authenticated
and authorized by the AAA server. Since mutual proof of
possession is not the same as mutual authentication, the EAP peer
cannot verify authenticator assertions (including the
authenticator identity) as a result of this exchange.
[4] Secure negotiation of capabilities. During phase 2, the
peer and authenticator may exchange more service parameters (possibly
beyond those exchanged during phase 0) and protect some or all
of these parameters using the AAA-Key. By securely negotiating
session parameters, the service authentication protocol protects
against spoofing during the discovery phase and ensures that the
peer and authenticator are in agreement about how data is to be
secured.
[5] Generation of fresh transient session keys. This is typically
accomplished via the exchange of nonces, and includes generation
of both unicast and multicast (where required) session keys.
By not using the AAA-Key directly to protect data, protection is
provided against compromise of the AAA-Key. By guaranteeing
freshness of TSKs it is assured that these keys are not reused.
An attacker not knowing the AAA-Key is unable to calculate the TSKs.
[6] Key activation and deletion. Once the TSKs are derived, it
is necessary to synchronize their activation. The issue of
synchronization also arises during rekey, when it
is desirable to create a new TSK prior to deleting the old one.
The phases and the relationship between the parties is
illustrated below.
EAP peer Authenticator Auth. Server
-------- ------------- ------------
<---------------------------->
Discovery (phase 0)
<------------------------------------------------------>
EAP authentication (phase 1a)
<------------------------->
Access authorization (phase 1b)
<---------------------------->
Service authentication (phase 2)
1.3.1 A concrete example: IEEE 802.11i Extended Service Set (ESS)
o Phase 0: The Station (peer) discovers the Access
Point (authenticator) and its associated capabilities
by listening to Beacon messages, and/or a Probe
Request/Response exchange with the Access Point.
Capabilities learned in phase 0 include the SSID,
data rates, supported ciphersuites, hop patterns
and other PHY parameters.
o Phase 1a is initiated by the station either by sending
an EAPOL-Start message to the Access Point (pre-authentication)
or by completing an Association/Reassociation Request/Response
exchange with the Access Point. The Association/Reassociation
exchange includes selection of the network to which the station
wishes to be attached, as well as the associated capabilities
of that network. However, since this exchange is not secured,
successful completion cannot be considered definitive.
The Access Point (AP) then sends an EAP-Request (most likely an
EAP-Request/Identity) to the Station, encapsulated in an
EAP over Wireless LAN (EAPOW) frame.
The EAP peer and server then authenticate each other.
For example, if EAP-TLS is used, they exchange certificates,
verify that the certificates are valid and belong to the
expected party, and prove possessoin of the corresponding
private keys. This exchange generates a shared key between them.
o Phase 1b typically uses RADIUS, which may use a shared secret and/or
IPsec to provide per-packet authentication and integrity
protection. Where IPsec is used, per-packet confidentiality
can also be provided; where a shared secret is used
confidentiality can only be provided for selected attributes
(such as the AAA-Key).
The Access Point sends a RADIUS Access-Request packet
to the backend authentication server
containing attributes (such as the NAS-Port-Type,
Calling-Station-Id and Called-Station-Id)
describing the service that is being requested.
When phase 1a completes, the
backend authentication server communicates its access
decision to the Access Point (Access-Accept/Reject). If
access is to be provided, the Access-Accept includes
service authorizations such as those described in [RFC3580].
This may include parameters such as Session-Timeout, as
well as the AAA-Key.
o Phase 2 includes the four-way and group key handshakes.
These exchanges protect service parameters
(MAC addresses, Beacon/Probe Response Information Elements,
selected ciphersuite) and derive Transient Session
Keys (TSKs) used to protect subsequent data traffic.
Since the 4-way handshake includes
a protected parameter exchange it enables the station to
definitively confirm the results of the unprotected
Association/Reassociation exchange, including network
selection (if the SSID is included in the 4-way handshake).
After phase 2, the parties protect the 802.11 data frames
utilizing the selected ciphersuite (TKIP or AES CCMP) and
Transient Session Keys. Security services include per-packet
authentication, integrity protection, confidentiality and
replay protection.
1.3.2 Second example: IKEv2/IPsec
This example assumes that IKEv2 [IKEv2] and IPsec [RFC2401]
are used to to provide access to a Virtual Private Network
(VPN), and that EAP is used for authentication.
o Phase 0: Typically the VPN client (initiator) is configured
with the VPN gateway name or address, but it also may be
possible for it to be discovered using mechanisms such as
DNS KX [RFC2230], or SRV [RFC 2782] Resource Records.
The client contacts the gateway and they exchange Diffie-Hellman
parameters, nonces and select an IKEv2 ciphersuite. The
client also indicates the willingness to use EAP by
leaving out the AUTH payload from the third message.
o Phase 1a completes. Typically with IKEv2 it is likely
that an EAP method utilizing password or hardware token
authentication will be used.
o Phase 1b completes and the backend authentication server
provides the authenticator with the AAA-Key as well as
VPN authorization attributes, such as those defined in
[RFC2548].
o Phase 2: In this phase IKE and IPsec SAs are negotiated.
When EAP is used for authentication within IKEv2, the
AAA-Key is not required for TSK derivation since the
Diffie-Hellman exchange is used for this purpose.
However the AAA-Key is used to cryptographically bind
the EAP and IKEv2 exchanges. This is done by
computing a MIC of the Diffie-Hellman parameters and nonces
(and some other information) exchanged in phase 0. This
implicitly protects the parameters and the rest of the
conversation as well. This phase also includes negotiation
of service parameters such as the client IP address, what IP
traffic will be protected, what ciphersuites will be used,
and so on.
After this, data traffic is protected by IPsec ESP [RFC2406]
or AH [RFC2402].
1.3.3 PPP over Ethernet
PPP over Ethernet (PPPoE) [RFC2516] provides the ability to
connect a network of hosts to a remote Access Concentrator.
To provide a point-to-point connection over Ethernet, each
PPP session must discover the MAC address of the remote peer
and establish a unique session identifier.
PPPoE includes its own Discovery stage (Phase 0) in which the
peer can discover the capabilities of available Access
Concentrators. The peer broadcasts an Initiation
packet, one or more Access Concentrators send
Offer packets.
The peer then selects an Access Concentrator and sends
sends a unicast Session Request packet to it. The selected
Access Concentrator then replies with a Confirmation packet.
after which the peer proceeds to the PPP Session Stage,
where authentication can be carried out.
The Session Request/Confirmation exchange confirms the establishment
of an association between the peer and authenticator; however,
since the exchange is not secured it is vulnerable to attack.
Once a PPP Session is established, EAP authentication can
be selected and a method supporting key derivation can
be carried out enabling the generation of keying material
(phase 1a). If a backend authentication server is
available, it can then transport the AAA-Key to the authenticator
(Phase 1b).
Subsequent to PPP authentication, a ciphersuite such as MPPE [RFC3078]
can be negotiated in order to enable encryption of the PPP session. Use of
EAP keying material for derivation of transient session keys
for MPPE is described in [RFC3079].
1.4 Conversation limitations
It is worthwhile to point out two important limitations. The
first one is rather trivial, and applies only to some phase 2
protocols. However, the second one is much less obvious, and
is more a fundamental limitation of the EAP design.
1.4.1 Protection of service parameters in phase 2
Some media (such as PPPoE, see above) may not include a
Phase 2 exchange, and even where a Phase is included,
it may not protect all service parameters. This allows
an attacker without access to the AAA-Key to interfere in
the negotiation of service parameters, disrupting subsequent
communications.
IEEE 802.11i [IEEE80211i] supports but does not
require protection of the SSID or capabilities
such as the data rates or PHY-specific
parameters within the 4-way handshake. Since IEEE 802.11
management frames are unprotected (including the
Association/Reassociation exchange) an implementation
that does not securely include negotiated capability
Information Elements (IEs) within the 4-way handshake
is vulnerable to an attack involving spoofed management
frames. Such an attack could convince the station and
AP to connect to an undesired network at inappropriate
rates, disable use of power management features, etc.
In PPPoE the Discovery and Selection phases are not
protected, and the transient session keys are derived
directly from the AAA-Key, without an additional "secure
association" protocol step. This means that the freshness
of the TSKs are not guaranteed if the AAA-Key is reused;
it also implies that the discovery, network selection and
ciphersuite negotiation phases can be disrupted by an attacker,
since there is no provision for secure capabilities negotiation.
Since PPP ECP [RFC1968] does not support protected ciphersuite
negotiation, a "downgrade attack" can be carried out in
which an attacker can cause a weaker ciphersuite to be selected.
In general, enabling protected parameter negotiation is an
important part of the design of the phase 2 protocol, and
depends on a threat analysis in order to determine what
parameters require protection.
1.4.2 Independence of phases 1a and 1b
Currently, phases 1a and 1b are (almost) independent of each
other. They are usually carried inside the same RADIUS
packets, but in an important sense they are still
independent.
For example, it is possible to terminate
authentication on the EAP authenticator while still
utilizing AAA for authorization, so that EAP packets
would not "passthrough" the authenticator even though
a AAA exchange would still be carried out between the
authenticator and backend authentication server.
As a result, the backend authentication server cannot
restrict the service parameters used by the authenticator.
A malicious or compromised authenticator trusted by the
backend authentication server can present any set of
service parameters it wants to the peer. Protecting
these parameters within phase 2 does not prevent this
attack since protection is achieved using a key known
to the authenticator (the attacker).
Leaving the service parameters to the authenticator
makes sense in many situations. For example in IEEE 802.11
the authenticator (AP) has knowledge of what data rates,
hop patterns or ciphersuites it supports, while the backend
authentication server may not have this information. As a
result, the backend authentication server may only be
capable of providing general guidelines as to what services
can be provided, but not a detailed service specification.
However, there are situations in which the backend
authentication server may wish to restrict some particular
service parameters. For example, currently an IEEE 802.11
Access Point advertising the SSID "Joe's Hotspot" could
advertise the SSID "Harry's Hotspot" or "Example
Inc. Intranet" even though it did not really offer access
to those networks.
Similarly, an IKEv2 VPN gateway could claim to offer
IEEE 802.11 access, and if the IKEv2 session
is authenticated solely using EAP (without certificates),
an Access Point could claim to offer IKEv2 services.
Since the AAA server implicitly trusts the NAS to carry
out the service that it requests, a AAA protocol by itself
cannot provide protection against these kind of attacks.
1.4.3 Connecting phases 1a and 1b
This vulnerability results from the separation of phases 1a
and 1b, a fundamental limitation of the current
EAP (and AAA) design.
It appears that potential solutions involve three
necessary components:
a) The backend authentication server needs to obtain
service parameters from the authenticator.
b) The backend authentication server needs to determine
whether the service parameters are appropriate/valid prior to
providing the AAA-Key to the NAS. This typically will involve
checking the service parameters against values corresponding to
the claimed identity of the authenticator.
c) The authenticator has to be prevented from communicating
different service parameters to the peer and backend authentication
server.
Several potential solutions have been suggested:
1) Service parameters can be communicated within an EAP
method exchange, protected using keys known only to the peer and
EAP server. This allows the backend authentication server to
check whether the values communicated by the EAP peer match
those provided to it by the authenticator.
2) The backend authentication server (and the peer) could
include the service parameters in the derivation of the
AAA-Key, which in turn is derived from keying material
known only to the peer and EAP server. This approach
guarantees that the EAP peer and authenticator will only
derive matching TSKs where the service parameters
communicated by the authenticator to the EAP peer and
server are the same.
Mechanisms 1 and 2 each have their advantages and disadvantages.
Mechanism 1 does not require changes to deployed AAA servers or
authenticators, but depends on deployment of EAP methods which
support service parameter verification. Since EAP methods
are media independent, the method specification cannot be
media specific, and thus cannot service parameters unique to
a particular lower layer. This may make it
difficult to create an EAP method that can verify arbitrary
service parameters.
Mechanism 2 requires chagnes to AAA servers and authenticators
but can work with arbitrary EAP methods. However, its
correct operation is heavily dependent on correct implementation
of service parameter cannonicalization, since if implementations
differ it is conceivable that they could derive different keys,
even if the parameters advertised by the authenticator to the
peer and backend authentication server match identically.
1.4.4 Repeating the conversation
Subsequent to completion of the initial conversation, it is
possible for Phases 0, 1 and/or 2 to be repeated.
A mobile host may change its location and as a result may
periodically initiate discovery of potential new points of
attachment. Alternatively, a new authenticator
may be placed into service and announce its presence on
the network. As a result, a new Phase 0 exchange may be
carried out.
There are several reasons why a new phase 1a/1b conversation
might be required.
o Periodic reauthentication (and reauthorization) might be
needed. In this case a new phase 1a/1b is used to check that
the peer still has the correct credentials, and that
authorization granted by the backend authentication server
is still valid. Where the ciphersuite is known to be
weak (such as IEEE 802.11 WEP), reauthentication may also
be used to force the derivation of a new AAA-Key and
corresponding Transient Session Keys.
o The authenticator has lost the state associated with this
service, or the state is no longer synchronized. This can
occur if the authenticator is rebooted, or
if the the service is moved to a different physical
service element (see Sections 1.4.1 and 3.3.3 for more
discussion).
o New authorization may be required from the backend
authentication server.
This can be required if the peer attempts to change
aspects of the service. Typically the service authorizations
include a range of acceptable services that can be
provided by the authenticator without requesting permission
from the backend authentication server. However if the
peer requests a service outside the authorized range,
additional permission may be required.
For example, in IEEE 802.11 it is possible for the
Station (peer) and Access Point (authenticator) to
renegotiate the data rate, or even the network to
which the station is attached (new SSID in an
Association-Request). If the new rate or SSID is
not one which the backend authentication server had
previously authorized a new phase 1a/1b exchange may
be required.
There are several reasons why a new phase 2 conversation
might be required:
o Periodic rekey. After expiration of the TSK lifetime
it might be desirable to derive fresh TSKs without having
to reauthenticate.
o Deletion of service SAs. For example, a peer might be
moving out of range and wish to notify the authenticator
so that resources can be reclaimed.
Add to informative references:
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-11.txt, Internet draft (work in progress),
October 2003.
[RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June
1996.
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS",
RFC 2230, November 1997.
[RFC2401] Atkinson, R. and Kent, S., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998
[RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", RFC
2402, November 1998
[RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998
[RFC2516] Mamakos, L., et. al., "A Method for Transmitting PPP over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., Esibov, L. "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000
[RFC3078] Pall, G. and G. Zorn,
"Microsoft Point-to-Point Encryption (MPPE) Protocol",
RFC 3078, March 2001.
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft
Point-to-Point Encryption (MPPE)", RFC 3079, March 2001.
-------------------------------------------------------------
Issue 180: Conversation Overview
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen [at] nokia.com
Date first submitted: October 14, 2003
Reference:
Document: Keying framework
Comment type: T
Priority: 1
Section: 1.3
Rationale/Explanation of issue:
Here is a proposed replacement for section 1.3 of the
keying framework (note that this will most likely be
revised during/after the interim meeting).
1.3. Conversation Overview
Where EAP key derivation is supported, EAP authentication is
typically a component of a four phase exchange:
Discovery (phase 0)
EAP authentication (phase 1a)
Access authorization (phase 1b)
Service authentication (phase 2)
In the discovery phase (phase 0), the parties locate and
contact each, and then exchange some information about the
service to be provided. For instance, one of the parties may
indicate its willingness to provide a service (and to perform
the EAP authenticator role), and the other party requests
access to that service (assuming the EAP peer role).
Next, the EAP peer and backend authentication server
authenticate each other (phase 1a) and derive a shared
session key (later called Authorization Key). In this phase,
the authenticator just forwards EAP packets between the peer
and backend authentication server (note that in some cases,
the authenticator and backend authentication server can be
colocated in the same physical node). This feature of EAP
enables deployment of new authentication methods without
requiring development of new code on the authenticator.
Partially overlapping with this exchange is a second exchange
(phase 1b), between the authenticator and the backend
authentication server. In this exchange, the authenticator
and backend authentication server authenticate each other
(using some other mechanism than EAP), and authenticator
sends information about the service requested by the peer
(typically inside some AAA protocol attributes). When the
phase 1a has finished, the backend authentication server
sends the authenticator information about whether the service
should be provided or not, a key for protecting service
communication (Authorization Key), and optionally more detailed
instructions about the service to be provided.
After both phases 1a and 1b are complete, the authenticator
signals the peer it will allow access to the service (phase
2). Next, the peer and authenticator typically exchange more
parameters about the service to be provided (most likely some
were already exchanged during phase 0), protect at least some
of these parameters using the Authorization Key, and agree
about keys used to protect subsequent communication. The goal
is to ensure that an attacker not knowing the Authorization
Key cannot modify the protected parameters or calculate the
keys that will be subsequently used.
The phases and the relationship between the parties is
illustrated below.
EAP peer Authenticator Auth. Server
-------- ------------- ------------
<---------------------------->
Discovery (phase 0)
<------------------------------------------------------>
EAP authentication (phase 1a)
<------------------------->
Access authorization (phase 1b)
<---------------------------->
Service authentication (phase 2)
1.3.1 A concrete example: IEEE 802.11i ESS
(Details to be added; this is just a sketch)
o Phase 0: Typically, the client (peer) discovers the access
point (authenticator) by listening to Beacon messages, and
requests access by sending an Assocation Request
message. The service parameters exchanged in phase 0
include the SSID, data rates, supported ciphersuites, hop
patterns (and other PHY parameters).
The AP initiates phase 1a by sending an EAP Identity
Request, encapsulated inside an EAPOL frame (though in
some cases, the AP requests the backend authentication
server to send this).
o In phase 1a, the client and backend authentication server
authenticate each other. For instance, if EAP-TLS is used,
they both exchange certificates, verify that the certificates
are valid and belong to the expected party, and prove
that they know the corresponding private keys. This exchange
also generates a shared key between them.
o Phase 1b typically uses RADIUS. The RADIUS packets are
authenticated either with RADIUS's own shared secret
mechanism (Message-Authenticator), or IPsec. The access
point sends an Access-Request message containing various
service parameters (such as Service-Type,
Calling-Station-Id, and Called-Station-Id). When phase 1a
has finished, the backend authentication server gives
permission for the service (Access-Accept), and sends
e.g. Authorization Key and Session-Timeout.
o Phase 2 includes the four-way handshake and group key
handshake. These exchanges protect various service parameters
(MAC addresses, RSN IE, selected ciphersuite) and produce
keys for encrypting the actual traffic.
After phase 2, the parties protect the 802.11 data frames
with TKIP or CCMP (basically, encryption and MAC using the
keys negotiated in phase 2, and sequence numbers for replay
protection).
1.3.2 Second example: IKEv2/IPsec
This example assumes a "road warrior VPN gateway" type
situation where the IKEv2 SA is authenticated solely using
EAP (no certificates are necessary).
o Phase 0: IKEv2 doesn't usually use "discovery" in strict
sense; instead, the client (initiator) is configured with
the IPsec gateway's address or DNS name. The client
contacts the gateway and they exchange Diffie-Hellman
parameters, nonces and select an IKEv2 ciphersuite. The
client also indicates the willingness to use EAP by
leaving out the AUTH payload from the third message.
o Phase 1a is similar as above (although it is likely
that some other EAP method than EAP-TLS would be used).
o Phase 1b is also very similar. Although no "RADIUS
guidelines for IKEv2" document exists yet, RADIUS could be
used with very small modifications (perhaps a new value
for Service-Type and agreement about what to put in
Calling-Station-Id/Called-Station-Id attributes).
o Phase 2: In this phase, the client and the gateway
authenticate the IKEv2 SA by using Authorization Key to
compute a MAC of the Diffie-Hellman parameters and nonces
(and some other information) exchanged in phase 0. This
implicitly protects other parameters and the rest of the
conversation as well. The service parameters negotiated
next include details about client IP addresses, what IP
traffic will be protected, what ciphersuites will be used,
and so on.
After this, the traffic is typically protected with ESP or AH.
1.3.3 Repeating the conversation
There are several reasons why a service might require new
phase 1a/1b conversation.
o The service may require periodic reauthentication (and
reauthorization): A new phase 1a/1b is used to check that
the client still has the correct credentials, and the
authorization granted by the backend authentication server
is still valid.
o Service parameters may have changed in a way that requires
new authorization granted by the backend authentication
server.
For instance, suppose that the peer is allowed WLAN access
with 802.11g physical layer; is the user allowed to switch
to 802.11b? In this case, the answer is most likely
yes--the backend authentication server isn't concerned
with such small details. The peer and authenticator can
negotiate this change in service parameters without having
a new phase 1a/1b exchange.
However, if the user is accessing SSID "Joe's HotSpot",
does this authorization also give access to SSID "Example
Inc. Intranet"? Most likely no--this is a detail the
backend authentication server would like to know about.
Depending on the service, there are service parameters
between these two extremes: some of them matter when
authorizing access, some are small details that can be
negotiated freely between the peer and the authenticator.
See Section X.X for more discussion about the authorization
issues.
o The authenticator has lost the state associated with this
service, or the state is no longer synchronized. This may
occur if, for instance, the authenticator is rebooted, or
if the the service is moved to a different physical
service element (see Sections X.X.X (TBD: correctness
of fast handoff) and 3.3.3 for more discussion
about this).
1.4 Conversation limitations
It is worthwhile to point out two important limitations. The
first one is rather trivial, and applies only to some phase 2
protocols. However, the second one is much less obvious, and
is more a fundamental limitation of the EAP design.
1.4.1 Protection of service parameters in phase 2
Typically, phase 2 does not protect all parameters about the
service. That is, even an attacker who does not know the
Authorization Key can cause the parties to have a different
idea of some service parameters.
For instance, MPPE [RFC3078] does not protect the selected
ciphersuite, potentially allowing a "downgrade attack" in
which an attacker causes a weaker ciphersuite to be selected
than would have been otherwise. To take a second example,
IEEE 802.11i does not protect the SSID, capability
information, data rates and PHY-specific parameters sent in
Beacon messages.
Of course, not all parameters necessarily need protection,
since they are not useful in any practical attacks. Selecting
what parameters to protect is a design decision in the phase
2 protocol, not a fundamental property of the EAP design.
1.4.2 Independence of phases 1a and 1b
Currently, phases 1a and 1b are (almost) independent of each
other. They are usually carried inside the same RADIUS
packets, but in an important sense they are still
independent. (At least in theory, it would be possible to
have a system where the EAP packets would not go through the
authenticator at all).
The most important consequence of this is that the backend
authentication server cannot restrict the service parameters
used by the authenticator. A malicious or compromised
authenticator (that is trusted by the backend authentication
server) can present any set of service parameters it wants to
the peer. The parameters can be protected at phase 2, but at
this point they are protected using a key known to the
authenticator.
Leaving the service parameters to the authenticator actually
makes sense in many situations. For instance, in WLANs the
authenticator (AP) knows best what data rates, hop patterns
or ciphersuites it supports. It would probably not be wise to
require the backend authenticator server to know about these.
However, there are situations where the backend
authentication server might want to restrict some particular
service parameters. For instance, currently a WLAN access
point offering service for SSID "Joe's Hotspot" could also
claim to offer service for SSID "Harry's Hotspot" or "Example
Inc. Intranet". To take a second example, an IKEv2 gateway
could claim to offer WLAN service, and if the IKEv2 session
is authenticated solely using EAP (without any certificates),
a WLAN access point could claim to offer IKEv2 services.
1.4.3 Connecting phases 1a and 1b
The separation of phases 1a and 1b is a fundamental
limitation of current EAP design. There have been discussions
whether this limitation is actually a significant problem or
not, and if so, how it could be solved.
It seems that any solution involves three necessary components:
1) The backend authentication server has to get the values
for those parameters.
2) The backend authentication server has to check that
the authenticator it is sending the Authorization Key to is
actually authorized to use those values.
This most likely involves a database on the backend
authentication server, connecting the authenticated
identity of the authenticator (AAA SA, see Section 3.4)
to the authorized values (such as SSID).
3) The authenticator has to be prevented from telling different
values to the peer and backend authentication server.
a) The values could communicated inside the EAP exchange,
protected using keys known only to the peer and
the backend authentication server (EAPv2 or Archie).
b) The backend authentication server (and the peer) could
include the values of these parameters when deriving
the Authorization Key (from keys known only to the
peer and the backend authentication server).
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.