|
RE: IETF last call on draft-barany-eap-gee-04.txt
2007-01-04 17:20:29
<snip>
* EAP lower layer and GEE - Bernard's review pointed out
that the EAP
lower layer transport requirements are not discussed in the
GEE draft.
GEE is not an EAP lower layer. GEE is a protocol that the EAP lower
layer can use to allow multiple parallel authentications.
As I already commented, GEE is part of EAP lower layer in
term of RFC 3748. This fact does not change even if the
lower layer of GEE negotiates the use of GEE between the peer
and authenticator.
[Joe] GEE is not an EAP lower layer, it is intended to be transparent to
the EAP method layer. GEE does not provide lower layer functionality by
itself, rather it relies upon the processing of a lower layer that meets
the RFC 3748 requirements.
Yoshihiro Ohba
Also, this is
not quite the same as pre-authentication, since GEE is to allow
multiple authentications for different purposes (e.g., device and
user; specific types of accesses, say, IPv4 and IPv6, etc.).
Pre-authentication, as Lakshminath points out, can still be
done with
GEE and in fact, multiple types of authentications can be
done as pre-authentication.
* Packet modification attacks - Bernard raised a question on packet
modification attacks leading to, say, Type 2 access being granted,
when only Type 1 authentication had occurred. Such MiTM attacks are
not a problem when appropriate key/identity binding
requirements are
met as documented. OTOH, if the peer is malicious, it may
try to use
Type 1 credentials for Type 2 authentication or vice-versa.
However,
any time a system expects multiple types of authentication, the
authorization information must be clearly sent from the
backend server
to the authenticator, indicating the type of access the
peer can be granted.
This is a need for multiple authentications with or without GEE. We
can add some text about this in the security considerations
section to
clarify the required authorization information from the
backend to the
authenticator.
* Identity binding - Bernard points out the incorrect usage of peer
IDs in page 12. We will remove the text under "Single
Access Control
Enforcement with Protected Result Indication" - when both
methods are
key generating, the MSKs should be bound anyway.
* On using CUI for identity binding - I think Bernard raises a good
point here. Perhaps, that doesn't make sense as an example
and perhaps
should be removed. Jari, thoughts on this?
We will fix the terminology and other nits suggested by
Bernard as we
revise the document.
Thanks,
Vidya
-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti(_at_)qualcomm(_dot_)com]
Sent: Wednesday, December 27, 2006 11:44 PM
To: Bernard Aboba; Yoshihiro Ohba
Cc: Jari Arkko; Barany, Pete; ietf(_at_)ietf(_dot_)org
Subject: Re: IETF last call on draft-barany-eap-gee-04.txt
Hi Bernard, Yoshi,
Many thanks for your reviews and notes. I am going to try and
address the overarching issues. Once we settle on those, we can
take care of the details.
* On the use of the term "generic":
At the beginning of the GEE standardization effort, the
idea was to
specify the protocol and allow use of it by any EAP lower layer,
irrespective of which standards body develops the lower
layer. Upon
Jari's suggestion, we introduces the term 3GPP2 so as it
stands now,
GEE is only applicable to EAP lower layers defined by
3GPP2. Please
note that *multiple* lower layers specified by 3GPP2 may use it.
Furthermore, the intended status is "experimental." The
idea is to
try it out and if all goes well, allow the protocol to be used by
any lower layer. Finally, the mechanism over the period
of 1 year
or so has been known as GEE, so we would like to continue to use
that term.
* On correctly parsing the GEE header:
Indeed EAP lower layers (would have to) specify how a peer and an
authenticator can negotiate whether to use EAP or GEE
(and versions
within GEE etc); after that though, there would not be
any incorrect
parsing of a GEE header as an EAP header.
Perhaps it is best to specify that this is expected of
the EAP lower
layer in the GEE I-D. Would that resolve this concern?
* On specifying GEE at the IETF:
Surely, GEE could have been specified as part of the EAP lower
layer, but that would mean each lower layer would have to
specify it
independently and as with most things, those sort of
exercises tend
to end up with results slightly (or vastly, take your pick)
different from each other.
Next, where as it is true that pre-authentication does allow
multiple EAP conversations to occur in parallel, it is
important to
note that pre-authentication merely solves a subset of
the problems.
In fact, there is nothing to say that pre-authentication
cannot be
used with GEE. It can very well be used.
(Also please see the explanation for the use of the term
"generic"
on why GEE is better specified at the IETF). Jari also
provides a
justification for this in his latest email.
* On getting an expert review of 3GPP2's EAP lower layers
by the IETF:
As it turns out, Vidya suggested this very thing at the
beginning of
the GEE standardization effort to some of our
3GPP2 colleagues. The decision of course will be made by
3GPP2 (the IESG can send an LS of course). 3GPP2 may
develop one or
more EAPoBlah standards and we can try and suggest to them that a
review by the IETF in each case would be worthwhile. In the same
vein, it appears that with GEE they have identified a piece of
common functionality that they think is best specified at
the IETF.
Once we agree on the above issues, we can move forward
and discuss
things like key binding, how authenticators might keep track of
results from the multiple authentications etc.
Thanks also for your notes on inconsistencies (e.g., upside down
layering diagram) and gaps in explanations. We will fix those as
part of the next revision of the draft.
Thanks again for your review and best wishes for the new year,
Lakshminath
At 05:00 PM 12/24/2006, Bernard Aboba wrote:
Review of draft-barany-eap-gee-04.txt
Overall Comments
The title of this document "3GPP2 Generic EAP
Encapsulation (GEE)
Protocol" is somewhat of a contradiction in terms,
implying both a
mechanism that is specific to 3GPP2, as well as a "generic"
encapsulation, suitable for use with any link layer.
This contradiction carries through much of the document, leaving
the reader uncertain whether the authors are describing a
3GPP2-specific lower layer encapsulation of EAP, or a
more general
mechanism that is
intended for use with *all* existing EAP lower layers.
If the document is intended to describe an EAP lower
layer, then it
should not contain language suggesting that EAP peer and
authenticator
implementations need to be modified for use with GEE, or
diagrams that
show GEE sitting above the EAP lower layer.
The problem with a generic EAP shim is that the architecture
described
in RFC 3748 does not provide a mechanism for negotiation of its
use, and therefore there is no generic (e.g. non-link layer
specific) way for backwards compatibility to be maintained.
As a result, introducing a shim as described in this
document requires
modification to existing EAP lower layers, or it risks
introducing
interoperability problems within existing implementations.
No existing
EAP lower layer has been defined to handle the GEE header,
and if such
a header were to blindly inserted, it would be interpretted
it as the
EAP Packet Code field by existing EAP peers, authenticators and
servers:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Version|TID|RFL|
+-+-+-+-+-+-+-+-+
The version field = 0, and the TID field = 00/01. The
RFL bits are
= 10 or 00.
Given this, the GEE header would be interpreted as one of
the following
EAP Packet Code values:
0 (TID = 0, RFL = 00) (Reserved in RFC 3748)
2 (TID = 0, RFL = 10) (Response, in RFC 3748)
4 (TID=01, RFL = 00) (Failure, defined in RFC 3748).
6 (TID=01, RFL=10) Not defined in RFC 3748.
RFC 3748-conformant EAP implementations would be likely
to silently
discard Packet Codes of Types 0 and 6, and would also
discard Code 2 if
sent by an EAP authenticator and Code 4 if sent by an EAP peer.
While the document states that conforming implementations are to
add and strip off the GEE header, it is not made clear how use
of EAP GEE
is negotiated so that EAP peer and authenticator implementations
can tell if it is being used or not. Presumably this
negotiation
is to occur in the link layer, but since no existing EAP link
layers support
such a negotiation, and the document does not describe how
it works, I
am not clear about whether backward compatibility is being
maintained or not.
Given that link layer negotiation seems to be required and
no existing
link layer supports such a negotiation, GEE appears
incompatible with
existing EAP lower layers other than perhaps 3GPP2.
A generic shim that only (maybe) works with a single
link layer is
somewhat of a contradiction.
Given the problems of a generic EAP shim, the document makes
much more
sense if it is viewed as part of a definition of a 3GPP2 lower
layer for EAP. Presumably 3GPP2 has defined a mechanism by which
the use of
GEE can be negotiated, and once this is done, 3GPP2 peers and
authenticators can encapsulate and decapsulate EAP
packets within a
3GPP2 lower layer including the GEE header. This kind of
encapsulation/decapsulation is described in RFC 3748 as
part of the
operation of a lower layer, so inclusion of GEE within the
3GPP2 lower
layer definition makes much more architectural sense.
However, given the current orientation of the document,
significant
rework would be required to recast the GEE scheme as a
3GPP2-specific
lower layer definition. Currently the document does not
really get
into sufficient detail to understand exactly how EAP is to be
encapsulated when run over 3GPP2. For example, there is no
discussion
of lower layer requirements for transport of EAP packets, as
discussed
in RFC 3748, Section 3.1.
Specific Comments
Abstract
This document specifies the 3GPP2 Generic EAP
Encapsulation (GEE)
protocol for differentiating between multiple EAP
conversations between
a peer and an authenticator.
As noted earlier, this paragraph presents GEE as a
generic update
to the EAP specification when it seems more appropriate as part
of a 3GPP2
lower-layer definition.
As CDMA2000 third generation cellular networks evolve
[8], [9], EAP
will also be used as a general authentication
protocol that runs
directly over the data link layer [10].
Is GEE support included in reference [10]? I presume that
it is, since
otherwise, I don't see how the mechanism described in
the document
could be deployed.
EAP can be used for different types of authentication,
where multiple
providers provide access to different services.
However, EAP itself
does not have the ability to differentiate between
multiple EAP
conversations between a peer and an authenticator.
In general, differentiation between conversations is the task of
the lower layer, so this is not an EAP architectural issue.
This document specifies the 3GPP2 Generic EAP
Encapsulation (GEE)
protocol for differentiating between multiple EAP
conversations
between a peer and an authenticator. In the rest of
this document,
we refer to this protocol as GEE, Version 0 or GEEv0.
Given the title of the document, I was expecting something
more along
these lines:
This document defines a mechanism implemented as part of
the 3GPP2
lower layer support for EAP defined in [10] which enables
differentation between multiple EAP conversations occuring
over a 3GPP2 link layer.
As a result, the mechanism described in this document is
specific
to
3GPP2 and is not applicable to other EAP lower layers.
Figure 1 shows an example of the case where the
access network
provider is different from the service network
provider. The ANP
hosts the Authenticator (NAS or Network Access Server in
the figure)
and an Authentication Server (AAA-ANP in the figure).
The SNP may
have its own Authentication Server (AAA-SNP in the figure).
This figure implicitly assumes use of an EAP lower layer
that enables
multiple EAP conversations to be ongoing at the same
time. Not all
existing EAP lower layers permit this. For example, WPA
does not
support pre-authentication or make-before-break, and
therefore EAP
authentication is only permitted between a STA and an AP that it
has successfully associated to. A STA can only be associated to
a single AP
within an ESS (associations to separate ESSes are possible via
multi-net). As a result, I would suggest that the lower
layer assumptions be stated.
When a peer is performing multiple EAP
authentications, it is not possible to clearly
differentiate between
the two types of authentications using available means...
Hence, there is no available means to allow multiple EAP
authentications for a given peer to occur in
parallel.
Some existing EAP lower layers do enable an EAP peer to conduct
multiple EAP authentications in parallel. For example, a STA
supporting WPA2 pre-authentication can initiate multiple
simultaneous
EAP authentications (to different BSSIDs).
While EAP methods are TLV-based and can easily be
extended to carry
additional information between the peer and the server,
EAP itself
does not provide a means to carry any additional
information between
the peer and the authenticator.
Not all EAP methods are TLV based, and as described in RFC 3748,
the lower layer can also carry "additional information"
such as a
GEE header.
It is important that the EAP peer
and authenticator be able to differentiate between
the access and
service authentication exchanges for multiple reasons.
For example,
it allows proper routing of the messages to the
appropriate EAP
server and allows the two exchanges to happen in parallel.
EAP peers and authenticators already do this today, as noted
earlier.
However, this does not relate to routing of EAP packets to
EAP servers;
that is handled via the EAP Identity Request/Response
mechanism as
described in RFC 3748 and 3579.
Hence, the primary motivation for this document is
to provide the
functionality for EAP peers and authenticators to
differentiate
between multiple EAP exchanges that a peer may be
executing in
parallel to gain access to different networks or services.
As described above, the title suggests that the motivation is to
describe a 3GPP2-specific EAP lower layer encapsulation.
relate t routing of EAP messages to EAP servers. That
routing is
handled uthenticator
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP method| EAP method| | EAP method| EAP method|
| Type = X | Type = Y | | Type = X | Type = Y |
| V | | | ^ | |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! Peer layer | | EAP ! Auth. layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! layer | | EAP ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| GEE ! layer | | GEE ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| Lower ! layer | | Lower ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
! !
! !
+------------>-------------+
Figure 2: GEE Protocol stack and Peer to Authenticator
interaction
in
In this diagram, GEE should be included as part of the
lower layer,
rather than a distinct entity below the EAP layer, given
that GEE
cannot function without modifications to the lower layer.
Peer Pass-through Authenticator
Authentication
Server
+-+-+-+-+-+-+
+-+-+-+-+-+-+
| | |
|
|EAP method |
|EAP method |
| V | |
^ |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-!-+-+-+
| ! | |EAP | EAP | | |
! |
| ! | |Peer | Auth.| EAP Auth. | |
! |
|EAP ! peer| | | +-----------+ |
|EAP !Auth.|
| ! | | | ! | ! | |
! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+
+-+-+-!-+-+-+
| ! | | ! | ! | |
! |
|EAP !layer| | EAP !layer| ! | |
! |
| ! | | ! | EAP ! layer | |
EAP !layer|
+-+-+-!-+-+-+ +-+-+-+-!-+-+-| ! | |
! |
|GEE !layer| | GEE !layer| ! | |
! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+
+-+-+-!-+-+-+
| ! | | ! | ! | |
! |
|Lower!layer| | Lower!layer| AAA ! /IP | |
AAA ! /IP |
| ! | | ! | ! | |
! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+
+-+-+-!-+-+-+
! ! ! !
! ! ! !
+-------->--------+ +--------->-------+
This diagram is also problematic because the kind of
decapsulation
described here can only be carried out by an EAP lower
layer, not
within the EAP layer itself. If GEE is included as part of
the lower
layer, then the diagram makes more sense, since it would be
clear that
GEE requires lower layer modifications.
When the authenticator operates in pass-through mode,
the GEE layer
terminates at the authenticator and the EAP packet
is sent over a
backend AAA layer (e.g., RADIUS [11]). In this case, the
authenticator must handle the GEE fields in exactly the
same manner
as in the multiplexing model. The fields in the GEE
header may be
used by the authenticator to identify the correct
EAP exchange to
properly route the EAP packet. A Transaction ID (TID)
field defined
in the protocol allows the EAP exchanges to be
distinguished. The
TID field is used to look up the appropriate domain
to which a
particular EAP message must be routed.
As described in RFC 3748, the behavior described above
can only be
satisfied by an EAP lower layer, since a legacy EAP
implementation will
not know how to add or strip a GEE header. So the term
"GEE-enabled lower layer" would be more appropriate than
"GEE layer".
Depending on the architecture, the authenticator that is
responsible
for each authentication may be different. This could be true
irrespective of whether the EAP server is the same or
different for
each authentication. However, in most practical cases,
the need for
multiple authentications arises only when the EAP
servers performing
the different types of authentications are different.
Figure 4 shows
the architecture with each provider having a different
authenticator
that is engaged in different EAP exchanges that the peer
performs.
In 3GPP2 networks, single authenticator and multiple
authenticator
architectures are both possible.
Since existing EAP lower layers already support multiple
simultaneous
authentications with different authenticators (and different EAP
servers), this scenario can be realized today, without the
GEE header.
Since GEE runs between the peer and the authenticator,
it brings a
slight variance when the authenticator for each EAP
exchange is
different. Since the multiple EAP authentications are
over the same
link, the EAP exchange between the peer and one of the
authenticators
may have to pass through another authenticator or
enforcement point.
Hence, the lower layers at each hop in this case
must be able to
indicate the presence of the GEE header.
Actually, the lower layer *always* needs to support the GEE
header, right?
---------------------------------
| |
| Data link layer header |
| |
---------------------------------
| |
| GEE header |
| |
---------------------------------
| |
| EAP packet |
| |
---------------------------------
This diagram is upside down (other diagrams put EAP layer on
top of the
GEE layer).
Version
The first 4 bits in the GEE header represent the
protocol version
number. This field MUST be set to 0 for GEEv0.
Transaction ID (TID)
A 2-bit TID flag is used to distinguish between
multiple EAP
conversations. In Version 0 of GEE (GEEv0), the TID
field MUST be
either 00 or 01. When TID = 01, the encapsulated EAP
packet is
for Type 1 authentication. When TID = 00, the
encapsulated EAP
packet is for Type 2 authentication. In GEEv0, TID
values other
than 00 and 01 are reserved and MUST NOT be used.
Why are 4 bits used for the Version, but only 2 for the
transaction ID?
Existing EAP lower layers can handle more than 4
simultaneous EAP
authentications, so that a two bit transaction ID seems
to provide
*less* flexibility than already exists.
Result flags/code (RFL)
The last 2 bits in the GEE header are used to
indicate the result
of the EAP authentication in progress. The leftmost
bit in this
field is the 'K' bit and indicates whether the MSK
resulting from
the EAP conversation being encapsulated by the
particular GEE
session must be bound with an MSK resulting from the
second EAP
conversation carried in a second GEE session. If
set, this
implies that the peer MUST bind the MSKs to
derive TSKs. The
process of MSK binding is described in Section 5.3.
In GEEv0, the
last bit is the R bit and is reserved and MUST be set
to zero at
the sender and MUST be ignored by the receiver.
Statements about the use of an MSK only really make sense
within the a
lower layer definition, since presumably the EAP method will
output the
MSK/EMSK as it would normally, with no awareness that
GEE is being
used.
When the peer receives a GEEv0 packet, the TID field
in the GEEv0
header MUST be used to determine if the encapsulated EAP
packet is
for Type 1 or Type 2 authentication. If TID value
is 01 in the
packet received from the authenticator, the peer
must perform the
necessary Type 1 authentication. For instance, this may
mean that
the peer provides the appropriate identity and use the
appropriate
EAP method in the EAP session. When the TID is set
to 00 in the
packet received from the authenticator, the peer
must perform the
necessary Type 2 authentication.
At first glance, this appears to be a statement about EAP packet
handling. I would rephrase it to say "when a 3GPP2 lower layer
receives a GEEv0 packet... if the enapsulated 3GPP2 frame is
for Type 1
or Type 2 authentication... the 3GPP2 lower layer must
perform the
necessary Type 1 authentication..."
5.2. Packet Handling at the Authenticator
When the authenticator receives a GEEv0 packet, the TID
value in the
header MUST be used to determine if the encapsulated EAP
packet is
for Type 1 or Type 2 authentication.
Again, I don't believe that this document should be
modifying EAP
authenticator behavior described in RFC 3748. This should
be modified
to say "when the 3GPP2 lower layer residing on the authenticator
receives..."
5.3. Multiple authentications and access control enforcement
When both Type 1 and Type 2 authentications are carried
out, access
control MUST conform to the following cases.
Type1 Type2
Combined result
Case 1 Success Success Success
Case 2 Success Failure Type1
related access only
Cases 3&4 Failure S/F Failure
Cases 5&6 N/A S/F S/F
This diagram suggests that network access can be granted
even if one of
the authentications fail. If the GEE header is not
protected (it would
be hard to protect unless it represented a
re-authentication, since no
keys have been derived), this seems like it could result in
a privilege
elevation attack. For example, unless the NAS kept
track of which
conversation related to which GEE header, an attacker could
potentially
modify the GEE header in transit, resulting in granting
a different
Type of access than was intended. For example, the
attacker could
modify a GEE Type 1 to a GEE Type 2, etc.
GEE requires that at least one of the
authentications to be key
generating and both authentications to be mutually
authenticating.
How does GEE enforce this requirement? If GEE is part
of the lower
layer, then it makes more sense to say "3GPP2 lower layers
require that
at least one...".
If one of the authentications is not key generating,
then there MUST
be a way for the authenticator to identify the two
authentication
conversations (Type 1 and Type 2) corresponding to a peer.
Specifically, there MUST be a mechanism for the
authenticator to
correlate the Type 1 and Type 2 credentials;
typically this is
facilitated by backend network protocol support. An
example of such
backend support is to be able to send an identifier that
is unique to
the peer across the authentications in an authenticated
manner. For
instance, when both authenticators reside in the same
node, the AAA
transactions may return Chargeable-User-Identity
(CUI) attributes
[12] and the node can compare them for equality. If
there is a
mismatch, or the node has not received such an
identity from both
transactions, the peer MUST be disconnected.
Since different AAA servers can issue different CUIs for the
same user,
I am not clear how a NAS could compare them. And in any
case, the CUI
document describes the returned attributes as opaque blobs, no?
MSK Binding
In this case,even when there are multiple
authenticators, we
assume that there is only one access control
enforcement point.
Here, the combined MSK MUST be used to derive session keys
(Transient session keys, TSKs). Both authenticators
deliver the
MSK to the enforcement point and it computes the
combined MSK as
follows: Combined-MSK = f(MSK-Type 1, "GEE Combined
Key" || MSK-
Type 2), where f represents prf+ as defined in [3].
The length of
the Combined-MSK MUST be 512 bits. With GEEv0, the
PRF is HMAC-
SHA-256.
The use of terms such as "combined MSK" suggest that this
document is
updating RFC 3748. I would suggest that a different term be
used, such
as "Intermediate Key Binding" (IMSK).
Single Access Control Enforcement with Protected Result
Indication
In the event that there can be a protected result
indication
between authenticators and/or enforcement points
with a way to
correlate the peer IDs used in the EAP
conversations, it is
feasible to have the TSK generated from only one
MSK. A MiTM
attack may be plausible in this case, and hence it is NOT
RECOMMENDED.
I'm unclear what this paragraph is intending to say. The
authenticator
is presumably unable to correlate peer-IDs, given that it is
operating
in "pass-through" and may not even have visibility into the
EAP method
exchanges since they are encrypted with keys it does not have
access to. Does the paragraph mean to imply that the
NAS requests
the Peer-Id
attribute be sent to it by the AAA server?
When two EAP authentications are performed, it is always
feasible to
use keys from a first exchange to protect a
subsequent exchange.
Note that the two authentications in this case will occur
sequentially and the first method must be key
generating. The use of
GEE does not preclude such an operation, even though the main
motivation for GEE is to allow parallel execution of the EAP
exchanges.
In fact, existing lower layer specifications *require* that the
authentications be handled sequentially. For example,
in WPA/WPA2,
receipt of keys kicks off the 4-way handshake. This is
another reason
why GEE is inherently incompatible with existing EAP
lower layers.
6. GEE Extensibility
GEE could be extended to support dynamic TID
assignment, where an
authenticator may pick an unused TID value. The peer could
participate in as many as 4 EAP conversations in parallel.
As noted earlier, this is already possible.
In order for the peer to be able to understand the
meaning of each
TID, a new mechanism would be needed to send
information about
authentication type and other policy hints.
Given that existing implementations can already handle multiple
authentications, I don't understand why "policy hints" need
to be sent
across the wire.
If the EAP method used for one authentication is known
to be weaker
than the EAP method used for another authentication,
whereas the
authenticator may intend to enforce one
authentication before the
other, an attacker may modify the GEE flags to cause
the peer to
start the weaker authentication without the protection
of stronger
authentication. The adversary may then be able to break
the weaker
authentication method and gain access to services.
Even if the
authenticator requires, say, both Type 1 and Type 2
authentications
from all peers, it is plausible for a rogue peer
with available
credentials for Type 1 authentication to gain access
to Type 2
services for which it does not have proper credentials.
Wouldn't it also be possible for an attacker to gain access to a
different service type (1 vs. 2) by packet modification?
To mitigate this threat, i.e., when the EAP method
used for one
authentication (e.g., Type 2) is more vulnerable to
attacks than the
EAP method used for another authentication (e.g.,
Type 1), the
authenticator needs to strictly enforce a policy of Type 1
authentication first, and require that the Type 2
authentication
occur within the secure channel established as a
result of Type 1
authentication. Another possible solution is for the
authenticator
to maintain an association between the Layer 2 security
association
and Layer 3 address(es), to prevent rogue peers from
stealing other
peers' IP services.
The problem is that EAP authentication typically occurs
*before* layer
3 addresses are assigned, so that this would require the
authenticator
to snoop on layer 3 traffic occuring after authentication,
as well as
to keep additional state.
Suppose a peer has credentials for Type 1 authentication
in a visited
network and credentials for both Type 1 and Type 2
authentication in
the home network. It is plausible that the peer may
supply its home
network credentials for Type 1 as well as Type 2
authentication and
thereby avoid any payments to the visited ANP. To avoid this
possibility, the AAA-ANP may send to the authenticators
its Type 1
authentication policy by sending a list of realms for
which Type 1
authentication request is allowed to be forwarded to
home network.
The authenticator may share that information with the
peer in the EAP
identity request following the semantics in RFC 4284
[13] or other
similar procedures.
Since RFC 4284 hints are unprotected, it seems like this
would be
vulnerable to active attack.
There are several possible mitigation strategies
including the use of
identifier binding between authentications (e.g., Layer
2 and Layer 3
identifier correlation), or in case of sequential
authentications,
the use of key material from the first
authentication to encrypt
future authentications. Other solutions require all
authentications
to be key generating and binding all the keys to
generate the master
key used to bootstrap the traffic key generation
process or using
multiple encapsulations using the generated keys.
As described earlier, this would require authenticators
to snoop on
layer 3 exchanges and keep additional state on EAP peers.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|