eap Mailing List: RE: Issue 286: Security

[Bernard Aboba (aboba]

> I do not claim myself to be a security expert. The fundamental question
> that I ask, is if it is fair thing to ask a service provider not to
> announce its presence when by the very nature of its business it needs
> to announce its presence to the maximum number of current and potential
> future customers?

It seems fair to enable the maximum degree of connectivity -- but this is
not the same as requiring that a AAA proxy announce its routing table
beyond the boundaries of the routing system.  Based on some of the
exchanges, my understanding is that there is some implicit "filtering"
that is to occur in the route announcements so that not all routes are
actually announced to the client.  But it is not clear to me from the
discussion exactly how this filter is defined, and what the impact is on
global reachability.

> 1) What is the issue with advertising presence of a service provider to
> all users before authentication has been done?

The exchanges have brought up at least three issues:

a)  Security.  In the Request/Response model the peer announces its
networks, then the AAA proxy replies with a subset of that set that it
supports.  In such an exchange a rogue proxy can learn the networks
supported by the client, but it is harder for a rogue client to learn all
the networks supported by a AAA proxy.  Are the threats in one model
inherently more serious than the other model?

b) Scalability.  As the number of supported networks grows, a
Request/Response model appears to scale better than a raw
announcement model.  In particular, a peer may only be expected to support
a relatively small number of networks, while a AAA proxy may support a
great many.  Therefore a Request/Response exchange can scale to a much
greater degree than a pure announcement model can, without having to
exceed the MTU size.

c) Reachability.  Given that a pure announcement model does not scale, the
question is what filters need to be applied in order to allow the
announcement to fit within an MTU.  The document appears to assume that a
"carrier" filter is being applied which prevents home AAA servers from
being advertised.  Glen has questioned whether this implicit roaming model
is articulated in the document, and whether that model is consistent with
RFC 2194 and RFC 2477.

> 2) Do not we do it today via SSID or PLMN ID etc? Do not the hotpsot
> operator try to announce themselve by trying to have a specific SSID for
> their customers and broadcasting it (it has its issues but they are
> relevant to this discussion). The hotspot operators can even announce
> their roaming partners today by using multiple SSIDs.

Today there are a number of models in use for SSID discovery/announcement.
For example, some vendors support both announced and "hidden" SSIDs.
Announced SSIDs are sent in Beacons, along with capabilities.  "Hidden"
networks can only be discovered via a Probe Request/Response.  So I think
the answer today is that *both* the broadcast and request/response
exchanges are supported.