eap Mailing List: Re: Issue 376: Proposed Resolution (Section 2.2)

[Bernard Aboba (bernard_aboba]

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 [at] isp1. |    | Access  |/
    example.com"      -- ? -->| Network |
  also known             |    |    2    |\
    "employee123 [at] corp2.  |    +---------+ \
    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 "subscriber [at] isp1. |    | Access  |/
    example.com"      -- ? -->| Network |
  also known             |    |    2    |\
    "employee123 [at] corp2.  |    +---------+ \
    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.