Subject: [eap] Issue 23: Content of the Identity Request Payload

From: [email-masked] (Bernard Aboba)
Date: Sun, 6 Oct 2002 03:33:42 -0700 (PDT)

Issue 23: Contents of Identity Request Payload
Submitter: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section: 5.1
Rationale/Explanation of issue:

Section 5.1 page 13 describes the Identity Type thusly:

The Identity Type is used to query the identity of the peer.
Generally, the Authenticator will issue this as the initial Request.
An optional displayable message MAY be included to prompt the Peer in
the case where there expectation of interaction with a user. A
Response MUST be sent to this Request with a Type of 1 (Identity).

This language is good as far as it goes, but I wonder if more formal rules
should be specified to enable the more mobile enviroments where EAP is
being applied? What I have in mind is that it is likely that many (most?)
users/devices will have different sets of credentials for many of the
security domains they visit. Each of these credentials will assign to the
user/device a different artificial and arbitrary "identity".

In the wireless roaming case, it is likely that a user will sometimes
cross domain boundaries without even knowing it, so the commonly cited
industry goal of "seamless" roaming would imply that the Identity Request
from the Authenticator should provide some hint as to which "identity" it
is expecting, i.e., which domain is in use. While the cited language above
does not preclude this, it does not specify any interoperable way of
accomplishing this goal.

The obvious suggestion would be to insert the domain name portion of the
NAI of the Authenticator in some standard way into the Identity Request.
The Peer could parse and then attempt to map this to the credentials it
should present to this particular Authenticator.

[BA] I think that there are a number of issues here:

1. How the Supplicant knows what NAI to present to the Authenticator,
if more than one is available.
2. What certificate the Supplicant presents when queried by the
Authenticator.
3. How to route the authentication itself, particularly
if EAP pre-authentication is used. (In this case, the
selected access point (and in the case of 802.11, SSID) is
not known at the time of authentication (assuming
that we are talking about a shared use AP advertising multiple
SSIDs).

Note that knowing the NAI of the Authenticator may not by itself
help answer these questions. In the case of wireless the AP is
also typically advertising its characteristics, which in the
case of 802.11 can include the SSID. Similar advertisements
have also been discussed in SEAMOBY.

So at the point at which EAP authentication occurs, the Supplicant
may have learned information about the AP, based on the L2 or
L3 advertisements.

So the question is how information to be added in the EAP
Identity-Request adds to (or possibly conflicts) with the
information in the advertisement.

For example, in 802.11 there are quite a few ways to implement
a shared use AP that can advertise multiple SSIDs. SSIDs
represent the networks to which the AP connects, which may is
often more useful than the NAI of the Authenticator itself.
For example, a single AP may advertise a roaming consortia SSID,
a WISP SSID, and maybe the SSID for a secure network. Each of
these SSIDs correspond to a different VLAN and access network.

---

From: [email-masked] (Jari Arkko)
Date: Sun, 06 Oct 2002 15:44:17 +0300

I have a few background questions before I can understand this
issue:

1) Are we sure that the NAI in the Identity *Response* is not
    sufficient to handle these situations? Assuming all the
    domains you visit are still within the same roaming
    group, this should work.

2) How are EAP peers expected to treat multiple identity
    requests? Presumably, these could be made for retransmission
    purposes or because the authenticator doesn't have any
    information about the given identity.

3) If need to solve this issue, would be better to work on
    advertisements or re-trials with other identities?

4) In a roaming group, what network domain should be advertised?
    The user is unlikely to know the local domain, but we can't
    list all the domains involved in the group. Are roaming groups
    always associated with a domain?

5) When certificates need to be presented, how are the currently
    available cert-based methods handling the domain issue? Does
    TLS allow you to specify the root for which you need the cert?

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 6 Oct 2002 08:21:52 -0700 (PDT)

>     domains you visit are still within the same roaming

I think the issue arises if the user has multiple identities, and if
insufficient information is available on the authenticator network to make
a decision on which Identity to use or credentials to present.

I am not sure that this is an issue for the NAI, so much as for
credentials (such as certificates).

I think it is reasonable to expect that prior to use of EAP, some
out-of-band information is available on the network to which the
authenticator connects. In the case of PPP, there is typically an ISP
phone book that was installed beforehand. In the case of 802.11 there are
the 802.11 Beacons and Probe Responses, which include the SSID. So if
the user's machine has a list of potential networks and the corresponding
NAIs to login to those networks, I think that is enough, without adding
hints in the Identity Request.

>     information about the given identity.

One can conceive of several identities being used in a single
authentication -- for example, a machine identity followed by
authentication, then a user identity request followed by another
authentication. I'm not sure how the peer knows which identity is being
requested, though.

Distinguishing retransmissions from new requests can be
handled via the Identifier.

>     advertisements or re-trials with other identities?

I think that advertisements handle some of it (NAI selection). However,
it's not clear to me how a peer determines which cert to use unless there
is an SSID or other field in the cert providing a hint. See:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-02.txt

>     always associated with a domain?

In 802.11, it is possible for an AP to advertise multiple SSIDs, one for
each network that it connects to. If it does this using multiple BSSIDs,
the "virtual APs" are indistinguishable from real APs. However, the SSID
is limited to 32 octets, so it cannot represent an arbitrary FQDN or
"realm" in the RFC 2486 sense.

>     TLS allow you to specify the root for which you need the cert?

The TLS certificate request payload includes acceptable certificate types
and CAs. However, it is still possible that this guidance will not
uniquely point to a client certificate.