eap Mailing List: Re: [HOKEY] ERX fraud issue

[Glen Zorn (gzorn]

Bernard_Aboba [at] hotmail.com <> scribbled on Wednesday, March 12, 2008 5:43
PM:

> 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 assertion seems to rely upon two assumptions. The first is that the
users connection time will necessarily be significantly longer than the
hand-over latency (true for 802.11 if the user is walking, more
problematic if the user is inside (or _is_) a moving vehicle.  The
second (and more obviously) false assumption is that the absolute length
of time taken by a hand-over is irrelevant because it will be "amortized
across the user's (sic) connection time".  Leaving aside the
questionable concepts of time mortgages (is there a time bank?  I want
to borrow a couple of hundred years ;-) connection time divination (how
do you know that the _future_ connection time will be long enough to
"amortize" anything?), this implies that it is only the ratio of
hand-over latency to connection time that is important.  If the
connection time is 6 months, is it OK for hand-over to take 10 minutes?
Obviously not, but that's what you seem to be saying...

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

I find it difficult to reconcile the descriptions given below with any
known definition of the term "property", most especially with the
definition that seems to be implied, that of a quality that is
inherently present in another thing (see further comments on the
individual 'properties').

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

This is what RFC 2865 says about the Class attribute:

5.25.  Class

   Description

      This Attribute is available to be sent by the server to the client
      in an Access-Accept and SHOULD be sent unmodified by the client to
      the accounting server as part of the Accounting-Request packet if
      accounting is supported.  The client MUST NOT interpret the
      attribute locally.

   A summary of the Class Attribute format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      25 for Class.

   Length

      >= 3

   String

      The String field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

There is just one more thing that RFC 2865 mention WRT this attribute:
it is listed as optional in Access-Accept messages but in an interesting
way: zero or more are allowed.  RFC 2866 says this about the Class
attribute: "A forwarding server MUST not modify existing Proxy-State or
Class attributes present in the packet."  It also allows zero or more
Class attributes in Accounting-Request packets.  Neither RFC 3579 nor
RFC 3748 even mention the Class attribute, nor does the Internet-Draft
describing the RADIUS design guidelines.  So one of the attributes upon
which the property in question depends appears to be a) practically
speaking undefined and b) strictly optional.  This begs the question:
Where does this 'property of AAA protocols' come from?  It's one thing
to claim that AAA protocols _should_ have certain properties, but
entirely another to claim that they already do: for the latter, one
would imagine that some supporting evidence would need to be present in
the relevant standards but that doesn't appear to be the case.

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

Leaving aside the technical problems with using an attribute intended
for usage with multilink PPP to track hand-offs, we need to ask how the
various access points obtain the correct value for the
Acct-Multi-Session-Id attribute and why those same techniques would be
unusable with hokey.  BTW, while the Acct-Multi-Session-Id attribute is
considerably more completely defined than the Class attribute (at least
in the context of its intended usage with MLPP), it, too, is completely
optional & more than one may be included in an Accounting-Request.

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

Since Property 1 has been shown to be non-existent (at least as a
"property of AAA protocols") and Property 2 essentially does nothing to
prohibit the invention of new accounting sessions from whole cloth, this
is quite simply nonsense.  If you want to standardize the usage of the
Class attribute to provide the behavior you want, please try, but don't
claim that it already exists without any backup from at least some RFC.

...

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

And now, for something completely different ;-).  Since the user is
_always_ unaware of the very existence of AAA (let alone the particular
attributes in a AAA message or the keys requested in it), how, exactly
does the AAA protocol provide "proof that the user authorized" _any_ key
request?

...