Subject: ERX fraud issue

From: <[email-masked]>
Date: Wed, 12 Mar 2008 14:43:03 -0700

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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 13 Mar 2008 10:02:02 +0100

> charges can then be attached.

  One caveat: Yes, for EAP sessions.

  For hotspot or dial-up, the passwords are sent in clear-text.  This
gives the visited operators the ability to invent sessions.

> authentication attempt occurred. 

  Hokey restricts ERX to within one domain (I think Glen said that in
the meeting), so the above restriction will apply to Hokey, too.  This
means that the only vulnerability Hokey has to fraudulent operators is
their ability to use ERX to generate *multiple* authentications for the
same user.

  This fraud can be detected and prevented if Hokey ties each ERX
session to the original EAP session.  (It's not immediately obvious from
a scan of ERX-13 how this happens).  i.e. Any accounting stream from an
ERX authentication should be tied to the original EAP authentication.
The home server can then validate that it is receiving one, and only
one, accounting stream that results from an EAP authentication.

> bypassing AAA protocol anti-fraud protections.

  Largely, yes.  The above analysis does some risk mitigation on
subsequent activity.

> issuing the requested DSRK. ...  If the ERX

  I think that the ERX server MUST be within the same domain as the AAA
server: the visited domain.

> as existing fast handoff proposals

  That would be best, I think.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Mar 2008 07:20:25 -0700

> gives the visited operators the ability to invent sessions.

[BA] Fair enough. 
 
> their ability to use ERX to generate *multiple* authentications for the

[BA] This is where I get confused.  As far as I can tell, the DSRK request
can be inserted by *any* proxy on the path.  So I'm not sure how the
restrictions is implemented in practice. 

> one, accounting stream that results from an EAP authentication.

[BA] It would certainly help for the subsequent ERX accounting records to
be tied to the original EAP session (e.g. via use of the same Multi-Session-Id). 
But it would still be necessary to tie the ERX accounting records to
an authentication that terminates at the home ERX server, not just
the local ERX server. 

> server: the visited domain.

[BA] If the ERX server and AAA server are both in the visited domain, why refer
to a "local" ERX server and a "home" ERX server?  I thought that the 
applicability statement proposed refers to inter-domain use. 

>   That would be best, I think.

[BA] I agree that the restrictions you describe would address the issue,
but I'm still confused as to whether the solution scope includes those
restrictions or not.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 13 Mar 2008 15:59:54 +0100

> restrictions is implemented in practice.

  A proxy inserting a DSRK for the purposes of faking authentication
would presumably do so without the cooperation of the visited network.
The proxy would then have to filter the accounting traffic from the
visited network.

  This is where a 3 party *reconciliation* protocol would be beneficial.
 If the visitied network, proxies, and home network all share their
accounting data, fraud is easier to detect.

