| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
FYI... Of interest to these groups I'm sure...
-----Original Message-----
From: Bernard Aboba [mailto:bernarda@windows.microsoft.com] Sent: Friday, May 30, 2003 2:45 PM To: Mike Moreton; CONGDON,PAUL (HP-Roseville,ex1); stds-802-11@ieee.org Subject: RE: [802-11Technical] <TGi> 802.1X Controlled Port There is something of a misunderstanding relating to Section 6.7 that needs to be clarified both in IEEE 802.1X/D6 as well as in IEEE 802.11i. EAP is fundamentally a peer-to-peer protocol, and as a result, after a mutual authentication, both sides are capable of communicating. There is no need to do bi-direction authentication, for example, in order to enable exchange of Bridge PDUs in LinkSec. Yet, because of the Section 6.7 language this misunderstanding persists.
I believe that Section 6.7 needs to be clarified so as to make clear bi-directional authentication is required and for what reasons. As I understand it, the reason why this is needed for IEEE 802.11i adhoc has nothing to do with EAP, or even IEEE 802.1X but rather relates to specific issues encountered in IEEE 802.11 adhoc. For example, where different keys are needed in each direction and a single key will not suffice, or where the sequence space cannot be guaranteed to be distinct in each direction, it may be necessary to derive more than a single key. This is the requirement that is driving use of bi-directional authentication within IEEE 802.11i adhoc.
There really is no issue with respect to "asymmetry of the controlled/uncontrolled port". RFC 2284bis will make it clear that no such asymmetry exists within EAP or any encapsulating media such as IEEE 802.1X. In reality, each side of the conversation decides when they wish to enable communications and therefore a single mutual authentication is sufficient in many cases, including those considered by LINKSEC.
From:
owner-stds-802-11@majordomo.ieee.org
[mailto:owner-stds-802-11@majordomo.ieee.org] On Behalf Of Mike Moreton
Paul,
I'd strongly agree that TGi should make 802.1aa's recommendation mandatory.
I still think we need to adjust some of our informative text that implies that changing the state of the controlled port in the authenticator will also change the filtering state in the supplicant.
Mike.
Mike Moreton Synad Technologies Ltd.
-----Original
Message-----
Mike,
You are a draft behind. Check-out 802.1aa/D6 which has been available for weeks. The model in 802.1X is NOT significantly different and in fact the wording and latest changes have been designed explicitly for TGi. The text you site was a bug in my mind in D5, it has been replace with the following (perhaps still not perfect, but feel free to ballot on it in a few weeks when we run the D6 ballot - sorry for the length of this, but...):
6.7 Bi-directional and Mutual authentication The model of operation of 802.1X is one where the Supplicant is authenticated by the Authenticator, with the help of the Authentication Server function. At the conclusion of the authentication, the Authenticator decides whether or not to allow access to the Supplicant. In situations where bi-directional authentication is needed between a pair of systems connected by a common LAN segment, it is necessary for each system to adopt both Authenticator and Supplicant roles; operating as an Authenticator in order to authenticate the other system, and as a Supplicant in order to be authenticated by the other system. For example, this can be required within IEEE 802.11 in order to support ad-hoc authentication. Alternatively it may be desirable to protect a Bridged LAN from the attachment of additional unauthorized Bridges, and for the additional Bridges to protect themselves against being attached to an unauthorized Bridged LAN. In this case it would be appropriate for the Bridges to implement both Authenticator and Supplicant functionality (as illustrated in Figure 6-6). When two Bridges, A and B, first connect to each other, they would both initiate authentication exchanges. Once Bridge A successfully authenticates Bridge B, Bridge A's controlled Port would be authorized; however, data transfer between the Bridges can only take place once Bridge B has successfully authenticated Bridge A, resulting in Bridge B's controlled Port being Authorized. It should be noted that systems supporting bi-directional authentication need to be prepared for role reversal. That is, after completing authentication in one direction, the system formerly operating as an Authenticator may receive an EAP-Request from the system formerly operating as a Supplicant, indicating the desire to reverse the direction of authentication. Systems supporting bi-directional authentication typically authenticate based on locally stored credentials, using a locally implemented authentication method, so that they may operate without requiring assistance from backend authentication servers. However, this need not necessarily be the case. It is even possible, though uncommon, for a Supplicant to be assisted by a backend authentication server, so that an EAPRequest could be encapsulated within an Access-Request, and answered by an EAP-Response encapsulated within an Access-Response. This is permitted by RFC 2869bis, though support is optional on the backend authentication server. It should also be noted that from the point of view of security, two one-way authentication exchanges in each direction are not equivalent to a single mutual authentication exchange, since the two one-way authentication exchanges are not cryptographically bound together. For example, two EAP MD5 exchanges in each direction are vulnerable to man-in-the-middle and reflection attacks, whereas a single mutually authenticating exchange would not be, assuming that it derives a key that remains uncompromised by the attacker. The EAPOL protocol can be used with EAP methods that explicitly perform mutual authentication (for example, EAP-TLS). These particular EAP methods are intended to ensure that the Supplicant will only pass its credentials to a valid server. If the server fails to authenticate itself to the Supplicant then the Supplicant will terminate the authentication. However, if a Supplicant only terminates the authentication without blocking network access then this is a serious security risk because a rogue Authenticator could allow access to a network and the application layer networking facilities of the Supplicant would continue to operate despite the failed authentication. This could result in the Supplicant-protected system passing sensitive data through an untrusted entity. This specification currently only specifies the action taken by the Authenticator at the end of the authentication process (setting the controlled Port to Authorized or Unauthorized depending upon the outcome of the authentication); any action taken by the Supplicant when the port is unauthorized is currently undefined. It is strongly recommended that an implementation used in environments where rogue network access devices are easily implemented (such as 802.11 wireless networks) that the Supplicant should disable communication on its Port other than for the purposes of performing EAPOL protocol exchanges. This can be accomplished by implementing a filter mechanism that will pass all packets when the portStatus variable (of the Supplicant front-end state machine) is in the authorized state and filters all packets but EAPOL when portStatus is unauthorized. In addition, in such environments portValid should not be set to TRUE until a successful mutual authentication has occurred to prevent the rogue device from impersonating a non-EAPOL-capable device and causing the supplicant to transition from CONNECTING to AUTHENTICATED because it receives no responses to its EAPOL-Start.
Also, make sure you look at how the 'filtering' is specified in D6. We haven't gone all the way and created a controlled port on the supplicant because of the incompatibility that would have caused, but we have introduced the portStatus variable that controls whether the Supplicant should filter frames or not. I think TGi could make our 'recommendation' in 802.1aa/D6 a mandate quite easily... Paul
|