[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eap] [HOKEY] ERX fraud issue
On Wed, Mar 12, 2008 at 10:47:44PM -0700, Lakshminath Dondeti wrote:
> Hi Bernard,
>
> Thank you for clearly explaining the problem. I appreciate it. I have
> even read Acct-Multi-Session-Id thing now and I wonder perhaps it makes
> sense to tie the "domain" definition to that attribute.
I am not sure how this can solve the problem. How this provides an
evidence that the peer has requested DSRK?
Yoshihiro Ohba
>
> Let me try to respond to your notes below:
>
> On 3/12/2008 2:43 PM, Bernard_Aboba@hotmail.com wrote:
> > 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).
>
> Again, thanks for pointing out the specific issue here. It is very helpful.
>
> >
> > 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.
>
> The shortcut helps. After full EAP authentication, the next AP the peer
> attaches to (we don't know how fast the handover happens) would have to
> run ERP bootstrapping exchange instead of ERP with the local ER server.
> We should avoid that when possible. Implicit bootstrapping is a
> SHOULD. Implicit bootstrapping is also possible only if the peer can
> learn the domain name from the authenticator. Thus, there is a way for
> the peer and the server to establish that they are communicating with
> entities that advertise the same domain name. Now as long as we require
> all acct records from the same domain to use the Acct-Multi-Session-Id,
> we would have mitigated the fraud.
>
> thanks,
> Lakshminath
>
> >
> > 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.
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY@ietf.org
> > https://www.ietf.org/mailman/listinfo/hokey
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap
>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>