> be tied to the original EAP session (e.g. via use of the same

  Not many systems implement Multi-Session-Id.  It may be simpler just
to require the accounting records for the visited network to be
consistent.  i.e. when a user moves to a new NAS, the records could be
sent through the visited network AAA server, which could do the
necessary data massaging to create a canonical accounting stream.

> applicability statement proposed refers to inter-domain use.

  I think the "home" ERX server just complicates the issue.

> but I'm still confused as to whether the solution scope includes those

  Reviews && feedback are being solicited...

  Alan DeKok.

---

From: <[email-masked]>
Date: Thu, 13 Mar 2008 16:03:28 -0700

> The proxy would then have to filter the accounting traffic from the

[BA] Ah... so you are saying that the forgery can be detected by looking
for overlap in the time sequence of user activity?  This seems like a
fairly intensive check, though.

> If the visited network, proxies, and home network all share their

[BA] I was looking for something simpler, such as a mechanism that
would enable checking of a ERX auth exchange with the home server
against subsequent accounting records sent by the local ERX server.
For example, if the peer were to use ERX to tell the home server what
local domain it is in, then the home server could ensure that it only
accepts accounting records from that domain, and no other ones.

> necessary data massaging to create a canonical accounting stream.

[BA] That would be fine too, as long as the home server knows what
visited network the accounting data is supposed to come from.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 14 Mar 2008 10:52:37 +0100

> fairly intensive check, though.

  I'm saying that the home AAA server can detect multiple accounting
streams for one user, and conclude that fraud is involved.  The visited
network is therefore required (somewhat logically) to generate only one
accounting stream for a user, independent of how many times ERX is used.

  i.e. if the visited network permits the user to move between AP's, it
should be required to bear the burden of ensuring that the accounting
stream it generates is sane.

  Since we assume only one accounting stream from visited AAA to home
AAA, the fraud issue is limited.  Most networks bill on the basis of
time, and one stream can't have multiple start/stop times.  Other
networks bill on the basis of data usage, and visited networks can
already claim inflated numbers.  (i.e. it isn't a problem.)

> accepts accounting records from that domain, and no other ones.

  Since ERX is not for intra-domain handovers, I think it's best to

> visited network the accounting data is supposed to come from.

  The accounting stream is tied to the original EAP authentication,
which must carry information about the visited domain.  This information
doesn't have to be generated by the NAS.  It can be generated by the
visited domain, or by server (proxy/home) that accepts AAA traffic from
the visited domain.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Mar 2008 04:57:33 -0700

> already claim inflated numbers.  (i.e. it isn't a problem.)

[BA] By a "stream" you mean Accounting-Requests from a single NAS, right?
As the user moves between NASes, Accounting-Requests will be generated,
with Start/Stop to mark the beginning and end of a session on a particular
NAS. 

> leave this as a requirement on the visited AAA server, as below:

[BA]  So with ERX it is necessary to do a full EAP authentication every time
a peer enters a new domain? I guess that this is a consequence of not
being able to assume EMSK caching within the AAA server. 
 
> which must carry information about the visited domain.  

[BA] How is information about the visited domain encoded by the NAS?  
Looking at the document, it appears that the DSRK can be requested
by any ERX proxy along the path.  Does the AAA server assume that
whatever ERX proxy has submitted the request is valid before delivering
the key? Or is there information provided by the NAS that it is supposed
to check against?  For example, does it do a reverse PTR RR query
on the NAS-IP-Address Attribute and check that the proxy submitting
the DSRK request is within the same domain?

---

From: Alan DeKok <[email-masked]>
Date: Fri, 14 Mar 2008 13:28:43 +0100

> [BA] By a "stream" you mean Accounting-Requests from a single NAS, right?

  Yes and no.  From the point of view of the home server, there is *one*
user login.  This *should* translate into one accounting stream.  Which
NAS(es) generate that stream is a separate issue.

> with Start/Stop to mark the beginning and end of a session on a particular

  Yes.  These packets go through the visited AAA server, which talks to
the visited ERX server.  That visited AAA server SHOULD be made
responsible for reconciling accounting streams from disparate NASes in
it's local network.

> being able to assume EMSK caching within the AAA server.

  That's my interpretation of what was said in Hokey.

> [BA] How is information about the visited domain encoded by the NAS? 

  It doesn't need to be.  The proxy knows about the visited domain, and
can add that information to the AAA packet stream.  This may require
policy changes on those proxies, and maybe a new AAA attribute.  But it
won't require code changes.

> by any ERX proxy along the path.

  Yes.  I'm not sure I understand that part.  If the visited domain
implements ERX, it can terminate the ERX requests.  If it doesn't
implement ERX, then it can't proxy those requests.

  i.e. the only thing that makes sense to me is that the ERX proxies (if
any) are all within the visited domain.

>  Does the AAA server assume that

  Not really sure...

  Alan DeKok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 14 Mar 2008 12:12:42 -0400

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, [email-masked] wrote:
> Again, thanks for pointing out the specific issue here.  It is very helpful.
> 
> >  
> 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
> 
> >  
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > HOKEY mailing list
> > [email-masked]
> > 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
>