2.2. Identity selection
As networks proliferate, it becomes more and more likely
that a given
user may have multiple identities and credential sets,
available for
use in different situations. For example, the user may
have an
account with one or more Public WLAN providers; a
corporate WLAN; one
or more wireless WAN providers. As a result, the user
has to decide
which credential set to use when presented with a
choice.
[BA] The above paragraph could use an example describing how
the choice
is typically made, in order to introduce the example.
Figure 1 illustrates a situation where the user realm may
not be
reachable from each potential access network. Access
Network 1 only
enables access to the realm "isp1.example.com"
whereas Access Network
3 enables access to the realm
"corp2.example.com" whereas Access
Network 2 enables access to both realms.
? ? +---------+
+------------------+
? | Access | |
|
O_/ _-->| Network |------>|
isp1.example.com |
/| / | 1 | _->|
|
| | +---------+ /
+------------------+
_/ _ | /
| +---------+ /
User "subscriber isp1. | | Access |/
example.com" -- ? -->| Network |
also known | | 2 |
"employee123corp2. | +---------+
example.com" |
| +---------+ _
+-------------------+
_ | Access | ->|
|
-->| Network |------>|
corp2.example.com |
| 3 | |
|
+---------+
+-------------------+
Figure 1: Two credentials, three possible access
networks
[BA] I think you need to fill in some more details on why
the
example above creates a problem.
Traditionally, hints useful in identity selection have
also been
provided out-of-band. For example, via the RFC 3017 XML
DTD
[RFC3017], a client can select between potential POPs,
and then based
on information provided in the DTD, determine the
appropriate NAI to
use with the selected point of attachment to the
network.
Where a fixed set of realms are always reachable from a
given
network, access network names can be used to infer realm
reachability. For example, IEEE 802.11 Access Points
provide the
SSID, though in some cases the station may not learn all
the SSIDs
supported by the given access point without probing for
them. In
IKEv2 [RFC4306], the identity of the responder (typically
the
security gateway) is provided as a part of the IKEv2
exchange.
To use this information for identity selection, the
client has to
match the access network name with the realm portion of a
valid
client identity. For example, the client may be
configured with the
network access names that have roaming contracts with
each of the
client's home realms.
It is also possible for hints to be embedded within
credentials. In
[RFC4334], usage hints are provided within certificates
used for
wireless authentication. This involves extending the
client's
certificate to include the SSIDs with which the
certificate can be
used.
Finally, some EAP implementations use the space after the
NUL
character in an EAP Identity Request to communicate some
parameters
for example listing realms supported for authentication.
The
Informational RFC [RFC4284] specifies the interpretation
of the field
beyond the NUL character when realms are to be
communicated.
[BA] I think we need to provide more information on why
out-of-band or
static configuration is not sufficient.
Suggest rewriting this section to:
2.2. Identity selection
As networks proliferate, it becomes more and more likely
that a
user may have multiple identities and credential sets,
available for
use in different situations. For example, the user may
have an
account with one or more Public WLAN providers; a
corporate WLAN;
and one or more wireless WAN providers.
Typically, the user will choose an identity and
corresponding credential
set based on the network chooses to connect to, perhaps
with additional
assistance provided by the chosen authentication
mechanism. For example,
if EAP-TLS is the authentication mechanism used with a
particular
network, then the user will select the appropriate
EAP-TLS client
certificate based in part on the list of trust anchors
provided by
the EAP-TLS server.
However, in access networks where roaming is enabled, the
mapping
between an access network and an identity/credential set
may not be
one to one. For example, it is possible for multiple
identities
to be usable on an access network or for a given identity
to
be usable on a single access network, which may or may
not be
available.
Figure 1 illustrates a situation where a user identity
may
not be usable on a potential access network. In this
case
access network 1 enables access to users within the
realm
"isp1.example.com" whereas access network
3 enables access to users within the realm
"corp2.example.com";
access network 2 enables access to users within both
realms.
? ? +---------+
+------------------+
? | Access | |
|
O_/ _-->| Network |------>|
isp1.example.com |
/| / | 1 | _->|
|
| | +---------+ /
+------------------+
_/ _ | /
| +---------+ /
User "subscriberisp1. | | Access |/
example.com" -- ? -->| Network |
also known | | 2 |
"employee123corp2. | +---------+
example.com" |
| +---------+ _
+-------------------+
_ | Access | ->|
|
-->| Network |------>|
corp2.example.com |
| 3 | |
|
+---------+
+-------------------+
Figure 1: Two credentials, three possible access
networks
In this situation, a user only possessing an identity
within the
"corp2.example.com" realm can only successfully
authenticate to
access networks 2 or 3; a user possessing an identity
within the
"isp1.example.com" realm can only successfully
authenticate to
access networks 1 or 2; a user possessing identities
within both
realms can connect to any of the access networks. The
question
is: how does the user figure out which access networks it
can
successfully authenticate to, preferrably prior to
choosing a
point of attachment?
Traditionally, hints useful in identity selection have
been
provided out-of-band. For example, the XML DTD described
in
[RFC3017] enables a client to select between potential
point of attachment as well as to select the NAI and
credentials
to use in authenticating with it.
Where all points of attachment within an access network
enable
authentication utilizing a set realms, selection of an
access
network provices knowledge of the identities that a
client
can use to successfully authenticate. For example, in
an
access network, the set of supported realms
corresponding
to network name can be pre-configured.
Of course, it may not be possible to determine the
available
access networks prior to authentication. For example,
in
802.11, not all SSIDs are broadcast, so that the
station may need to probe to locate a "hidden"
SSID. Also,
within IKEv2 [RFC4306], the responder identity
(typically
the security gateway) is provided as a part of the IKEv2
exchange.
It is also possible for hints to be embedded within
credentials. In
[RFC4334], usage hints are provided within certificates
used for
wireless authentication. This involves extending the
client's
certificate to include the SSIDs with which the
certificate can be
used.
However, there may be situations in which an access
network may
not accept a static set of realms at every point of
attachment. For
example, as part of a roaming agreement only points of
attachment
within a given region or country may be made available.
In these
situations, mechanisms such as hints embedded within
credentials or
pre-configuration of access network to realm mappings may
not be
sufficient. Instead, it is necessary for the client to
discover usable
identities dynamically.
This is the problem that RFC 4284 attempts to solve,
using the
EAP-Request/Identity to communicate a list of supported
realms.
However, the problems inherent in this approach are many,
as
discussed in Appendix A.1.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
