Re: [HOKEY] ERX fraud issue

[Alan DeKok <aland@deployingradius.com>]

Bernard_Aboba@hotmail.com wrote:
> 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.

  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.

> 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. 

  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.

> 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.

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

> As it stands, the ERX-13 document does not specify
> checks that the AAA server should perform before
> issuing the requested DSRK. ...  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.

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

> 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.

  That would be best, I think.

  Alan DeKok.

--
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/>