|
During the HOKEY WG meeting today we got into a
discussion of
fraud protection and potential issues relating to that within ERX. Since I mentioned the fraud issue in my O&M
review, and
since this issue has been brought up by other reviewers as well as in Sam's DISCUSS, I thought I'd send a more detailed description of my perception of the problem to the list, in order to fully describe what I think the issue is, and how it has been introduced.
At its core, I believe that the problem has been
created
by the introduction of a short cut that in practice will provide little in the way of handoff latency reduction, namely the piggybacking of DSRK provisioning on the initial EAP authentication (e.g. EAP boostrapping). The shortcut is immaterial to performance because
the additional
latency involved in providing proper peer authorization for DSRK provisioning would be amortized across the user's connection time within the new domain and thus would not constitute a burden. This optimization is problematic from
a security perspective because it not only enables new avenues for fraud when ERX is used, but it also negatively affects the security of EAP as it is currently deployed, by providing keying material to an entity that the EAP peer has not authorized, and may not even be familiar with, even when the peer does not support ERX. How has the use of EAP boostrapping within the ERX
design
introduced new avenues for fraud? There are several properties of AAA protocols that
are very
useful for automated anti-fraud protection: 1. Correlation of Accounting Records to a
corresponding
authentication record; 2. Linkage of authentication records to a user
whose
authentication can be verified (and is immune to replay). Property 1 is provided by the Class Attribute,
which can
be provided within an Access-Accept and subsequently echoed to an Accounting-Start, as well as via the Acct-Multi-Session Attribute, which can be used to correlate Accounting-Start packets issued within a single session of a user handing off between access points. Property 2 is provided by the requirement that a
RADIUS
Access-Request provide either a State Attribute, user authentication attributes or other evidence that demonstrates that the Access-Request represents an interaction with a user that at one point was demonstrated to be live (e.g. not a replay). Properties 1 and 2 together limit the
opportunities
for fraud. While it is possible for an operator to "imbelish" accounting records for valid sessions, potentially expanding the charges, it is typically not possible to invent sessions to which fictious charges can then be attached. The difference may seem subtle, but in practice,
it
is important. As an analogy, it is the difference between being overcharged for a purchase that you did make, and having an unknown item show up on your credit card that was purchased at an unfamiliar location. To date, fast handoff proposals (such as 11r)
have
stretched, but not broken the anti-fraud protections provided by AAA protocols: 1. While the user may move between
authenticators,
migration of the authorization parameters between authenticators has enabled correlation of accounting records both with each other (e.g. same Multi-Session-Id) and with the corresponding authentication record (via the Class Attribute). 2. While the fast handoffs do not generate
authentication attempts for each new authenticator, accounting records can only originate from the administrative domain within which the original authentication attempt occurred. For example, within IEEE 802.11r, the user
may
only successfully complete a fast BSS transition within the Mobility Domain. As a result, if the home accounting server were to receive an Accounting-Start from a different Mobility Domain that did not correspond to an authentication attempt originating from within that Mobility Domain, then the Accounting-Start can be flagged as fraudulent. What has ERX done with EAP boostrapping that is so
different from existing schemes? As I see it, the fundamental problem is that
EAP
boostrapping changes the AAA protocol model in a fundamental way by allowing an ERX server on the path to request a key, without providing proof that the user authorized that key request, thereby bypassing AAA protocol anti-fraud protections. As it stands, the ERX-13 document does not
specify
checks that the AAA server should perform before issuing the requested DSRK. For example, the ERX server need not necessarily be only a single hop from the AAA server, and thus may not be authenticated to the AAA server, violating the requirements of RFC 4962. If the ERX server is allowed to exist multiple hops from the AAA server, this also implies that the ERX server need not necessarily exist within the local domain which the user has connected to. The result of this is that a home AAA server
providing a DSRK to an ERX server via EAP boostrapping will not necessarily be able to link accounting records received from that server to the original EAP authentication, or to a subsequent ERX authentication terminating at the home server. What can be done to address the problems? The most satisfying solution from a security perspective would be to eliminate the piggybacking of DSRK provisioning on top of legacy EAP exchanges. Providing an explicit request from the peer to the server for provisioning of the DSRK would provide the server with proof of client liveness within the domain which subsequently will issue accounting records, closing the fraud loophole, as well as removing the RFC 4962 "authenicate all parties" problem, and any security impact on legacy EAP deployments. Another potential approach would be to
introduce authorization checks on the AAA server. For example, the AAA server could require that the ERX server be only one hop away, thereby addressing the "authenticate the parties" issue. Also, the ERX server could now be guaranteed to be in the same domain as the user, limiting the potential for fraud to roughly the same magnitude as existing fast handoff proposals such as 11r. |