| RE: Resolution of 802.1X/EAP-SM issue | <– Date –> <– Thread –> |
From: John Vollbrecht (jrv umich.edu)
|
|
| Date: Wed, 14 Jan 2004 11:45:34 -0500 (EST) | |
I agree this is confusing, and I have also found it hard to follow. I am
now at the 802 Interim meeting and have had conversations with Jim Burns
about this, and we have a revised proposal. I wrote up a proposal which
was sent to a number of people, and Jim is planning to write the details.
The gist of the proposal is that
1. we don't change EAP at all, no new interface variable is needed. This means no dependency on producing new EAP documents.
2. we keep the possibility of running both two state machines at each machine, each could be supplicant and authenticator. Associated with each state machine is a variable, and for the physical port to be enabled, both variables must be set on. The variables currently exist, so only the mechanism for setting them changes. The proposal is to use the standard Success and Failure from EAP to set these variables, with no need to understand whether the authentication is "mutual".
Some cases are described below, and some implications of the change described after that. Cases:
a. A machine may be configured to have only one state machine (it is either a supplicant or an authenticator). This is the case covered by prior 802.1X. A supplicant only machine can talk to a authenticator only machine. By configuration the null variable in each machine is set to be always ON.
b. A machine configured to be both a authenticator and supplicant may talk to another that is also configured as an authenticator and supplicant. In this case when device comes up the supplicant will attempt to start a dialog with an authenticator. If each device has two state machines, two authentications will occur and both must succeed for the actual port to be enabled. This allows certain devices [e.g. bridges with nets behind them] to be connected and to get Unicast and Broadcast keys from both authentions.
A problem here is that that a lower device must decide which Unicast key
to use and must know about the two multicast keys. Solution to this is
considered out of scope for 802.11 but must be understood by protocols
that use the keys.
c. One device may configured as both supplicant and authenticator and the other as supplicant only. In this case the [authenticator] variable in the supplicant only device is configured on. The suplicant in the dual state machine will attempt to "start" but will get no answer and will timeout and set the variable to ON [this works this way to support the case where there is no authentication required by the device - I am not sure it is right, but this is the way it works]. Thus a device with a supplicant only state machine will work with a device with a authenticator state machine or with a machine with authenticator and supplicant state machine.
d. one machine may be configured with authenticator and supplicant machine and the other with only an autheniticator. This case will not work because the authenticator in the device with authenticator and supplicant will wait forever for a supplicant to start. The 802.1X document should be amended to make this case clear.
e. It is also true, as now, that two authenticator only or two supplicant only devices will not connect.
The above cases seem to be satisfactory but require some documentation to make clear the cases that will not work.
Some decision implications:
This proposal maintains the interface between 802.1X and EAP. The implications seem to be in making the distinction in what is done on each side of the interface. Authentication is done on the EAP side, and configuration of what eap method to use is done as part of total device configuration. 802.1X determines that the authentication is done, but assumes the configuration forced the correct configuration to be done.
This proposal assumes that the EAP method chosen by each device in each direction is configured. The EAP method determines what kind of authentication will be done, whether it is one way or mutual, whether it includes authorization at either or both ends, what keys it creates and derives. If this is configured correctly, then if mutual authentication is required, the configuration must ensure that only a method that supports this will be selected in the EAP negotiation.
The implication here is that the selection of the EAP method is part of the whole implementation of an 802.1X device. Defining the EAP methods that are allowed with an application is part of the protocol. In particular, 802.1X may have some requirements, and 802.11 may have additional requirements. The 802.1x requirements presumably should be in the 802.1X documentation, and the 802.11 added requirements should be in 802.11.
John
--On Wednesday, January 14, 2004 4:26 AM -0500 Nick Petroni <npetroni [at] cs.umd.edu> wrote:
The gist of the proposal is that
1. we don't change EAP at all, no new interface variable is needed. This means no dependency on producing new EAP documents.
2. we keep the possibility of running both two state machines at each machine, each could be supplicant and authenticator. Associated with each state machine is a variable, and for the physical port to be enabled, both variables must be set on. The variables currently exist, so only the mechanism for setting them changes. The proposal is to use the standard Success and Failure from EAP to set these variables, with no need to understand whether the authentication is "mutual".
Some cases are described below, and some implications of the change described after that. Cases:
a. A machine may be configured to have only one state machine (it is either a supplicant or an authenticator). This is the case covered by prior 802.1X. A supplicant only machine can talk to a authenticator only machine. By configuration the null variable in each machine is set to be always ON.
b. A machine configured to be both a authenticator and supplicant may talk to another that is also configured as an authenticator and supplicant. In this case when device comes up the supplicant will attempt to start a dialog with an authenticator. If each device has two state machines, two authentications will occur and both must succeed for the actual port to be enabled. This allows certain devices [e.g. bridges with nets behind them] to be connected and to get Unicast and Broadcast keys from both authentions.
A problem here is that that a lower device must decide which Unicast key
to use and must know about the two multicast keys. Solution to this is
considered out of scope for 802.11 but must be understood by protocols
that use the keys.
c. One device may configured as both supplicant and authenticator and the other as supplicant only. In this case the [authenticator] variable in the supplicant only device is configured on. The suplicant in the dual state machine will attempt to "start" but will get no answer and will timeout and set the variable to ON [this works this way to support the case where there is no authentication required by the device - I am not sure it is right, but this is the way it works]. Thus a device with a supplicant only state machine will work with a device with a authenticator state machine or with a machine with authenticator and supplicant state machine.
d. one machine may be configured with authenticator and supplicant machine and the other with only an autheniticator. This case will not work because the authenticator in the device with authenticator and supplicant will wait forever for a supplicant to start. The 802.1X document should be amended to make this case clear.
e. It is also true, as now, that two authenticator only or two supplicant only devices will not connect.
The above cases seem to be satisfactory but require some documentation to make clear the cases that will not work.
Some decision implications:
This proposal maintains the interface between 802.1X and EAP. The implications seem to be in making the distinction in what is done on each side of the interface. Authentication is done on the EAP side, and configuration of what eap method to use is done as part of total device configuration. 802.1X determines that the authentication is done, but assumes the configuration forced the correct configuration to be done.
This proposal assumes that the EAP method chosen by each device in each direction is configured. The EAP method determines what kind of authentication will be done, whether it is one way or mutual, whether it includes authorization at either or both ends, what keys it creates and derives. If this is configured correctly, then if mutual authentication is required, the configuration must ensure that only a method that supports this will be selected in the EAP negotiation.
The implication here is that the selection of the EAP method is part of the whole implementation of an 802.1X device. Defining the EAP methods that are allowed with an application is part of the protocol. In particular, 802.1X may have some requirements, and 802.11 may have additional requirements. The 802.1x requirements presumably should be in the 802.1X documentation, and the 802.11 added requirements should be in 802.11.
---- this is a bit involved/ complex, but I would be interested in comments.
John
--On Wednesday, January 14, 2004 4:26 AM -0500 Nick Petroni <npetroni [at] cs.umd.edu> wrote:
> As I recall, the resolution of the comment in IEEE 802.1X-D7.1 was that > an interface variable was needed so that EAP could indicate down to the > lower layers whether a protected result indication was received. > > Nick -- if you're out there listening.... can you help us clear this up?
Actually, I'm not sure I can. I am very confused about who is waiting for what to be put where. Picking up late on the many threads related to this topic has proven unsuccessful for me- I guess I should have been better at keeping up over vacation. It seems we are asking for SOMETHING to be put into the EAP SM, but that the group has not yet reached a consensus on what that somethingis. The way I understand the timeline is as (roughly) as follows:
1. 802.1X-D7.1 Ballot comment 15 was proposed and rejected for grounds that there was insufficient signaling from EAP SM.
2. A discussion was held offline to try to find a solution to this problem, the result was a conclusion that some mechanism to show knowledge of the other party's satisfaction was needed --> eapRemoteSuccess or something similar would be used.
3. Upon presentation to the EAP WG, discussion started as to why this is needed/what it means. To the best of my understanding, there is yet to be a consensus on the solution. I *think* the discussion of key-derivation and its implication of knowledge of the other party's acceptance has led to the conclusion that enough information is provided by the current interface (thereby rebutting #1 above - 1x does, in fact, have the info it needs).
4. Now the question seems to be if the keyAvailable variable is the only indication we want to provide and, if so, how to document it so this is clear. If not, do we want to set another signal in EAP that always has the same result as keyAvailable, but is semantically different in that it answers the exact question 1x is asking. I suppose we are also awaiting an argument playing devil's advocate as to why keyAvailable is not sufficient (if such an argument can be made).
The set of dependencies I see is - 802.1x is waiting for Pasi,Nick,John,Yoshihiro to produce an SM draft with a new variable
- Pasi et al. are waiting on the consensus of the group before producing a draft.
I am trying my best to come up to speed- any help clarifying is greatly appreciated.
Thanks, nick
> > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > It was both as I recall. The AAA attribute was clearly not necessary > > because of the requirements for key derivation and mutual auth. > > Since this wasn't required, the presence of the key could also be > > used by the pass-thru authenticator and thus the new interface > > variable also wasn't needed. Someone correct me if I'm out in the > > weeds. > _______________________________________________ > eap mailing list > eap [at] frascone.com > http://mail.frascone.com/mailman/listinfo/eap >
_______________________________________________ eap mailing list eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap
- Re: Resolution of 802.1X/EAP-SM issue, (continued)
- Re: Resolution of 802.1X/EAP-SM issue Bernard Aboba, January 14 2004
-
RE: Resolution of 802.1X/EAP-SM issue CONGDON,PAUL (HP-Roseville,ex1), January 13 2004
-
RE: Resolution of 802.1X/EAP-SM issue Bernard Aboba, January 14 2004
- RE: Resolution of 802.1X/EAP-SM issue Nick Petroni, January 14 2004
- RE: Resolution of 802.1X/EAP-SM issue John Vollbrecht, January 14 2004
-
RE: Resolution of 802.1X/EAP-SM issue Bernard Aboba, January 14 2004
-
RE: Resolution of 802.1X/EAP-SM issue John Vollbrecht, January 14 2004
- Re: Resolution of 802.1X/EAP-SM issue Jim Burns, January 14 2004
- RE: Resolution of 802.1X/EAP-SM issue Bernard Aboba, January 14 2004
Results generated by Tiger Technologies using MHonArc.