From gwz@cisco.com Mon Feb 18 02:49:24 2002 From: gwz@cisco.com (Glen Zorn) Date: Sun, 17 Feb 2002 18:49:24 -0800 Subject: [eap] test Message-ID: ~gwz Glen Zorn CTO Consulting Engineer Security and Integrity Group Consulting Engineering Cisco Systems PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769 FB97 FBCF 7DA4 9A2D 1963 From gwz@cisco.com Mon Feb 18 03:31:51 2002 From: gwz@cisco.com (Glen Zorn) Date: Sun, 17 Feb 2002 19:31:51 -0800 Subject: [eap] test Message-ID: ~gwz Glen Zorn CTO Consulting Engineer Security and Integrity Group Consulting Engineering Cisco Systems PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769 FB97 FBCF 7DA4 9A2D 1963 From aboba@internaut.com Mon Feb 18 04:52:06 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 17 Feb 2002 20:52:06 -0800 (PST) Subject: [eap] RFC 2284bis issues Message-ID: Over the last few months, we've collected quite a few issues for resolution in RFC 2284bis. Here are the list of issues that we have collected, and how I would propose to resolve them. Comments welcome. 1. IANA considerations. RFC 2284 does not include an IANA considerations section, and RFC 2284bis needs one. Some thoughts on what might be in such a section: a. Reservation of some of the Type space for future use. Should this be a single EAP method (255) or more of the space (e.g. 127-255)? b. Statement that IANA should not allocate two Type codes for a single EAP method. c. Statement about reclamation of unused Type allocations. It looks like several of the alllocated Type codes have never been used. d. Allocation of an EAP Type code for "Vendor Specific". I have in mind something like what RADIUS does with attribute 26. This could take the pressure off the Type space. e. Statement on allocation of EAP type codes. Should this be on request? By expert review? (e.g. by sending mail to the WG) By designated expert? Assuming that we have a vendor specific code, the criteria might be different, (e.g. a specification and expert review might be required). 2. State machine issues. There are a lot of these. RFC 2284 has only a short section describing in general terms what the protocol does. There is no detailed section describing the protocol exchange in more detail, or a formal state machine. These meaans that in many cases there is no clear answer to the question "what do you do if you receive packet X when you are in the midst of doing Y?" 3. Not allowing data traffic prior to completion of authentication. RFC 2284 doesn't state specifically that this is required, because it is required by PPP -- so it probably seemed obvious and not worth mentioning. But now that EAP can be used over a variety of media, this has become a point of confusion. Proposed resolution is to indicate that an authentication conversation, once initiated, must complete before data traffic can be sent. 4. EAP Success prior to mutual authentication. RFC 2284 does not include a state machine, but it seems to imply that the peer should consider authentication complete on receiving an EAP Success. Bill Arbaugh has pointed out that a client requiring mutual authentication should not consider itself "on the network" until that mutual authentication is complete, so this is broken. For example, if the peer is authenticating via a method supporting mutual auth (EAP TLS, EAP SRP, etc.) and an authenticator sends an EAP Success in the middle, the recommendation is that the text of RFC 2284bis be changed to note that the client SHOULD NOT bring up the interface and SHOULD disconnect. Comments? 5. Spoofed EAP Failure. Similarly, RFC 2284 seems to imply that a peer always considers themself disconnected when receiving an EAP Failure, although it does indicate that "alternative indications of success/failure" can be considered. What if an attacker spoofs an EAP Failure outside of an authentication conversation? What if other traffic is being received at the same time, indicating that the connection is in fact up? Can the peer ignore the EAP Failure? My recommendation is that the text clarify the meaning of "alternative indications" with respect to this scenario. I believe that 802.11 and PPP both have such alternative indications -- in the case of PPP, we have LCP Terminate, in 802.11 we have Disassociate or Deauthenticate. So typically the EAP Failure will be followed by an alternative indication, particularly if it occurs "out of the blue". I think that the EAP indicator can be ignored (sometimes? all the time?) if it is at odds with the alternative indication. 6. Authentication of the EAP Success. Bill suggests that an authenticator be added to the EAP Success message. My inclination is not to accept this suggestion since existing proposals (PEAP, TTLS) already support authentication and encryption of the entire EAP conversation. Comments? From karlfox@columbus.rr.com Wed Feb 20 15:11:31 2002 From: karlfox@columbus.rr.com (Karl Fox) Date: Wed, 20 Feb 2002 10:11:31 -0500 Subject: [eap] Is this list working? Message-ID: <5.1.0.14.2.20020220101056.0489d5f0@pop-server.columbus.rr.com> I haven't received any messages yet. Is eap@frascone.com working properly? Karl From jschnizl@cisco.com Wed Feb 20 15:39:44 2002 From: jschnizl@cisco.com (John Schnizlein) Date: Wed, 20 Feb 2002 10:39:44 -0500 Subject: [eap] Is this list working? In-Reply-To: <5.1.0.14.2.20020220101056.0489d5f0@pop-server.columbus.rr. com> Message-ID: <4.3.2.7.2.20020220103900.01954ea0@diablo.cisco.com> At 10:11 AM 2/20/2002, Karl Fox wrote: >I haven't received any messages yet. Is eap@frascone.com working properly? I got your "does this work?" message without any problem. ;-) From sjosefsson@rsasecurity.com Wed Feb 20 15:43:39 2002 From: sjosefsson@rsasecurity.com (Simon Josefsson) Date: Wed, 20 Feb 2002 16:43:39 +0100 Subject: [eap] Is this list working? In-Reply-To: <5.1.0.14.2.20020220101056.0489d5f0@pop-server.columbus.rr.com> (Karl Fox's message of "Wed, 20 Feb 2002 10:11:31 -0500") References: <5.1.0.14.2.20020220101056.0489d5f0@pop-server.columbus.rr.com> Message-ID: Karl Fox writes: > I haven't received any messages yet. Is eap@frascone.com working properly? Yes. Is it too late to ask for a BOF in Minneapolis? /Simon From karlfox@columbus.rr.com Wed Feb 20 16:03:06 2002 From: karlfox@columbus.rr.com (Karl Fox) Date: Wed, 20 Feb 2002 11:03:06 -0500 Subject: [eap] Is this list working? In-Reply-To: References: <5.1.0.14.2.20020220101056.0489d5f0@pop-server.columbus.rr.com> <5.1.0.14.2.20020220101056.0489d5f0@pop-server.columbus.rr.com> Message-ID: <5.1.0.14.2.20020220110253.05ae8040@pop-server.columbus.rr.com> Probably. Ask anyway! Karl At 10:43 AM 2/20/02, Simon Josefsson wrote: >Karl Fox writes: > >> I haven't received any messages yet. Is eap@frascone.com working properly? > >Yes. Is it too late to ask for a BOF in Minneapolis? > >/Simon From aboba@internaut.com Wed Feb 20 15:53:46 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 20 Feb 2002 07:53:46 -0800 (PST) Subject: [eap] RFC 2284bis issues Message-ID: Over the last few months, we've collected quite a few issues for resolution in RFC 2284bis. Here are the list of issues that we have collected, and how I would propose to resolve them. Comments welcome. 1. IANA considerations. RFC 2284 does not include an IANA considerations section, and RFC 2284bis needs one. Some thoughts on what might be in such a section: a. Reservation of some of the Type space for future use. Should this be a single EAP method (255) or more of the space (e.g. 127-255)? b. Statement that IANA should not allocate two Type codes for a single EAP method. c. Statement about reclamation of unused Type allocations. It looks like several of the alllocated Type codes have never been used. d. Allocation of an EAP Type code for "Vendor Specific". I have in mind something like what RADIUS does with attribute 26. This could take the pressure off the Type space. e. Statement on allocation of EAP type codes. Should this be on request? By expert review? (e.g. by sending mail to the WG) By designated expert? Assuming that we have a vendor specific code, the criteria might be different, (e.g. a specification and expert review might be required). 2. State machine issues. There are a lot of these. RFC 2284 has only a short section describing in general terms what the protocol does. There is no detailed section describing the protocol exchange in more detail, or a formal state machine. These meaans that in many cases there is no clear answer to the question "what do you do if you receive packet X when you are in the midst of doing Y?" 3. Not allowing data traffic prior to completion of authentication. RFC 2284 doesn't state specifically that this is required, because it is required by PPP -- so it probably seemed obvious and not worth mentioning. But now that EAP can be used over a variety of media, this has become a point of confusion. Proposed resolution is to indicate that an authentication conversation, once initiated, must complete before data traffic can be sent. 4. EAP Success prior to mutual authentication. RFC 2284 does not include a state machine, but it seems to imply that the peer should consider authentication complete on receiving an EAP Success. Bill Arbaugh has pointed out that a client requiring mutual authentication should not consider itself "on the network" until that mutual authentication is complete, so this is broken. For example, if the peer is authenticating via a method supporting mutual auth (EAP TLS, EAP SRP, etc.) and an authenticator sends an EAP Success in the middle, the recommendation is that the text of RFC 2284bis be changed to note that the client SHOULD NOT bring up the interface and SHOULD disconnect. Comments? 5. Spoofed EAP Failure. Similarly, RFC 2284 seems to imply that a peer always considers themself disconnected when receiving an EAP Failure, although it does indicate that "alternative indications of success/failure" can be considered. What if an attacker spoofs an EAP Failure outside of an authentication conversation? What if other traffic is being received at the same time, indicating that the connection is in fact up? Can the peer ignore the EAP Failure? My recommendation is that the text clarify the meaning of "alternative indications" with respect to this scenario. I believe that 802.11 and PPP both have such alternative indications -- in the case of PPP, we have LCP Terminate, in 802.11 we have Disassociate or Deauthenticate. So typically the EAP Failure will be followed by an alternative indication, particularly if it occurs "out of the blue". I think that the EAP indicator can be ignored (sometimes? all the time?) if it is at odds with the alternative indication. 6. Authentication of the EAP Success. Bill suggests that an authenticator be added to the EAP Success message. My inclination is not to accept this suggestion since existing proposals (PEAP, TTLS) already support authentication and encryption of the entire EAP conversation. Comments? From jrv@interlinknetworks.com Wed Feb 20 16:50:27 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Wed, 20 Feb 2002 11:50:27 -0500 Subject: [eap] RFC 2284bis issues References: Message-ID: <3C73D3D3.CBAAD9E0@interlinknetworks.com> Some comments in line- Bernard Aboba wrote: > Over the last few months, we've collected quite a few issues for > resolution in RFC 2284bis. Here are the list of issues that we have > collected, and how I would propose to resolve them. Comments welcome. > > 1. IANA considerations. RFC 2284 does not include an IANA considerations > section, and RFC 2284bis needs one. Some thoughts on what might be in such > a section: > > a. Reservation of some of the Type space for future use. Should this be > a single EAP method (255) or more of the space (e.g. 127-255)? > > b. Statement that IANA should not allocate two Type codes for a single > EAP method. > > c. Statement about reclamation of unused Type allocations. It looks > like several of the alllocated Type codes have never been used. > > d. Allocation of an EAP Type code for "Vendor Specific". I have in > mind something like what RADIUS does with attribute 26. This could > take the pressure off the Type space. > This seems a very good idea. > > e. Statement on allocation of EAP type codes. Should this be on > request? By expert review? (e.g. by sending mail to the WG) By > designated expert? Assuming that we have a vendor specific code, > the criteria might be different, (e.g. a specification and expert > review might be required). > This is also a good idea - some review seems reasonable, especially if we have a Vendor specific type > > 2. State machine issues. There are a lot of these. RFC 2284 has only a > short section describing in general terms what the protocol does. There > is no detailed section describing the protocol exchange in more detail, > or a formal state machine. These meaans that in many cases there is no > clear answer to the question "what do you do if you receive packet X when > you are in the midst of doing Y?" > Also a good idea. > > 3. Not allowing data traffic prior to completion of authentication. RFC > 2284 doesn't state specifically that this is required, because it is > required by PPP -- so it probably seemed obvious and not worth > mentioning. But now that EAP can be used over a variety of media, this > has become a point of confusion. > Here I think there is some conceptual conversation that needs to take place. There are different ways to think about EAP. One is to see it as a decision making protocol for Access control. Another is as a protocol between two end points that use it to make decisions AND possibly other things, and not just for access control applications. > > Proposed resolution is to indicate that an authentication conversation, once > initiated, must complete before data traffic can be sent. > > 4. EAP Success prior to mutual authentication. RFC 2284 does not > include a state machine, but it seems to imply that the peer should > consider authentication complete on receiving an EAP Success. Bill Arbaugh > has pointed out that a client requiring mutual authentication should not > consider itself "on the network" until that mutual authentication is > complete, so this is broken. or the client should not accept a "success" from the server if it is doing mutual authentication. I must decide for itself if the other side has successfully authenticated > > > For example, if the peer is authenticating via a method supporting > mutual auth (EAP TLS, EAP SRP, etc.) and an authenticator sends an EAP > Success in the middle, the recommendation is that the text of RFC 2284bis > be changed to note that the client SHOULD NOT bring > up the interface and SHOULD disconnect. Comments? > This needs clarification as you say. Again I think it is the clients job (or 802.11 or 802.1x)'s job to spell out what the client must do. > > 5. Spoofed EAP Failure. Similarly, RFC 2284 seems to imply that a peer > always considers themself disconnected when receiving an EAP Failure, > although it does indicate that "alternative indications of > success/failure" can be considered. What if an attacker spoofs an EAP > Failure outside of an authentication conversation? What if other traffic > is being received at the same time, indicating that the connection is in > fact up? Can the peer ignore the EAP Failure? > I agree > > My recommendation is that the text clarify the meaning of "alternative > indications" with respect to this scenario. I believe that 802.11 and PPP > both have such alternative indications -- in the case of PPP, we have LCP > Terminate, in 802.11 we have Disassociate or Deauthenticate. So typically > the EAP Failure will be followed by an alternative indication, > particularly if it occurs "out of the blue". I think that the EAP > indicator can be ignored (sometimes? all the time?) if it is at odds with > the alternative indication. > seems a state machine could help here > > 6. Authentication of the EAP Success. Bill suggests that an authenticator > be added to the EAP Success message. My inclination is not to accept this > suggestion since existing proposals (PEAP, TTLS) already support > authentication and encryption of the entire EAP conversation. Comments? > I think the success message needs to be talked about more. It is used to indicate a successful completion of a method as far as one end of the method is concerned. It also is used to signal the end of the EAP session. I would like to talk about how to concatenate EAP methods - for example to do anuthentication with one method (e.g. TLS) and negotiating a QOS with another method, before terminating the EAPsession. - John From aboba@internaut.com Wed Feb 20 16:39:02 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 20 Feb 2002 08:39:02 -0800 (PST) Subject: [eap] RFC 2284bis issues In-Reply-To: <3C73D3D3.CBAAD9E0@interlinknetworks.com> Message-ID: > This seems a very good idea. Look for some initial ideas on how to do this in: http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-vendor-00.txt http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-00.txt > Here I think there is some conceptual conversation that needs to take place. > There are different ways to think about EAP. One is to see it as a decision > making protocol for Access control. Another is as a protocol between two end > points that use it to make decisions AND possibly other things, and not just for > access control applications. Want to stake out a position? > or the client should not accept a "success" from the server if it is doing > mutual authentication. I must decide for itself if the other side has > successfully authenticated If the client does not accept a "success" how does it know when the server has granted access to the network? It seems like the "ok to get on the network" state is reached as a result of two things where there is mutual auth: 1. Server authenticates itself to client (method specific) 2. Client authenticates itself to server (indicated by EAP Success) Note that in RFC 2284bis there is an open issue as to whether a client can send an EAP Success to a server. > This needs clarification as you say. Again I think it is the clients job (or > 802.11 or 802.1x)'s job to spell out what the client must do. Surely this doesn't depend on the underlying media, does it? Shouldn't the "access granted" state be defined within the EAP state machine as opposed to in the PPP/802.1X/802.11 state machines? > > fact up? Can the peer ignore the EAP Failure? > I agree This presumes that there is an "authenticating state" in which EAP Failures are accepted, and that these packets can be thrown away in other client states. > > My recommendation is that the text clarify the meaning of "alternative > > indications" with respect to this scenario. I believe that 802.11 and PPP > > both have such alternative indications -- in the case of PPP, we have LCP > > Terminate, in 802.11 we have Disassociate or Deauthenticate. So typically > > the EAP Failure will be followed by an alternative indication, > > particularly if it occurs "out of the blue". I think that the EAP > > indicator can be ignored (sometimes? all the time?) if it is at odds with > > the alternative indication. > > > seems a state machine could help here Yes -- the trick is that if it is an EAP state machine, it has to include support for L2 triggers. In some media such triggers exist, and in other media they do not. For example, in PPP we have LCP-Terminate, in 802.11 we have Disassociate as alternative failure indications. In generic IEEE 802 we do not have an equivalent. Similarly, in terms of success in PPP we have NCP, but I don't think there is an equivalent in 802.11 or generic 802. > I think the success message needs to be talked about more. It is used to > indicate a successful completion of a method as far as one end of the method is > concerned. It also is used to signal the end of the EAP session. I would like > to talk about how to concatenate EAP methods - for example to do anuthentication > with one method (e.g. TLS) and negotiating a QOS with another method, before > terminating the EAPsession. The RFC 2284bis text suggests that since EAP Success ends the conversation (if only because it cannot be ACK'd), that this only be sent after all the methods have completed. So if you want multiple methods, after a method succeeds, instead of sending EAP Success, you just start the new method. So you could do: EAP Identity Request/Response EAP Type=Foo Request/Responses [EAP Identity Request/Response] EAP Type=Bar Request/Responses [EAP Identity Request/Response] EAP Type=Gump Request/Response EAP Success This presumes that EAP Types Foo, Bar and Gump all suceeded. From jrv@interlinknetworks.com Wed Feb 20 18:37:29 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Wed, 20 Feb 2002 13:37:29 -0500 Subject: [eap] RFC 2284bis issues References: Message-ID: <3C73ECE9.8C36C0ED@interlinknetworks.com> Bernard Aboba wrote: > > This seems a very good idea. > > Look for some initial ideas on how to do this in: > http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-vendor-00.txt > http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-00.txt > > > Here I think there is some conceptual conversation that needs to take place. > > There are different ways to think about EAP. One is to see it as a decision > > making protocol for Access control. Another is as a protocol between two end > > points that use it to make decisions AND possibly other things, and not just for > > access control applications. > > Want to stake out a position? sure - I would argue that EAP should be the basis for a conversation between end points. In 802.1X terms this would be the STA and AS. Converstion between the STA and AP should be outside this. The problem that arises is that the AP and STA have "side" EAP conversations that get confused with the conversation between STA and AS. Unconfusing this would be a priority for me in the revised EAP doc. > > > > or the client should not accept a "success" from the server if it is doing > > mutual authentication. I must decide for itself if the other side has > > successfully authenticated > > If the client does not accept a "success" how does it know when the server > has granted access to the network? It seems like the "ok to get on the > network" state is reached as a result of two things where there is mutual > auth: > 1. Server authenticates itself to client (method specific) > 2. Client authenticates itself to server (indicated by EAP Success) > I would argue that granting access to the net is the APs job, not the AS. The AS is having the EAP conversation. Initiating access is different than authenticating. Success could be used to say I am happy with the conversation so far, but not to say "start access" > > Note that in RFC 2284bis there is an open issue as to whether a client can > send an EAP Success to a server. > yes - this needs conversation as well, but I would argue that the client should be able to send a Success. > > > This needs clarification as you say. Again I think it is the clients job (or > > 802.11 or 802.1x)'s job to spell out what the client must do. > > Surely this doesn't depend on the underlying media, does it? Shouldn't > the "access granted" state be defined within the EAP state machine as > opposed to in the PPP/802.1X/802.11 state machines? Well I think that the AS can decide that access is ok, but it is the APs job to make it happen. APs may have different ways of initiating stuff. Certainly a 802.1x ethernet switch supporting EAP/MD5 may not require a session key, while an 802.11AP will require a session key. > > > > > fact up? Can the peer ignore the EAP Failure? > > I agree > > This presumes that there is an "authenticating state" in which EAP > Failures are accepted, and that these packets can be thrown away in other > client states. > hmm - is this a state machine issue? I think there is an authenticating state where Success and Failure mean something. An EAP failure out of the blue should not be taken seriously. > > > > My recommendation is that the text clarify the meaning of "alternative > > > indications" with respect to this scenario. I believe that 802.11 and PPP > > > both have such alternative indications -- in the case of PPP, we have LCP > > > Terminate, in 802.11 we have Disassociate or Deauthenticate. So typically > > > the EAP Failure will be followed by an alternative indication, > > > particularly if it occurs "out of the blue". I think that the EAP > > > indicator can be ignored (sometimes? all the time?) if it is at odds with > > > the alternative indication. > > > > > seems a state machine could help here > > Yes -- the trick is that if it is an EAP state machine, it has to include > support for L2 triggers. In some media such triggers exist, and in other > media they do not. For example, in PPP we have LCP-Terminate, in 802.11 we > have Disassociate as alternative failure indications. In generic IEEE 802 > we do not have an equivalent. Similarly, in terms of success in PPP we > have NCP, but I don't think there is an equivalent in 802.11 or generic > 802. > This is why I would like to get EAP and the L2 triggers separated. 802.11 has used EAPOL to do two things, and I am think it has made for a lot of confusion. Do you know what EAP/SIP does this way? > > > I think the success message needs to be talked about more. It is used to > > indicate a successful completion of a method as far as one end of the method is > > concerned. It also is used to signal the end of the EAP session. I would like > > to talk about how to concatenate EAP methods - for example to do anuthentication > > with one method (e.g. TLS) and negotiating a QOS with another method, before > > terminating the EAPsession. > > The RFC 2284bis text suggests that since EAP Success ends the conversation > (if only because it cannot be ACK'd), that this only be sent after all the > methods have completed. So if you want multiple methods, after a method > succeeds, instead of sending EAP Success, you just start the new > method. So you could do: > > EAP Identity Request/Response > EAP Type=Foo Request/Responses > [EAP Identity Request/Response] > EAP Type=Bar Request/Responses > [EAP Identity Request/Response] > EAP Type=Gump Request/Response > EAP Success > > This presumes that EAP Types Foo, Bar and Gump all suceeded. If you want to ping pong methods (have a client initiate a method) one would like to know that the other end is happy so far before starting the next method. My reading is that this (client start of method) is not possible now, but I would be curious if this seems useful to others. It could allow each end to do different authentication of the other. John From aboba@internaut.com Wed Feb 20 18:35:00 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 20 Feb 2002 10:35:00 -0800 (PST) Subject: [eap] RFC 2284bis issues In-Reply-To: <3C73ECE9.8C36C0ED@interlinknetworks.com> Message-ID: > The problem that arises is that the AP and STA have "side" EAP conversations that get > confused with the conversation between STA and AS. Unconfusing this would be a > priority for me in the revised EAP doc. Are you referring to the EAP Identity exchange? > Success could be used to say I am happy with the conversation so far, but not to say > "start access" >From a technical point of view, the AS communicates that it wishes the NAS/AP to "grant access" through the AAA message, *not* via the encapsulated EAP frame if there is one. So you can have: 1. Access-Accept + EAP-Message/EAP-Failure 2. Access-Reject + EAP-Message/EAP-Success 3. Access-Accept + no EAP-Message attribute 4. Access-Reject + no EAP-Message attribute Note that in case 1, if the EAP frame is decapsulated and sent, the client can think that it failed authentication, whereas access can be granted by the NAS/AP. In case 2, the client thinks it succeeded, but the NAS/AP denies access. In case 3, the NAS/AP grants access, but the client never finds out what the result is. In case 4, the NAS/AP denies access, but the client doesn't get a result. You can argue that this is where "alternative indications of success/failure" come in. Or you can argue (as 802.1X did) that the NAS/AP should "manufacture" the appropriate Success/Failure packet based on the Accept/Reject result to make sure that things are always consistent. > yes - this needs conversation as well, but I would argue that the client should be > able to send a Success. What would such as Success mean to the NAS/AP? Does this serve as an ACK of the Success sent by the NAS/AP? > Well I think that the AS can decide that access is ok, but it is the APs job to make > it happen. APs may have different ways of initiating stuff. Certainly a 802.1x > ethernet switch supporting EAP/MD5 may not require a session key, while an 802.11AP > will require a session key. So you're saying that the definition of the "authenticated" state is media-dependent? > hmm - is this a state machine issue? I think there is an authenticating state where > Success and Failure mean something. An EAP failure out of the blue should not be > taken seriously. Yes, I think this is a state machine issue. Same with an EAP Success, presumably. > This is why I would like to get EAP and the L2 triggers separated. The RFC 2284 text that refers to L2 triggers is the "alternative indication" text. That text was put in there presumably because the Success and Failure messages are not ACK'd. Is this the only reason that L2 triggers need to be taken into account within the EAP state machine? > If you want to ping pong methods (have a client initiate a method) one would like to > know that the other end is happy so far before starting the next method. My reading > is that this (client start of method) is not possible now, but I would be curious if > this seems useful to others. It could allow each end to do different authentication > of the other. Yes, RFC 2284 seems to imply that the additional methods must be server initiated. This is perhaps another place where L2 triggers intervene. PPP is inherently peer-to-peer. 802.1X (bless its pointy little head) is not. So in PPP, the client could presumably turn around and start an authentication conversation in the other direction. In 802.1X that would require both implementation of dual roles on each peer (Supplicant and Authenticator). I don't even want to think about what PIC (draft-ietf-ipsra-pic-05.txt) does... From jrv@interlinknetworks.com Wed Feb 20 19:38:18 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Wed, 20 Feb 2002 14:38:18 -0500 Subject: [eap] RFC 2284bis issues References: Message-ID: <3C73FB29.D4BE7786@interlinknetworks.com> Bernard Aboba wrote: > > The problem that arises is that the AP and STA have "side" EAP conversations that get > > confused with the conversation between STA and AS. Unconfusing this would be a > > priority for me in the revised EAP doc. > > Are you referring to the EAP Identity exchange? > yes, and the Success from the AP to the STA, which is independent of what the AS to AP EAP message (in an Access Accept) is. > > > Success could be used to say I am happy with the conversation so far, but not to say > > "start access" > > From a technical point of view, the AS communicates that it wishes the > NAS/AP to "grant access" through the AAA message, *not* via the > encapsulated EAP frame if there is one. > > So you can have: > > 1. Access-Accept + EAP-Message/EAP-Failure > 2. Access-Reject + EAP-Message/EAP-Success > 3. Access-Accept + no EAP-Message attribute > 4. Access-Reject + no EAP-Message attribute > > Note that in case 1, if the EAP frame is decapsulated and sent, the client > can think that it failed authentication, whereas access can be granted by > the NAS/AP. In case 2, the client thinks it succeeded, but the NAS/AP > denies access. > > In case 3, the NAS/AP grants access, but the client never finds out what > the result is. In case 4, the NAS/AP denies access, but the client doesn't > get a result. > > You can argue that this is where "alternative indications of > success/failure" come in. Or you can argue (as 802.1X did) that the NAS/AP > should "manufacture" the appropriate Success/Failure packet based on the > Accept/Reject result to make sure that things are always consistent. > I would argue that the EAP message in an Access Accept should be forwarded to the STA by the AP. It tells the STA wheter the AS is happy with the authentication dialog. Using the EAP Success to indicate session initiation creates a situation where the STA doesn't know if it is talking to the AS or the AP. > > > yes - this needs conversation as well, but I would argue that the client should be > > able to send a Success. > > What would such as Success mean to the NAS/AP? Does this serve as an ACK > of the Success sent by the NAS/AP? > > > Well I think that the AS can decide that access is ok, but it is the APs job to make > > it happen. APs may have different ways of initiating stuff. Certainly a 802.1x > > ethernet switch supporting EAP/MD5 may not require a session key, while an 802.11AP > > will require a session key. > > So you're saying that the definition of the "authenticated" state is > media-dependent? > no I'm arguing that what one does as a result of an authentication is different for different applications. > > > hmm - is this a state machine issue? I think there is an authenticating state where > > Success and Failure mean something. An EAP failure out of the blue should not be > > taken seriously. > > Yes, I think this is a state machine issue. Same with an EAP Success, > presumably. > > > This is why I would like to get EAP and the L2 triggers separated. > > The RFC 2284 text that refers to L2 triggers is the "alternative > indication" text. That text was put in there presumably because the > Success and Failure messages are not ACK'd. Is this the only reason that > L2 triggers need to be taken into account within the EAP state machine? > > > If you want to ping pong methods (have a client initiate a method) one would like to > > know that the other end is happy so far before starting the next method. My reading > > is that this (client start of method) is not possible now, but I would be curious if > > this seems useful to others. It could allow each end to do different authentication > > of the other. > > Yes, RFC 2284 seems to imply that the additional methods must be server > initiated. This is perhaps another place where L2 triggers intervene. PPP > is inherently peer-to-peer. 802.1X (bless its pointy little head) is > not. So in PPP, the client could presumably turn around and start an > authentication conversation in the other direction. In 802.1X that would > require both implementation of dual roles on each peer (Supplicant and > Authenticator). > > I don't even want to think about what PIC > (draft-ietf-ipsra-pic-05.txt) does... A state machine would be very helpful here. From gwz@cisco.com Wed Feb 20 21:23:02 2002 From: gwz@cisco.com (Glen Zorn) Date: Wed, 20 Feb 2002 13:23:02 -0800 Subject: [eap] Is this list working? In-Reply-To: Message-ID: > > I haven't received any messages yet. Is eap@frascone.com > working properly? > > Yes. Is it too late to ask for a BOF in Minneapolis? Almost. The deadline is Friday. One of the things we need one of the multitude of volunteers to do is draft a BOF proposal & send it to the list for (quick) review... > > /Simon > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@interlinknetworks.com Wed Feb 20 22:07:34 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Wed, 20 Feb 2002 17:07:34 -0500 Subject: [eap] A straw man for EAP BOG writeup Message-ID: <3C741E26.B69A12AF@interlinknetworks.com> Here is a first cut at a proposal for an EAP BOF writeup. I am sure there are other things to add, and that what is on here may need clarification. If we have till Friday there isn't much time. There are a number of issues with EAP that may need to be cleaned up. Many of these issues are created because of the use of EAP with 802.1x in 802.11 wireless LAN authentication. EAP work currently is being done in the PPPext working group. Since many issues are not PPP related, it seems reasonable to consider having a wg that will deal with EAP specific issues. Some possible topics: 1. Clarify meaning of EAP success and failure message 2. Extend Method negotiation 3. Add Mutual authentication and Client initiated authentication 4. Recommended practices for AP/NAS - (rework EAP recommendations in RADIUS and extend to other possible protocols) 5. any special requirements for Diameter, COPS, others 6. role of key creation and cyphersuite negotiation (especially for 802.11 algorithms) and EAP 7. Add state diagram for EAP and interactions with clients some possible workitems for an EAP group Clean up EAP 2284bis and publish Revise RADIUS Ext 2869 Create EAP Recommended practices for Access Devices Things not to be included in EAP group Security Review of EAP algorithms (although it might want to help figure out where this would be done) From jacques_m_caron@yahoo.com Wed Feb 20 23:23:14 2002 From: jacques_m_caron@yahoo.com (Jacques Caron) Date: Thu, 21 Feb 2002 00:23:14 +0100 Subject: [eap] RFC 2284bis issues In-Reply-To: References: <3C73D3D3.CBAAD9E0@interlinknetworks.com> Message-ID: <5.1.0.14.0.20020221001246.037c0ec0@pop.mail.yahoo.com> At 17:39 20/02/2002, Bernard Aboba wrote: > > This seems a very good idea. > >Look for some initial ideas on how to do this in: >http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-vendor-00.txt >http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-00.txt > > > Here I think there is some conceptual conversation that needs to take > place. > > There are different ways to think about EAP. One is to see it as a > decision > > making protocol for Access control. Another is as a protocol between > two end > > points that use it to make decisions AND possibly other things, and not > just for > > access control applications. > >Want to stake out a position? I vote in favor of "can do other things". The great thing about EAP is that: - it occurs before an actual session starts (whatever that session is) - it is transmitted transparently, end-to-end, between the client and an AAA server, across the NAS/AP/whatever [note: it might be a good idea to finally come up with a generic term that means any of those -- might be a GAS, like Generic Access Server ;-)] This could be used for negotiation of quite a number of things (related to AAA's second A). John seems to think QoS parameters. I think presentation of cost to the user. There might be more. However, moving EAP from a single-method-then-success to a multiple-method-then-success model might have some implications for backwards compatibility. > > or the client should not accept a "success" from the server if it is doing > > mutual authentication. I must decide for itself if the other side has > > successfully authenticated > >If the client does not accept a "success" how does it know when the server >has granted access to the network? It seems like the "ok to get on the >network" state is reached as a result of two things where there is mutual >auth: > 1. Server authenticates itself to client (method specific) > 2. Client authenticates itself to server (indicated by EAP Success) > >Note that in RFC 2284bis there is an open issue as to whether a client can >send an EAP Success to a server. I think one big issue with Sucess and Failure comes from the fact they're not ACK'd, and hence cannot be NACK'd. In some cases, a client might want to refuse a connection to go further (which in some contexts would mean "start pumping cash out of my account") unless something else happened to the satisfaction of the client. >Yes -- the trick is that if it is an EAP state machine, it has to include >support for L2 triggers. In some media such triggers exist, and in other >media they do not. For example, in PPP we have LCP-Terminate, in 802.11 we >have Disassociate as alternative failure indications. In generic IEEE 802 >we do not have an equivalent I would get that most of the 802 media that support 802.1x (and hence are port-based) have a "link down" (or whatever the fancy name for that is in IEEE lingo) event? >. Similarly, in terms of success in PPP we >have NCP, but I don't think there is an equivalent in 802.11 or generic >802. Back to ACK'ing success/failure :-) Back to backwards compatibility issues :-( Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jsalowey@cisco.com Wed Feb 20 23:50:22 2002 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 20 Feb 2002 15:50:22 -0800 Subject: [eap] RFC 2284bis issues In-Reply-To: <3C73D3D3.CBAAD9E0@interlinknetworks.com> References: Message-ID: <4.3.2.7.2.20020220153737.045ecf00@e2k-sea-xch1.cisco.com> At 11:50 AM 2/20/2002 -0500, John Vollbrecht wrote: >Some comments in line- > >Bernard Aboba wrote: > > > Over the last few months, we've collected quite a few issues for > > resolution in RFC 2284bis. Here are the list of issues that we have > > collected, and how I would propose to resolve them. Comments welcome. > > > > 1. IANA considerations. RFC 2284 does not include an IANA considerations > > section, and RFC 2284bis needs one. Some thoughts on what might be in such > > a section: > > > > a. Reservation of some of the Type space for future use. Should this be > > a single EAP method (255) or more of the space (e.g. 127-255)? > > > > b. Statement that IANA should not allocate two Type codes for a single > > EAP method. > > > > c. Statement about reclamation of unused Type allocations. It looks > > like several of the alllocated Type codes have never been used. > > > > d. Allocation of an EAP Type code for "Vendor Specific". I have in > > mind something like what RADIUS does with attribute 26. This could > > take the pressure off the Type space. > > > >This seems a very good idea. I think if this is not done carefully then it can cause all sorts of interoperability problems. I would rather first see what vendor specific issues need to be addressed and address them in a standard way if possible. > > > > e. Statement on allocation of EAP type codes. Should this be on > > request? By expert review? (e.g. by sending mail to the WG) By > > designated expert? Assuming that we have a vendor specific code, > > the criteria might be different, (e.g. a specification and expert > > review might be required). > > > >This is also a good idea - some review seems reasonable, especially if we >have a >Vendor specific type I am in favor of some sort of review given my concern above. > > > > 2. State machine issues. There are a lot of these. RFC 2284 has only a > > short section describing in general terms what the protocol does. There > > is no detailed section describing the protocol exchange in more detail, > > or a formal state machine. These meaans that in many cases there is no > > clear answer to the question "what do you do if you receive packet X when > > you are in the midst of doing Y?" > > > >Also a good idea. agree > > > > 3. Not allowing data traffic prior to completion of authentication. RFC > > 2284 doesn't state specifically that this is required, because it is > > required by PPP -- so it probably seemed obvious and not worth > > mentioning. But now that EAP can be used over a variety of media, this > > has become a point of confusion. > > > >Here I think there is some conceptual conversation that needs to take place. >There are different ways to think about EAP. One is to see it as a decision >making protocol for Access control. Another is as a protocol between two end >points that use it to make decisions AND possibly other things, and not >just for >access control applications. I'm not sure I follow you here. I see EAP as a protocol for carrying out authentication and thats it. It is when we bring in other things such as access control that we have current problems because things become application specific. > > > > Proposed resolution is to indicate that an authentication conversation, > once > > initiated, must complete before data traffic can be sent. > > > > 4. EAP Success prior to mutual authentication. RFC 2284 does not > > include a state machine, but it seems to imply that the peer should > > consider authentication complete on receiving an EAP Success. Bill Arbaugh > > has pointed out that a client requiring mutual authentication should not > > consider itself "on the network" until that mutual authentication is > > complete, so this is broken. > >or the client should not accept a "success" from the server if it is doing >mutual authentication. I must decide for itself if the other side has >successfully authenticated I'm not so sure about this either. I would like to see the server send some indication that it thinks the authentication is complete. The client may have some processing left to do. Also the completeness and success refers to the authentication not the access control. > > > > > > For example, if the peer is authenticating via a method supporting > > mutual auth (EAP TLS, EAP SRP, etc.) and an authenticator sends an EAP > > Success in the middle, the recommendation is that the text of RFC 2284bis > > be changed to note that the client SHOULD NOT bring > > up the interface and SHOULD disconnect. Comments? > > > >This needs clarification as you say. Again I think it is the clients job (or >802.11 or 802.1x)'s job to spell out what the client must do. I think applications that use EAP need to define what happens with different authentication results. I do not think it is EAP's job to determine access control. > > > > 5. Spoofed EAP Failure. Similarly, RFC 2284 seems to imply that a peer > > always considers themself disconnected when receiving an EAP Failure, > > although it does indicate that "alternative indications of > > success/failure" can be considered. What if an attacker spoofs an EAP > > Failure outside of an authentication conversation? What if other traffic > > is being received at the same time, indicating that the connection is in > > fact up? Can the peer ignore the EAP Failure? > > > >I agree > > > > > My recommendation is that the text clarify the meaning of "alternative > > indications" with respect to this scenario. I believe that 802.11 and PPP > > both have such alternative indications -- in the case of PPP, we have LCP > > Terminate, in 802.11 we have Disassociate or Deauthenticate. So typically > > the EAP Failure will be followed by an alternative indication, > > particularly if it occurs "out of the blue". I think that the EAP > > indicator can be ignored (sometimes? all the time?) if it is at odds with > > the alternative indication. > > > >seems a state machine could help here > > > > > 6. Authentication of the EAP Success. Bill suggests that an authenticator > > be added to the EAP Success message. My inclination is not to accept this > > suggestion since existing proposals (PEAP, TTLS) already support > > authentication and encryption of the entire EAP conversation. Comments? > > > >I think the success message needs to be talked about more. It is used to >indicate a successful completion of a method as far as one end of the >method is >concerned. It also is used to signal the end of the EAP session. I would >like >to talk about how to concatenate EAP methods - for example to do >anuthentication >with one method (e.g. TLS) and negotiating a QOS with another method, before >terminating the EAPsession. > > >- John > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap From jsalowey@cisco.com Wed Feb 20 23:55:02 2002 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 20 Feb 2002 15:55:02 -0800 Subject: [eap] RFC 2284bis issues In-Reply-To: <3C73ECE9.8C36C0ED@interlinknetworks.com> References: Message-ID: <4.3.2.7.2.20020220155234.046266b0@e2k-sea-xch1.cisco.com> At 01:37 PM 2/20/2002 -0500, John Vollbrecht wrote: >Bernard Aboba wrote: > > > > This seems a very good idea. > > > > Look for some initial ideas on how to do this in: > > http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-vendor-00.txt > > http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-00.txt > > > > > Here I think there is some conceptual conversation that needs to take > place. > > > There are different ways to think about EAP. One is to see it as a > decision > > > making protocol for Access control. Another is as a protocol between > two end > > > points that use it to make decisions AND possibly other things, and > not just for > > > access control applications. > > > > Want to stake out a position? > >sure - I would argue that EAP should be the basis for a conversation >between end >points. In 802.1X terms this would be the STA and AS. Converstion >between the STA >and AP should be outside this. > >The problem that arises is that the AP and STA have "side" EAP >conversations that get >confused with the conversation between STA and AS. Unconfusing this would >be a >priority for me in the revised EAP doc. Okay, I'm confused. From aboba@internaut.com Thu Feb 21 01:13:35 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 20 Feb 2002 17:13:35 -0800 (PST) Subject: [eap] RFC 2284bis issues In-Reply-To: <5.1.0.14.0.20020221001246.037c0ec0@pop.mail.yahoo.com> Message-ID: > I would get that most of the 802 media that support 802.1x (and hence are > port-based) have a "link down" (or whatever the fancy name for that is in > IEEE lingo) event? Maybe. Most switches and NICs have carrier sense at this point, but then there is Ethernet over ATM :( Typically though, switches do not lower carrier when there is an EAP Failure so this is not really an alternative indication of failure. > Back to ACK'ing success/failure :-) Back to backwards compatibility issues :-( All in all, whenever we've left out ACK'ing of messages, it always seems to come back to bite us :( From aboba@internaut.com Thu Feb 21 01:21:18 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 20 Feb 2002 17:21:18 -0800 (PST) Subject: [eap] RFC 2284bis issues In-Reply-To: <4.3.2.7.2.20020220153737.045ecf00@e2k-sea-xch1.cisco.com> Message-ID: > I think if this is not done carefully then it can cause all sorts of > interoperability problems. I would rather first see what vendor specific > issues need to be addressed and address them in a standard way if possible. Not sure why interoperability problems should result assuming that an EAP Type is uniquely allocated for this purpose. If a client doesn't support it, it will NAK the request. Or am I missing something? > I am in favor of some sort of review given my concern above. Since the majority of IANA allocations to date are for protocols with no specification, it isn't clear to me that requiring a spec and review is viable without also enabling vendor-specific use. But if the vendor community is willing to live with this, I won't object :) > I'm not so sure about this either. I would like to see the server send some > indication that it thinks the authentication is complete. The client may > have some processing left to do. Also the completeness and success refers > to the authentication not the access control. That's enabled within RFC 2284 today. The client is not REQUIRED to start accessing the network just because it gets an EAP Success. It could, for example, decide to discard the EAP Success if mutual auth was not complete. From jsalowey@cisco.com Thu Feb 21 06:18:37 2002 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 20 Feb 2002 22:18:37 -0800 Subject: [eap] RFC 2284bis issues In-Reply-To: References: <4.3.2.7.2.20020220153737.045ecf00@e2k-sea-xch1.cisco.com> Message-ID: <4.3.2.7.2.20020220214015.01ab5320@e2k-sea-xch1.cisco.com> At 05:21 PM 2/20/2002 -0800, Bernard Aboba wrote: > > I think if this is not done carefully then it can cause all sorts of > > interoperability problems. I would rather first see what vendor specific > > issues need to be addressed and address them in a standard way if possible. > >Not sure why interoperability problems should result assuming that an EAP >Type is uniquely allocated for this purpose. If a client doesn't support >it, it will NAK the request. Or am I missing something? No you're not, my worry is a bit more subtle, I don't think it will break existing things. I do worry that if there is something that should be added to EAP that is generally applicable which is only addressed in a vendor specific way that this will lead to interoperability problems. In general I support vendor specific extensions where the extension is vendor specific. If it is more generally applicable then I would like to see it addressed in a general way if it makes sense to do so within EAP. I don't want to see the vendor specific space become a catch all for things that should be in the spec (I don't want to see it become a catch all for things that shouldn't be either). > > I am in favor of some sort of review given my concern above. > >Since the majority of IANA allocations to date are for protocols with no >specification, it isn't clear to me that requiring a spec and review is >viable without also enabling vendor-specific use. But if the vendor >community is willing to live with this, I won't object :) I'm not sure of the feasibility of reviewing vendor specific extensions either, that's why I'd like to see things that are generally applicable in the base spec. > > I'm not so sure about this either. I would like to see the server send > some > > indication that it thinks the authentication is complete. The client may > > have some processing left to do. Also the completeness and success refers > > to the authentication not the access control. > >That's enabled within RFC 2284 today. The client is not REQUIRED to start >accessing the network just because it gets an EAP Success. It could, for >example, decide to discard the EAP Success if mutual auth was not >complete. True, I think what I was getting at here was that EAP-Success refers to the servers view of the state of authentication: it's done and doesn't expect anything more from the client. I also want to emphasize the distinction between authentication success or partial success and access control. The two are usually related, but one does not imply the other. What the client and server do with the knowledge that authentication has failed or succeeded should be outside of EAP. Joe From jacques_m_caron@yahoo.com Thu Feb 21 07:07:22 2002 From: jacques_m_caron@yahoo.com (Jacques Caron) Date: Thu, 21 Feb 2002 08:07:22 +0100 Subject: [eap] RFC 2284bis issues In-Reply-To: References: <4.3.2.7.2.20020220153737.045ecf00@e2k-sea-xch1.cisco.com> Message-ID: <5.1.0.14.0.20020221080517.05bfc530@pop.mail.yahoo.com> At 02:21 21/02/2002, Bernard Aboba wrote: >That's enabled within RFC 2284 today. The client is not REQUIRED to start >accessing the network just because it gets an EAP Success. It could, for >example, decide to discard the EAP Success if mutual auth was not >complete. But the EAP success usually means a successful auth, and the beginning of accounting. Maybe the client wants more before that is the case (see my example of cost advertisement somewhere else in the thread). Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From sjosefsson@rsasecurity.com Thu Feb 21 13:27:03 2002 From: sjosefsson@rsasecurity.com (Simon Josefsson) Date: Thu, 21 Feb 2002 07:27:03 -0600 Subject: [eap] RFC 2284bis issues Message-ID: <20020221132703.GL29510@newman.frascone.com> Bernard Aboba writes: > 1. IANA considerations. RFC 2284 does not include an IANA considerations > section, and RFC 2284bis needs one. Some thoughts on what might be in such > a section: > > a. Reservation of some of the Type space for future use. Should this be > a single EAP method (255) or more of the space (e.g. 127-255)? One value should be enough to extend the protocol syntax in the future, I don't see an argument for reserving one entire bit, but maybe I am missing something. > b. Statement that IANA should not allocate two Type codes for a single > EAP method. Yes. > c. Statement about reclamation of unused Type allocations. It looks > like several of the alllocated Type codes have never been used. > > d. Allocation of an EAP Type code for "Vendor Specific". I have in > mind something like what RADIUS does with attribute 26. This could > take the pressure off the Type space. I think this is too agressive. There is 31 EAP Request/Response types registered, we have 220 left. Extrapolating linearly tells us we will run out in 30-40 years. (Assuming registration started in 1997.) I think a better approach would be to let IANA continue to register EAP types, and to reserve 255 to mean that the first 16 bit of the Data field should be interpreted as a EAP type, where the first 255 values of that 16 bit field is reserved, and leave the control of that type space to IANA as well. This would allow you to plug in a multiplexing type 255 EAP mechanism in an old RFC 2284 implementation if needed. Of course RFC 2284bis and later implementations would support EAP type 255 internally. > e. Statement on allocation of EAP type codes. Should this be on > request? By expert review? (e.g. by sending mail to the WG) By > designated expert? Assuming that we have a vendor specific code, > the criteria might be different, (e.g. a specification and expert > review might be required). I think the current procedure (send email to IANA) is fine. Adding restrictions on how to register a EAP mechanism makes people just pick an unused one and not tell anyone. It also requires human resources to decide whether a registration is OK or not. Let's not create politics. /Simon ----- End forwarded message ----- From aboba@internaut.com Thu Feb 21 16:58:43 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 21 Feb 2002 08:58:43 -0800 (PST) Subject: [eap] Proposed EAP WG Charter Message-ID: To have an EAP WG, we need to have a Charter. Here's a first cut at an EAP WG Charter. The goal is to focus on cleaning up the EAP specification for the first 6 months, after which we can re-charter to work on additional items. ---------------------------------------------------------------- EAP Working Group (EAP) Chair(s): This space for rent Area Director(s): Thomas Narten Erik Nordmark Security Advisors: Bill Arbaugh Mailing Lists: General discussion: eap@frascone.com To subscribe: ? Archive: ? The EAP working group will restrict itself to the following short-term work items in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations. 2. Threat model and security considerations. 3. EAP state machine. 4. Clarification and documentation of EAP key usage. 5. Documentation of interaction between EAP and lower layers. 6. Resolution of interoperability issues. 7. Type space extension to support an expanded Type space. 8. Requirements for cryptographic protection of EAP. 9. Update of RFC 2869 (RADIUS/EAP) Goals and Milestones Jun 02 IANA considerations draft to RFC Editor. Jun 02 EAP type extension section for RFC 2284bis. Jun 02 EAP Security considerations section for RFC 2284bis. Jun 02 EAP state machine section for RFC 2284bis. Sep 02 RFC 2869bis published as Proposed Standard RFC. Sep 02 RFC 2284bis published as Proposed Standard RFC. Sep 02 EAP keying framework doc published as Informational RFC. From sblakewilson@certicom.com Thu Feb 21 16:56:53 2002 From: sblakewilson@certicom.com (Simon Blake-Wilson) Date: Thu, 21 Feb 2002 11:56:53 -0500 Subject: [eap] A straw man for EAP BOG writeup Message-ID: <85256B67.00642983.00@smtpmail.certicom.com> I think review of EAP methods, and standardization of new methods should be part of the proposal. Best regards. Simon John Vollbrecht on 02/20/2002 05:07:34 PM To: EAP cc: (bcc: Simon Blake-Wilson/Certicom) Subject: [eap] A straw man for EAP BOG writeup Here is a first cut at a proposal for an EAP BOF writeup. I am sure there are other things to add, and that what is on here may need clarification. If we have till Friday there isn't much time. There are a number of issues with EAP that may need to be cleaned up. Many of these issues are created because of the use of EAP with 802.1x in 802.11 wireless LAN authentication. EAP work currently is being done in the PPPext working group. Since many issues are not PPP related, it seems reasonable to consider having a wg that will deal with EAP specific issues. Some possible topics: 1. Clarify meaning of EAP success and failure message 2. Extend Method negotiation 3. Add Mutual authentication and Client initiated authentication 4. Recommended practices for AP/NAS - (rework EAP recommendations in RADIUS and extend to other possible protocols) 5. any special requirements for Diameter, COPS, others 6. role of key creation and cyphersuite negotiation (especially for 802.11 algorithms) and EAP 7. Add state diagram for EAP and interactions with clients some possible workitems for an EAP group Clean up EAP 2284bis and publish Revise RADIUS Ext 2869 Create EAP Recommended practices for Access Devices Things not to be included in EAP group Security Review of EAP algorithms (although it might want to help figure out where this would be done) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From sblakewilson@certicom.com Thu Feb 21 16:53:26 2002 From: sblakewilson@certicom.com (Simon Blake-Wilson) Date: Thu, 21 Feb 2002 11:53:26 -0500 Subject: [eap] RFC 2284bis issues Message-ID: <85256B67.00642983.00@smtpmail.certicom.com> I'd like to add a concern about EAP-Success that has confused me for a while. I think it's been aluded to here, but not stated explicitly yet. Specifically, since EAP-Success is not ACK'ed, how can it be relied upon to indicate things like "auth successful, go ahead and send packets"? It seems to me that the NAS has to tell the client that auth is successful via some other method ... at the moment the status quo seems to be to use a timer and start sending packets if you don't see EAP-Success before the timer expires, or watch for packets to arrive and decide auth must have been successful if you see packets. As EAP gets used for more stuff, I think this needs to get pinned down. If I remember correctly, 802.1x makes a mistake like this and relies on EAP-Success being delivered successfully in several of the state machines. Best regards. Simon Jacques Caron on 02/20/2002 06:23:14 PM To: Bernard Aboba cc: John Vollbrecht , eap@frascone.com (bcc: Simon Blake-Wilson/Certicom) Subject: Re: [eap] RFC 2284bis issues At 17:39 20/02/2002, Bernard Aboba wrote: > > This seems a very good idea. > >Look for some initial ideas on how to do this in: >http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-vendor-00.txt >http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-00.txt > > > Here I think there is some conceptual conversation that needs to take > place. > > There are different ways to think about EAP. One is to see it as a > decision > > making protocol for Access control. Another is as a protocol between > two end > > points that use it to make decisions AND possibly other things, and not > just for > > access control applications. > >Want to stake out a position? I vote in favor of "can do other things". The great thing about EAP is that: - it occurs before an actual session starts (whatever that session is) - it is transmitted transparently, end-to-end, between the client and an AAA server, across the NAS/AP/whatever [note: it might be a good idea to finally come up with a generic term that means any of those -- might be a GAS, like Generic Access Server ;-)] This could be used for negotiation of quite a number of things (related to AAA's second A). John seems to think QoS parameters. I think presentation of cost to the user. There might be more. However, moving EAP from a single-method-then-success to a multiple-method-then-success model might have some implications for backwards compatibility. > > or the client should not accept a "success" from the server if it is doing > > mutual authentication. I must decide for itself if the other side has > > successfully authenticated > >If the client does not accept a "success" how does it know when the server >has granted access to the network? It seems like the "ok to get on the >network" state is reached as a result of two things where there is mutual >auth: > 1. Server authenticates itself to client (method specific) > 2. Client authenticates itself to server (indicated by EAP Success) > >Note that in RFC 2284bis there is an open issue as to whether a client can >send an EAP Success to a server. I think one big issue with Sucess and Failure comes from the fact they're not ACK'd, and hence cannot be NACK'd. In some cases, a client might want to refuse a connection to go further (which in some contexts would mean "start pumping cash out of my account") unless something else happened to the satisfaction of the client. >Yes -- the trick is that if it is an EAP state machine, it has to include >support for L2 triggers. In some media such triggers exist, and in other >media they do not. For example, in PPP we have LCP-Terminate, in 802.11 we >have Disassociate as alternative failure indications. In generic IEEE 802 >we do not have an equivalent I would get that most of the 802 media that support 802.1x (and hence are port-based) have a "link down" (or whatever the fancy name for that is in IEEE lingo) event? >. Similarly, in terms of success in PPP we >have NCP, but I don't think there is an equivalent in 802.11 or generic >802. Back to ACK'ing success/failure :-) Back to backwards compatibility issues :-( Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Thu Feb 21 18:11:53 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 21 Feb 2002 10:11:53 -0800 (PST) Subject: [eap] RFC 2284bis issues In-Reply-To: <85256B67.00642983.00@smtpmail.certicom.com> Message-ID: > Specifically, since EAP-Success is not ACK'ed, how can it be relied upon to > indicate things like "auth successful, go ahead and send packets"? Well, RFC 2284 states that "alternate indications of Success/Failure" are to be used in case a Success or Failure indication does not arrive. This is problematic, because while PPP might have the appropriate mechanisms (like LCP-Terminate and NCP) not all media will have them. 802.11 has Disassociate, but no alternative success indicator (unless you count EAPOL-Key, which also isn't ACK'd). Generic IEEE 802 doesn't really have an alternative failure indicator, except maybe if you count carrier sense. EAPOL-Key isn't sent for 802 wired, so we don't even have that straw to grasp at. There seem to be two possible approaches to fixing this, neither of which seem ideal: a. Defining alternate success/failure indications for each media. b. Adding a client ACK (perhaps an EAP Success in the other direction). Approach a) seems hard to accomplish for all media. Approach b) may not work well with existing implementations. If an ACK is to be useful, then the Server would need to retransmit if it is not received. Yet legacy clients will never ACK so it is hard to see how backward compatibility can be achieved. Maybe someone else has some better ideas. > If I remember correctly, 802.1x makes a mistake like this and relies on > EAP-Success being delivered successfully in several of the state machines. Since IEEE 802.1X doesn't define alternative failure/success indicators, they just use a timeout. From jacques_m_caron@yahoo.com Thu Feb 21 18:58:59 2002 From: jacques_m_caron@yahoo.com (Jacques Caron) Date: Thu, 21 Feb 2002 19:58:59 +0100 Subject: [eap] RFC 2284bis issues In-Reply-To: References: <85256B67.00642983.00@smtpmail.certicom.com> Message-ID: <5.1.0.14.0.20020221195416.030a85c0@pop.mail.yahoo.com> At 19:11 21/02/2002, Bernard Aboba wrote: >Approach b) may not work well with existing implementations. If an ACK is >to be useful, then the Server would need to retransmit if it is not >received. Yet legacy clients will never ACK so it is hard to see how >backward compatibility can be achieved. There could be something earlier on in the conversation (e.g. a request for a specific method, or a change in response format) that would allow distinction between versions of EAP (i.e. the present one, and a new one). In the case of the present one (which we can suppose is mainly implemented in PPP clients, and some limited number of 802.1x clients for WLANs), traditional behavior would be expected. In the case of the new one, ACKs would be necessary. Of course there's the issue that some part of the negotiation actually has an implication on the NAS/AP/switch itself. An alternative method would be to define a brand new encapsulation of EAP (i.e. with a different LCP/Ethernet frame type) to distinguish the two versions. The intent being to keep the AAA proxying and serving intact as much as possible. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From aboba@internaut.com Thu Feb 21 18:51:30 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 21 Feb 2002 10:51:30 -0800 (PST) Subject: [eap] [Issue] Success/Failure ACK In-Reply-To: <5.1.0.14.0.20020221195416.030a85c0@pop.mail.yahoo.com> Message-ID: Is someone willing to volunteer to create a problem statement and analyze the pros and cons of various possible solutions to this issue? We've been asked to come up with an EAP BOF Agenda by tommorrow, and this sounds like a useful topic to explore. Some other potential BOF agenda items: 1. EAP state machine [Bill Arbaugh] 2. EAP vulnerability assessment & security considerations [Bill Arbaugh] 3. IANA considerations [Bernard Aboba] 4. RFC 2284bis issues [John Vollbrecht] 5. RFC 2869bis issues [Bernard Aboba] From gwz@cisco.com Fri Feb 22 06:16:07 2002 From: gwz@cisco.com (Glen Zorn) Date: Thu, 21 Feb 2002 22:16:07 -0800 Subject: [eap] Proposed EAP WG Charter In-Reply-To: Message-ID: > To have an EAP WG, we need to have a Charter. Here's a first cut at an EAP > WG Charter. The goal is to focus on cleaning up the EAP specification for > the first 6 months, after which we can re-charter to work on additional > items. It seems rather wildly inappropriate to ignore the question of analyzing/standardizing EAP types for six months (or, worse, as John V. suggested, bail on performing any security analysis on them at all). More below... > > > ---------------------------------------------------------------- > EAP Working Group (EAP) > > Chair(s): > This space for rent I'll volunteer to chair the BOF (I have experience in the field ;-) > > Area Director(s): > Thomas Narten > Erik Nordmark > > Security Advisors: > Bill Arbaugh > > Mailing Lists: > > General discussion: eap@frascone.com > To subscribe: ? Send a message containing the word "subscribe" in either the subject or body to eap-request@frascone.com > Archive: ? http://mail.frascone.com/pipermail/eap/ > > The EAP working group will restrict itself to the following short-term > work items in order to fully document and improve the interoperability of > the existing EAP protocol: > > 1. IANA considerations. > 2. Threat model and security considerations. > 3. EAP state machine. > 4. Clarification and documentation of EAP key usage. > 5. Documentation of interaction between EAP and lower layers. > 6. Resolution of interoperability issues. > 7. Type space extension to support an expanded Type space. > 8. Requirements for cryptographic protection of EAP. > 9. Update of RFC 2869 (RADIUS/EAP) > > Goals and Milestones > > Jun 02 IANA considerations draft to RFC Editor. > Jun 02 EAP type extension section for RFC 2284bis. > Jun 02 EAP Security considerations section for RFC 2284bis. > Jun 02 EAP state machine section for RFC 2284bis. > Sep 02 RFC 2869bis published as Proposed Standard RFC. > Sep 02 RFC 2284bis published as Proposed Standard RFC. > Sep 02 EAP keying framework doc published as Informational RFC. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Fri Feb 22 06:23:02 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 21 Feb 2002 22:23:02 -0800 (PST) Subject: [eap] Proposed EAP WG Charter In-Reply-To: Message-ID: > It seems rather wildly inappropriate to ignore the question of > analyzing/standardizing EAP types for six months (or, worse, as John V. > suggested, bail on performing any security analysis on them at all). More > below... There is a difference between working to clarify RFC 2284 and "ignoring" work on additional EAP Types. Presumably, as issues are clarified in RFC 2284bis, authors of EAP Methods will be updating their drafts to conform to the newly clarified specification. The evidence so far is that a *lot* of that kind of clarification is needed. So rather, I think of the first six months as clarifying RFC 2284 and the overall functionality of EAP so that it can be implemented interoperably, and simultaneously bringing methods into conformance with the newly clarified spec. Thus, while the WG may not be considering new methods, the authors will presumably be doing quite a bit of work in the background. I also expect the authors to be active in the discussion of RFC 2284bis -- asking questions about how things are supposed to work, and debating whether this or that practice is legal. Ultimately, I think this will *save* a lot of time -- because as it is, if we were to try to analyze submitted methods, we would find ourselves continually running into interoperability issues and fundamental questions about how EAP works which we would need to clarify before we could move forward. It makes more sense to try to address the major issues up front, rather than piece meal. I also think that by focussing on getting the fundamentals done up front, we have a much better chance of completing that work in an expeditious way. If we were to try to analyze/standardize methods at the same time, it's likely that we wouldn't have enough focus, and the fundamental work would drag out. From gwz@cisco.com Fri Feb 22 08:02:29 2002 From: gwz@cisco.com (Glen Zorn) Date: Fri, 22 Feb 2002 00:02:29 -0800 Subject: [eap] Proposed EAP WG Charter In-Reply-To: Message-ID: > > It seems rather wildly inappropriate to ignore the question of > > analyzing/standardizing EAP types for six months (or, worse, as John V. > > suggested, bail on performing any security analysis on them at > all). More > > below... > > There is a difference between working to clarify RFC 2284 and > "ignoring" work on additional EAP Types. The distinction escapes me. > Presumably, as issues are > clarified in RFC 2284bis, authors of EAP Methods will be updating their > drafts to conform to the newly clarified specification. The evidence so > far is that a *lot* of that kind of clarification is needed. Presumably, they would be doing that anyway... > > So rather, I think of the first six months as clarifying RFC 2284 and > the overall functionality of EAP so that it can be implemented > interoperably, and simultaneously bringing methods into conformance with > the newly clarified spec. I could have sworn that it _had_ been implemented interoperably... > > Thus, while the WG may not be considering new methods, the authors will > presumably be doing quite a bit of work in the background. I also expect > the authors to be active in the discussion of RFC 2284bis -- asking > questions about how things are supposed to work, and debating whether this > or that practice is legal. Why would they be doing this more than if there was no WG? > > Ultimately, I think this will *save* a lot of time -- because as it is, if > we were to try to analyze submitted methods, we would find ourselves > continually running into interoperability issues and fundamental > questions about how EAP works which we would need to clarify before we > could move forward. Maybe, maybe not. Hopefully, the people designing EAP types ahve _some_ idea of how it works already... > It makes more sense to try to address the major > issues up front, rather than piece meal. > > I also think that by focussing on getting the fundamentals done up front, > we have a much better chance of completing that work in an expeditious > way. If we were to try to analyze/standardize methods at the same time, > it's likely that we wouldn't have enough focus, and the fundamental work > would drag out. I have a feeling that the IESG would probably kill the group immediately after this "fundamental" work was complete; the idea of an on-going group that works on extensions doesn't fit neatly w/the IETF way. Of course, this would result in yet another WG that accomplishes something that's nice, and useful, while ignoring the urgent and important. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Fri Feb 22 07:49:29 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 21 Feb 2002 23:49:29 -0800 (PST) Subject: [eap] Proposed EAP WG Charter In-Reply-To: Message-ID: > I could have sworn that it _had_ been implemented interoperably... Unfortunately, there isn't enough data from the surveys we've gotten back to demonstrate that many of the features have even been implemented by two implementations, let alone that they interoperate. And in practice, quite a few of the methods that have been proposed will *not* interoperate with one or more AAA servers, NASes or clients. Some reasons: a. Use of NAK or NOTIFICATION as part of the method b. Data in EAP Success c. Use of ciphersuite-specific key derivations in the method d. Key derivation without key hierarchy support e. Use of multiple Types within a single method f. Sending of multiple EAP frames within a single round trip > Why would they be doing this more than if there was no WG? Presumably the WG will provide guidance on how the methods can developed so that they will interoperate. Whereas if there were no WG this wouldn't happen. > Maybe, maybe not. Hopefully, the people designing EAP types have _some_ > idea of how it works already... Unfortunately, the "idea" seems to vary according to the author's reading of RFC 2284. Based on results, it seems that RFC 2284 is unclear in quite a few places. > I have a feeling that the IESG would probably kill the group immediately > after this "fundamental" work was complete; the idea of an on-going group > that works on extensions doesn't fit neatly w/the IETF way. Of course, this > would result in yet another WG that accomplishes something that's nice, and > useful, while ignoring the urgent and important. Well, even if that happens, we'll still be a *lot* better off than we are now, because people will understand how to write EAP methods that will interoperate. BTW, what methods do you consider "urgent and important" and why? And what do those methods need to do? The charter can probably also include development of requirements for what those methods need to do. From jrv@interlinknetworks.com Fri Feb 22 13:48:10 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Fri, 22 Feb 2002 08:48:10 -0500 Subject: [eap] A straw man for EAP BOG writeup References: <85256B67.00642983.00@smtpmail.certicom.com> Message-ID: <3C764C1A.E9E108F8@interlinknetworks.com> Simon Blake-Wilson wrote: > I think review of EAP methods, and standardization of new methods should be part > of the proposal. > > Best regards. Simon My preference is to deal with EAP as a protocol. This would include interactions between EAP and the applications using EAP. I don't think it appropriate for this group to analyze SRP or Kerberos or SKE for strength of authentication or vulnerability to replay attack etc., unless the way that EAP is used to carry that method is the cause of the problem. I do think there should be some review of EAP methods for conformance to good "EAP" practice. I also would agree that this is a grey area and it is not clear exactly how or where to draw the line. -- John From aboba@internaut.com Fri Feb 22 18:15:35 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 22 Feb 2002 10:15:35 -0800 (PST) Subject: [eap] Proposed EAP BOF Agenda Message-ID: Extensible Authentication Protocol BOF (EAP) Time: 2 hour segment requested, not conflicting with AAA, PPPEXT, DHC, IPSEC, IPSRA, PANA, ROI, IPS, CAT CHAIRS: Bernard Aboba John Vollbrecht Description: EAP (RFC 2284) is currently a work item of the PPPEXT WG, and is also under consideration within the IPSRA WG (PIC) and PANA WGs. The goal of this BOF is to discuss the creation of a working group to clarify the EAP specification, and possibly to standardize additional EAP methods. Backwards compatibility with RFC 2284 is an explicit goal. Motivation: While EAP is now in use for authentication within the PPP and IEEE 802 link layers, interoperability issues have arisen. RFC 2284 lacked a protocol state machine, an IANA considerations section, and a complete security considerations section. A number of ambiguities have also arisen in RFC 2869 (RADIUS/EAP). The result of these ambiguities is that EAP method developers may find that their methods do not interoperate on all existing AAA servers, NASes, and clients. In addition, EAP is now being deployed in environments (such as wireless networks and use over the Internet) which make it vulnerable to attack. This has lead to proposals for improving the security of EAP. The primary goal of this BOF is to understand the range of interoperability and security issues encountered with RFC 2284, and secondarily to understand the requirements for development of additional EAP methods. EAP is currently a work item of the PPPEXT WG, but depending on the volume of EAP work required, it may be appropriate to form a separate WG focussing on EAP. BoF Agenda 1. Scribe volunteer 2. Agenda bash 3. RFC 2284 interoperability issues draft-ietf-pppext-rfc2284bis-02.txt 4. EAP IANA Considerations draft-aboba-pppext-eap-iana-00.txt 5. EAP state machine draft-ietf-pppext-rfc2284bis-02.txt 6. EAP security considerations draft-ietf-pppext-rfc2284bis-02.txt 7. Cryptographic protection of EAP draft-ietf-ipsra-pic-05.txt draft-ietf-pppext-eap-ttls-00.txt draft-josefsson-pppext-eap-tls-eap-02.txt 8. Requirements for additional EAP methods EAP dependencies of 802.11 draft-aboba-pppext-key-problem-01.txt 9. Additional proposed EAP methods draft-ietf-pppext-eap-srp-04.txt draft-arkko-pppext-eap-aka-01.txt draft-haverinen-pppext-eap-sim-02.txt draft-salgarelli-pppext-eap-ske-00.txt 10. Charter bash Background reading (required for BOF participants) RFC 2284 (EAP) RFC 2869 (EAP/RADIUS) draft-ietf-pppext-rfc2284bis-02.txt draft-ietf-pppext-key-problem-01.txt draft-ietf-ipsra-pic-05.txt draft-ietf-pppext-eap-ttls-00.txt draft-ietf-josefsson-pppext-eap-tls-eap-02.txt Strawman charter proposal EAP Working Group (EAP) Chair(s): This space for rent Area Director(s): Thomas Narten Erik Nordmark Security Advisors: Bill Arbaugh Mailing Lists: General discussion: eap@frascone.com To subscribe: send a message with "subscribe" in the subject to eap-request@frascone.com Archive: http://mail.frascone.com/pipermail/eap/ The EAP working group will restrict itself to the following short-term work items in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations. 2. Threat model and security considerations. 3. EAP state machine. 4. Clarification and documentation of EAP keying issues 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. Type space extension to support an expanded Type space. 8. EAP applicability statement 9. Update of RADIUS/EAP section of RFC 2869 Goals and Milestones Jun 02 IANA considerations draft to RFC Editor. Jun 02 EAP type extension section for RFC 2284bis. Jun 02 EAP Security considerations section for RFC 2284bis. Jun 02 EAP state machine section for RFC 2284bis. Sep 02 RFC 2869bis published as Proposed Standard RFC. Sep 02 RFC 2284bis published as Proposed Standard RFC. Sep 02 EAP applicability statement published as Informational RFC. Sep 02 EAP keying issues doc published as Informational RFC. From dnelson@enterasys.com Fri Feb 22 19:12:49 2002 From: dnelson@enterasys.com (Nelson, David) Date: Fri, 22 Feb 2002 14:12:49 -0500 Subject: [eap] Proposed EAP BOF Agenda Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBD4.EB266F30 Content-Type: text/plain; charset="iso-8859-1" Bernard Aboba writes... > > Extensible Authentication Protocol BOF (EAP) -snip- > Strawman charter proposal > > EAP Working Group (EAP) -snip- I like the proposed BOF agenda. Does the proposed WG agenda encompass the EAP requirements identified in the IEEE 801.11 Task Group TGi (as documented in a letter from Stuart Kerry to Harald Alverstrand)? Regards, Dave David B. Nelson, Software Architect Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01801-1008 Phone: (978) 684-1330 FAX: (978) 684-1368 E-mail: dnelson@enterasys.com ------_=_NextPart_001_01C1BBD4.EB266F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Proposed EAP BOF Agenda

Bernard Aboba writes...
>
> Extensible Authentication Protocol BOF = (EAP)

-snip-

> Strawman charter proposal
>
> EAP Working Group (EAP)

-snip-

I like the proposed BOF agenda.

Does the proposed WG agenda encompass the EAP = requirements identified in the IEEE 801.11 Task Group TGi (as = documented in a letter from Stuart Kerry to Harald = Alverstrand)?

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) = 684-1368
E-mail: dnelson@enterasys.com

------_=_NextPart_001_01C1BBD4.EB266F30-- From gwz@cisco.com Fri Feb 22 23:45:00 2002 From: gwz@cisco.com (Glen Zorn) Date: Fri, 22 Feb 2002 15:45:00 -0800 Subject: [eap] Proposed EAP BOF Agenda In-Reply-To: Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C1BBB7.E312BD70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [eap] Proposed EAP BOF AgendaThe proposed WG charter does basically nothing to speak to IEEE requirements, as far as I can tell. The IEEE (and 3GPP*) need new seats for their car; the proposal is to give them (after 6 months or so) a new car with the same seats. -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]On Behalf Of Nelson, David Sent: Friday, February 22, 2002 11:13 AM To: eap@frascone.com Subject: RE: [eap] Proposed EAP BOF Agenda Bernard Aboba writes... > > Extensible Authentication Protocol BOF (EAP) -snip- > Strawman charter proposal > > EAP Working Group (EAP) -snip- I like the proposed BOF agenda. Does the proposed WG agenda encompass the EAP requirements identified in the IEEE 801.11 Task Group TGi (as documented in a letter from Stuart Kerry to Harald Alverstrand)? Regards, Dave David B. Nelson, Software Architect Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01801-1008 Phone: (978) 684-1330 FAX: (978) 684-1368 E-mail: dnelson@enterasys.com ------=_NextPart_000_0097_01C1BBB7.E312BD70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Proposed EAP BOF Agenda
The=20 proposed WG charter does basically nothing to speak to IEEE = requirements, as far=20 as I can tell.  The IEEE (and 3GPP*) need new seats for their car; = the=20 proposal is to give them (after 6 months or so) a new car with the same=20 seats.
-----Original Message-----
From: = eap-admin@frascone.com=20 [mailto:eap-admin@frascone.com]On Behalf Of Nelson,=20 David
Sent: Friday, February 22, 2002 11:13 AM
To: = eap@frascone.com
Subject: RE: [eap] Proposed EAP BOF=20 Agenda

Bernard Aboba writes...
>=20
> Extensible Authentication Protocol BOF=20 (EAP)

-snip-

> Strawman charter proposal
>=20
> EAP Working Group (EAP)

-snip-

I like the proposed BOF agenda.

Does the proposed WG agenda encompass the EAP = requirements=20 identified in the IEEE 801.11 Task Group TGi (as documented in a = letter from=20 Stuart Kerry to Harald Alverstrand)?

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 = Minuteman=20 Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368 =
E-mail: dnelson@enterasys.com =

------=_NextPart_000_0097_01C1BBB7.E312BD70-- From dpotter@cisco.com Sat Feb 23 09:46:43 2002 From: dpotter@cisco.com (Darran Potter) Date: Sat, 23 Feb 2002 09:46:43 -0000 Subject: [eap] Proposed EAP BOF Agenda Message-ID: Could we please have draft-dpotter-pppext-eap-mschap-01 included in the Additional proposed EAP methods section? Thanks __________________________________ Darran Potter CiscoSecure ACS Development Team __________________________________ From aboba@internaut.com Sat Feb 23 18:13:42 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 23 Feb 2002 10:13:42 -0800 (PST) Subject: [eap] Re: eap digest, Vol 1 #6 - 4 msgs In-Reply-To: <200202231721.g1NHLVw16762@internaut.com> Message-ID: >> EAP dependencies of 802.11 > Does the proposed WG agenda encompass the EAP requirements identified in the > IEEE 801.11 Task Group TGi (as documented in a letter from Stuart Kerry to > Harald Alverstrand)? Yes, the BOF agenda does include an item on "EAP dependencies of 802.11". It would be desirable if someone representing 802.11i were to present the requirements. Note however, that my understanding is that the letter has not been sent yet -- though a preliminary version was made available to the IESG. From aboba@internaut.com Sat Feb 23 18:34:03 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 23 Feb 2002 10:34:03 -0800 (PST) Subject: [eap] EAP method discussion at EAP BOF Message-ID: An EAP BoF session has been scheduled at IETF 53. As part of this session, some time has been set aside for discussion of proposed EAP methods. We hereby solicit EAP method authors who wish to make a short (1 slide) presentation on their proposed EAP method. In the presentation, it can be assumed that BoF participants have read the draft. The slide should cover the following: a. Name of the method b. Justification (why is it unique) c. Usage scenario (kinds of devices, media, etc.) d. EAP Type # assigned e. Authentication (mutual/one-way) f. Support for "fast reconnect" (yes/no) g. Dictionary attack vulnerability (yes/no) h. Key derivation? (yes/no, kinds of keys derived) i. Algorithms (e.g. does it use existing standard algorithms or does it create new ones) j. Standards group dependencies (3GPP, IEEE 802.11i, etc.) EAP BOF description: http://www.ietf.org/ietf/02mar/eap.txt From dhala@cisco.com Sat Feb 23 19:21:27 2002 From: dhala@cisco.com (David Halasz) Date: Sat, 23 Feb 2002 14:21:27 -0500 Subject: [eap] Re: eap digest, Vol 1 #6 - 4 msgs In-Reply-To: References: <200202231721.g1NHLVw16762@internaut.com> Message-ID: <4.3.2.7.2.20020223135558.023200d0@unitas.cisco.com> I sent an email to chair@ietf.org on 1/30/02. But, this probably went into a bit bucket someplace. Any suggestions on how to formally deliver it to the chair of IESG/IETF? Dave H. At 01:13 PM 2/23/2002, Bernard Aboba wrote: > >> EAP dependencies of 802.11 > > > Does the proposed WG agenda encompass the EAP requirements identified > in the > > IEEE 801.11 Task Group TGi (as documented in a letter from Stuart Kerry to > > Harald Alverstrand)? > >Yes, the BOF agenda does include an item on "EAP dependencies of >802.11". It would be desirable if someone representing 802.11i were to >present the requirements. > >Note however, that my understanding is that the letter has not been >sent yet -- though a preliminary version was made available to the IESG. > > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 From aboba@internaut.com Sat Feb 23 18:43:47 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 23 Feb 2002 10:43:47 -0800 (PST) Subject: [eap] Re: eap digest, Vol 1 #6 - 4 msgs In-Reply-To: <4.3.2.7.2.20020223135558.023200d0@unitas.cisco.com> Message-ID: I would cc: a copy to Erik.Nordmark@sun.com as well as narten@us.ibm.com. On Sat, 23 Feb 2002, David Halasz wrote: > I sent an email to chair@ietf.org on 1/30/02. But, this probably went into > a bit bucket someplace. Any suggestions on how to formally deliver it to > the chair of IESG/IETF? > > Dave H. > > At 01:13 PM 2/23/2002, Bernard Aboba wrote: > > >> EAP dependencies of 802.11 > > > > > Does the proposed WG agenda encompass the EAP requirements identified > > in the > > > IEEE 801.11 Task Group TGi (as documented in a letter from Stuart Kerry to > > > Harald Alverstrand)? > > > >Yes, the BOF agenda does include an item on "EAP dependencies of > >802.11". It would be desirable if someone representing 802.11i were to > >present the requirements. > > > >Note however, that my understanding is that the letter has not been > >sent yet -- though a preliminary version was made available to the IESG. > > > > > >_______________________________________________ > >eap mailing list > >eap@frascone.com > >http://mail.frascone.com/mailman/listinfo/eap > > > Dave Halasz > Cisco Systems, Inc. > 320 Springside Drive > Akron, OH 44333 > From dhala@cisco.com Sat Feb 23 20:48:17 2002 From: dhala@cisco.com (David Halasz) Date: Sat, 23 Feb 2002 15:48:17 -0500 Subject: [eap] RFC 2284bis issues In-Reply-To: Message-ID: <4.3.2.7.2.20020223154608.016e17a8@unitas.cisco.com> One concern, of EAP and wireless, is anonymity. I don't have any ideas, of how to "hide" the user id, in the identity response. But, since it gets broadcast, in wireless, I have heard concerns. Dave H. At 10:53 AM 2/20/2002, Bernard Aboba wrote: >Over the last few months, we've collected quite a few issues for >resolution in RFC 2284bis. Here are the list of issues that we have >collected, and how I would propose to resolve them. Comments welcome. > >1. IANA considerations. RFC 2284 does not include an IANA considerations >section, and RFC 2284bis needs one. Some thoughts on what might be in such >a section: > > a. Reservation of some of the Type space for future use. Should this be > a single EAP method (255) or more of the space (e.g. 127-255)? > > b. Statement that IANA should not allocate two Type codes for a single > EAP method. > > c. Statement about reclamation of unused Type allocations. It looks > like several of the alllocated Type codes have never been used. > > d. Allocation of an EAP Type code for "Vendor Specific". I have in > mind something like what RADIUS does with attribute 26. This could > take the pressure off the Type space. > > e. Statement on allocation of EAP type codes. Should this be on > request? By expert review? (e.g. by sending mail to the WG) By > designated expert? Assuming that we have a vendor specific code, > the criteria might be different, (e.g. a specification and expert > review might be required). > >2. State machine issues. There are a lot of these. RFC 2284 has only a >short section describing in general terms what the protocol does. There >is no detailed section describing the protocol exchange in more detail, >or a formal state machine. These meaans that in many cases there is no >clear answer to the question "what do you do if you receive packet X when >you are in the midst of doing Y?" > >3. Not allowing data traffic prior to completion of authentication. RFC >2284 doesn't state specifically that this is required, because it is >required by PPP -- so it probably seemed obvious and not worth >mentioning. But now that EAP can be used over a variety of media, this >has become a point of confusion. > >Proposed resolution is to indicate that an authentication conversation, once >initiated, must complete before data traffic can be sent. > >4. EAP Success prior to mutual authentication. RFC 2284 does not >include a state machine, but it seems to imply that the peer should >consider authentication complete on receiving an EAP Success. Bill Arbaugh >has pointed out that a client requiring mutual authentication should not >consider itself "on the network" until that mutual authentication is >complete, so this is broken. > >For example, if the peer is authenticating via a method supporting >mutual auth (EAP TLS, EAP SRP, etc.) and an authenticator sends an EAP >Success in the middle, the recommendation is that the text of RFC 2284bis >be changed to note that the client SHOULD NOT bring >up the interface and SHOULD disconnect. Comments? > >5. Spoofed EAP Failure. Similarly, RFC 2284 seems to imply that a peer >always considers themself disconnected when receiving an EAP Failure, >although it does indicate that "alternative indications of >success/failure" can be considered. What if an attacker spoofs an EAP >Failure outside of an authentication conversation? What if other traffic >is being received at the same time, indicating that the connection is in >fact up? Can the peer ignore the EAP Failure? > >My recommendation is that the text clarify the meaning of "alternative >indications" with respect to this scenario. I believe that 802.11 and PPP >both have such alternative indications -- in the case of PPP, we have LCP >Terminate, in 802.11 we have Disassociate or Deauthenticate. So typically >the EAP Failure will be followed by an alternative indication, >particularly if it occurs "out of the blue". I think that the EAP >indicator can be ignored (sometimes? all the time?) if it is at odds with >the alternative indication. > >6. Authentication of the EAP Success. Bill suggests that an authenticator >be added to the EAP Success message. My inclination is not to accept this >suggestion since existing proposals (PEAP, TTLS) already support >authentication and encryption of the entire EAP conversation. Comments? > > > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap Dave Halasz Cisco Systems, Inc. 320 Springside Drive Akron, OH 44333 From aboba@internaut.com Sun Feb 24 05:11:47 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 23 Feb 2002 21:11:47 -0800 (PST) Subject: [eap] RFC2284bis -02 strawman Message-ID: I've put a strawman version of the -02 RFC 2284bis document up at: http://www.drizzle.com/~aboba/AAA/draft-ietf-pppext-rfc2284bis-02.txt Comments welcome. Changes Added IANA considerations section Added "media issues" section Added skeletal "state machine" section Beefed up security considerations section Updated "open issues" list at the end From gwz@cisco.com Sun Feb 24 06:04:55 2002 From: gwz@cisco.com (Glen Zorn) Date: Sat, 23 Feb 2002 22:04:55 -0800 Subject: [eap] Re: eap digest, Vol 1 #6 - 4 msgs In-Reply-To: Message-ID: Bernard Aboba [mailto:aboba@internaut.com] writes: > >> EAP dependencies of 802.11 > > > Does the proposed WG agenda encompass the EAP requirements > identified in the > > IEEE 801.11 Task Group TGi (as documented in a letter from > Stuart Kerry to > > Harald Alverstrand)? > > Yes, the BOF agenda does include an item on "EAP dependencies of > 802.11". It would be desirable if someone representing 802.11i were to > present the requirements. I guess I'm confused by both the Dave's question and Bernard's answer. Maybe somebody can clarify these things for me: was the question really about the proposed WG _Charter_ (as I assumed) or the proposed BOF _Agenda_? There is no WG Agenda (except, perhaps in the informal sense) AFAIK. > > Note however, that my understanding is that the letter has not been > sent yet -- though a preliminary version was made available to the IESG. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Sun Feb 24 07:14:03 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 23 Feb 2002 23:14:03 -0800 (PST) Subject: [eap] RE: BOF Agenda In-Reply-To: Message-ID: > I guess I'm confused by both the Dave's question and Bernard's answer. > Maybe somebody can clarify these things for me: was the question really > about the proposed WG _Charter_ (as I assumed) or the proposed BOF _Agenda_? > There is no WG Agenda (except, perhaps in the informal sense) AFAIK. Note sure it really matters. The BOF Agenda includes items relating to 802.11 requirements and new EAP methods as well a discussion of a proposed WG charter. From jacques_m_caron@yahoo.com Sun Feb 24 10:18:30 2002 From: jacques_m_caron@yahoo.com (Jacques Caron) Date: Sun, 24 Feb 2002 11:18:30 +0100 Subject: [eap] EAP "v2" backwards compatibility Message-ID: <5.1.0.14.0.20020224032708.00af3400@195.134.198.25> Hi, Some possibilities if EAP "v2" (e.g. with ACK'd success/failure) is different enough from the current EAP that backwards compatibility is an issue... * Add a special "EAP version" method. The conversation would then look like: Cl <- NAS EAP Request/Identity Cl -> NAS EAP Response/Identity NAS -> AAA AAA Auth request Username=Identity NAS <- AAA AAA Auth Challenge EAP=Request/Version Cl <- NAS EAP Request/Version Cl -> NAS EAP Response/Version NAS -> AAA AAA Auth request Username=Identity, EAP=Response/Version [... usual EAP Request/Response roundtrips...] NAS <- AAA AAA Auth Challenge EAP=Success Cl <- NAS EAP Success Cl -> NAS EAP Success ACK (in whatever form it may take) NAS -> AAA AAA Auth Request Username=Identity, EAP=Success ACK NAS <- AAA AAA Auth Accept EAP=Success Cl <- NAS EAP Success (completely redundant just to avoid changes to NAS) If the Client is RFC2284, then it will respond to Request/Version with a Response/NAK, so the server and/or NAS know not to expect an ACK for Success, and do it the "old" way: Cl <- NAS EAP Request/Identity Cl -> NAS EAP Response/Identity NAS -> AAA AAA Auth request Username=Identity NAS <- AAA AAA Auth Challenge EAP=Request/Version Cl <- NAS EAP Request/Version Cl -> NAS EAP Response/NAK NAS -> AAA AAA Auth request Username=Identity, EAP=Response/NAK [... usual EAP Request/Response roundtrips...] NAS <- AAA AAA Auth Accept EAP=Success Cl <- NAS EAP Success If the client is EAPv2 and not the server, the client won't receive the Request/Version packet, and will know that no ACK is needed for Success (or might decide it doesn't want to authenticate): Cl <- NAS EAP Request/Identity Cl -> NAS EAP Response/Identity NAS -> AAA AAA Auth request Username=Identity [... usual EAP Request/Response roundtrips...] NAS <- AAA AAA Auth Accept EAP=Success Cl <- NAS EAP Success Issue: do NASes currently transmit EAP messages in AAA Challenge requests transparently (including Success)? Similarly, will they take any answer and send it to the server without trying to interpret it? If that's not the case, then in the first scenario, success and success ACK might need to look like EAP methods: Cl <- NAS EAP Request/Identity Cl -> NAS EAP Response/Identity NAS -> AAA AAA Auth request Username=Identity NAS <- AAA AAA Auth Challenge EAP=Request/Version Cl <- NAS EAP Request/Version Cl -> NAS EAP Response/Version NAS -> AAA AAA Auth request Username=Identity, EAP=Response/Version [... usual EAP Request/Response roundtrips...] NAS <- AAA AAA Auth Challenge EAP=Request/Success Cl <- NAS EAP Request/Success Cl -> NAS EAP Response/Success ACK NAS -> AAA AAA Auth Request Username=Identity, EAP=Response/Success ACK NAS <- AAA AAA Auth Accept EAP=Success Cl <- NAS EAP Success (completely redundant) Of course, Request/Version and Request/Success might be sub-types of one single method (as well as Request/Failure and any others in the same vein). In this scenario, only clients and AAA servers would need to be modified. * Use a different encapsulation, i.e. a different PPP/Ethernet frame type This requires changes to both clients and NASes (and AAA servers, most probably), which would support rfc2284 and EAPv2 on different frame types. A bit of a waste, but if EAPv2 becomes significantly different from rfc2284, it might be needed. In short, this is a "wipe the board and start again" approach :-( * Encapsulate EAPv2 within an EAP method Here, EAPv2 packets would be encapsulated within regular EAP Request and Response packets, with a specific "EAPv2" method. For instance: Cl <- NAS EAP Request/Identity Cl -> NAS EAP Response/Identity NAS -> AAA AAA Auth request Username=Identity NAS <- AAA AAA Auth Challenge EAP=Request/Version Cl <- NAS EAP Request/EAPv2/Request/method Cl -> NAS EAP Response/EAPv2/Response/method NAS -> AAA AAA Auth request Username=Identity, EAP=Response/EAPv2/Response/method [... further EAP Request/Response/EAPv2 roundtrips...] NAS <- AAA AAA Auth Challenge EAP=Request/EAPv2/Success Cl <- NAS EAP Request/EAPv2/Success Cl -> NAS EAP Response/EAPv2/Success ACK NAS -> AAA AAA Auth Request Username=Identity, EAP=Response/EAPv2/Success ACK NAS <- AAA AAA Auth Accept EAP=Success Cl <- NAS EAP Success (completely redundant) This adds a bit of overhead to each packet, but it gives a lot more flexibility to EAPv2 (similar to what would be achieved with a whole new frame type as above), but doesn't require any changes to NASes. This might be needed if ever EAPv2 added any form of protection to the EAP packets themselves, for instance. The drawback compared to the method above is that the Identity exchange is still unchanged (and hence unprotected), since the EAPv2 thing only happens once the AAA server is involved. Comments welcome... Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From aboba@internaut.com Sun Feb 24 17:54:06 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 24 Feb 2002 09:54:06 -0800 (PST) Subject: [eap] Re: EAP "v2" backwards compatibility In-Reply-To: <200202241721.g1OHLPw01698@internaut.com> Message-ID: Jacques -- Thanks for characterizing the alternatives. As I see it, there are several fairly important areas of functionality addition that are under consideration. These include cryptographic protection of EAP, Vendor specific support, and Type space expansion. In looking at the alternatives, it might be useful to include thinking about their impact on the possible functionality additions. So far, the thinking seems to be to support cryptographic protection, Vendor-specific and Type space expansion via allocation of new EAP Method Types, but that might not necessarily be the best choice. Would you be willing to write up your analysis in the form of a draft for presentation during the EAP BOF at IETF 53? Comments below. > Cl <- NAS EAP Request/Version > Cl -> NAS EAP Response/Version >If the Client is RFC2284, then it will respond to Request/Version with a >Response/NAK, so the server and/or NAS know not to expect an ACK for >Success, and do it the "old" way. Interesting. So with this alternative *one* new EAP method would be used for negotiation of "optional" features. Presumably this new "capabilities negotiation" method could handle negotiation of multiple capabilities all in one shot. > Issue: do NASes currently transmit EAP messages in AAA Challenge requests > transparently (including Success)? According to RFC 2869, a Challenge is an indication of a continuing conversation, and does not terminate the AAA exchange. However, if the Challenge message were to include a Success which isn't ACK'd, then it's not clear how the conversation could continue after that. If the Success were ACK'd then this wouldn't be an issue. > In this scenario, only clients and AAA servers would need to be modified. Depends on whether the negotiated capabilities can solely be provided by the AAA server and client without NAS knowledge. I think that ACK'ing of EAP Success may not fit into this category, since presumably the NAS needs to retransmit a Success that isn't ACK'd, assuming that the feature has been negotiated between AAA server and client. I think this means that a NAS would need to have specific knowledge of the negotiation of an ACK'd "Success/Failure" capability, no? > * Use a different encapsulation, i.e. a different PPP/Ethernet frame type > > A bit of a waste, but if EAPv2 becomes significantly different from > rfc2284, it might be needed. In short, this is a "wipe the board and start > again" approach :-( Yes. > * Encapsulate EAPv2 within an EAP method > This adds a bit of overhead to each packet, but it gives a lot more > flexibility to EAPv2 (similar to what would be achieved with a whole new > frame type as above), but doesn't require any changes to NASes. This might > be needed if ever EAPv2 added any form of protection to the EAP packets > themselves, for instance. Interesting. This one offers more NAS independence than the first proposal, I think. I think it also implies that additional features are negotiated as a set. This make it harder to roll out individual improvements (e.g. Protection w/o ACK'ing or Type Expansion). But on the other hand, it might make it more likely that the entire set of improvements might be adopted as a unit. One of the complications of figuring out how to provide additional EAP Types is that if handled through a separate EAP method, you could never guarantee that an EAP implementation would support the expanded Types. > The drawback compared to the method above is that the Identity exchange is > still unchanged (and hence unprotected), since the EAPv2 thing only happens > once the AAA server is involved. Yes -- though the Identity required need only be a realm so as to route the exchange to the correct AAA server. From jacques_m_caron@yahoo.com Mon Feb 25 09:16:07 2002 From: jacques_m_caron@yahoo.com (Jacques Caron) Date: Mon, 25 Feb 2002 10:16:07 +0100 Subject: [eap] Re: EAP "v2" backwards compatibility In-Reply-To: References: <200202241721.g1OHLPw01698@internaut.com> Message-ID: <5.1.0.14.0.20020225100445.038f4ea0@pop.mail.yahoo.com> Hi Bernard, At 18:54 24/02/2002, Bernard Aboba wrote: >Would you be willing to write up your analysis in the form of a draft for >presentation during the EAP BOF at IETF 53? I can write a draft, but IETF 53 is clearly not in my budget, so somebody else will need to present it (I can prepare slides for that if needed) :-( >Interesting. So with this alternative *one* new EAP method would be used >for negotiation of "optional" features. Presumably this new "capabilities >negotiation" method could handle negotiation of multiple capabilities all >in one shot. Of course. I think the "Version" method would at least include some form of version number (in both directions) and a bitmap of features supported (or maybe even required). > > Issue: do NASes currently transmit EAP messages in AAA Challenge requests > > transparently (including Success)? > >According to RFC 2869, a Challenge is an indication of a continuing >conversation, and does not terminate the AAA exchange. However, if the >Challenge message were to include a Success which isn't ACK'd, then it's >not clear how the conversation could continue after that. If the Success >were ACK'd then this wouldn't be an issue. Hence, I do not know how various implementations on the field handle different combinations of AAA answers and EAP packets. We already know of the problem of accept/success vs accept/failure vs reject/success vs reject/failure (which 802.1X addresses by ignoring the EAP packet, and sending a "canned" EAP packet based on the AAA response code), but I have no idea about what different implementations would do if they found a success packet in a challenge, for instance. > > In this scenario, only clients and AAA servers would need to be modified. > >Depends on whether the negotiated capabilities can solely be provided by >the AAA server and client without NAS knowledge. I think that ACK'ing of >EAP Success may not fit into this category, since presumably the NAS needs >to retransmit a Success that isn't ACK'd, assuming that the feature has >been negotiated between AAA server and client. I think this means that a >NAS would need to have specific knowledge of the negotiation of an ACK'd >"Success/Failure" capability, no? If you look at the end of the last scenario: NAS <- AAA AAA Auth Challenge EAP=Request/Success Cl <- NAS EAP Request/Success Cl -> NAS EAP Response/Success ACK NAS -> AAA AAA Auth Request Username=Identity, EAP=Response/Success ACK NAS <- AAA AAA Auth Accept EAP=Success Cl <- NAS EAP Success (completely redundant) There are two types of "success" messages. One (the first four lines above) which is hidden within a Request (and the response is the ack), and the other one (the last two lines) which is there just for backwards compatibility. In the last one, the important part is really the AAA -> NAS Auth Accept (which tells the NAS the important this: yes, you are allowed to let this guy access the network), the EAP success message itself is just there for fun. Of course, if the NAS knows this is no longer necessary, it does not need to send it. > > * Encapsulate EAPv2 within an EAP method > > > This adds a bit of overhead to each packet, but it gives a lot more > > flexibility to EAPv2 (similar to what would be achieved with a whole new > > frame type as above), but doesn't require any changes to NASes. This might > > be needed if ever EAPv2 added any form of protection to the EAP packets > > themselves, for instance. > >Interesting. This one offers more NAS independence than the first >proposal, I think. I think it also implies that additional features are >negotiated as a set. This make it harder to roll out individual >improvements (e.g. Protection w/o ACK'ing or Type Expansion). But on the >other hand, it might make it more likely that the entire set of >improvements might be adopted as a unit. The EAPv2 method might start with some capabilities negotiation too. >One of the complications of figuring out how to provide additional EAP >Types is that if handled through a separate EAP method, you could never >guarantee that an EAP implementation would support the expanded Types. I don't see the problem? If the client does not support the EAPv2 method, then it will NAK it. If the client does not support a specific method encapsulated within the EAPv2 method, it will NAK it too (but this time the NAK will be EAPv2 encapsulated). > > The drawback compared to the method above is that the Identity exchange is > > still unchanged (and hence unprotected), since the EAPv2 thing only > happens > > once the AAA server is involved. > >Yes -- though the Identity required need only be a realm so as to route >the exchange to the correct AAA server. Totally. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From dnelson@enterasys.com Mon Feb 25 16:36:55 2002 From: dnelson@enterasys.com (Nelson, David) Date: Mon, 25 Feb 2002 11:36:55 -0500 Subject: [eap] RE: BOF Agenda Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BE1A.A2BD0BD0 Content-Type: text/plain; charset="iso-8859-1" > > I guess I'm confused by both the Dave's question and Bernard's answer. > > Maybe somebody can clarify these things for me: was the question really > > about the proposed WG _Charter_ (as I assumed) or the proposed BOF _Agenda_? That particular question was intended to be about the proposed WG Charter... (multi-tasking wasn't working for me at that moment :-) > Note sure it really matters. The BOF Agenda includes items relating to > 802.11 requirements and new EAP methods as well a discussion > of a proposed WG charter. ... and to the extent that the WG Charter is discussed at the BOF (and on the mailing list), so that it includes reasonable requirements from IEEE 802.11 TGi, then all is well. ------_=_NextPart_001_01C1BE1A.A2BD0BD0 Content-Type: text/html; charset="iso-8859-1" RE: [eap] RE: BOF Agenda

> > I guess I'm confused by both the Dave's question and Bernard's answer.
> > Maybe somebody can clarify these things for me: was the question really
> > about the proposed WG _Charter_ (as I assumed) or the proposed BOF _Agenda_?

That particular question was intended to be about the proposed WG Charter...
(multi-tasking wasn't working for me at that moment :-)

> Note sure it really matters. The BOF Agenda includes items relating to
> 802.11 requirements and new EAP methods as well a discussion
> of a proposed WG charter.

... and to the extent that the WG Charter is discussed at the BOF (and on the
mailing list), so that it includes reasonable requirements from IEEE 802.11
TGi, then all is well.



------_=_NextPart_001_01C1BE1A.A2BD0BD0-- From aboba@internaut.com Mon Feb 25 17:27:57 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 25 Feb 2002 09:27:57 -0800 (PST) Subject: [eap] Re: 802.11i requirements In-Reply-To: <200202251721.g1PHLJw16616@internaut.com> Message-ID: > mailing list), so that it includes reasonable requirements from IEEE 802.11 > TGi, then all is well. There is time set aside on the agenda for this. Hopefully a representative from IEEE 802.11i will be available to present the requirements. Note that a number of them have already been incorporated into the security considerations section of the RFC 2284bis strawman: http://www.drizzle.com/~aboba/AAA/draft-ietf-pppext-rfc2284bis-02.txt From thardjono@yahoo.com Mon Feb 25 23:54:49 2002 From: thardjono@yahoo.com (Thomas Hardjono) Date: Mon, 25 Feb 2002 18:54:49 -0500 Subject: [eap] RFC 2284bis issues In-Reply-To: <4.3.2.7.2.20020223154608.016e17a8@unitas.cisco.com> References: Message-ID: <5.0.0.25.2.20020225185147.01cbbb00@pop.mail.yahoo.com> Dave, There are many levels of anonymity possible. The easiest way would be for a Pre-Paid card type model, where the identity is tied to the card. I would put anonymity at a lower priority as it tends to complicate the security protocols. thomas ------ At 2/23/2002||03:48 PM, David Halasz wrote: >One concern, of EAP and wireless, is anonymity. I don't have any ideas, of >how to "hide" the user id, in the identity response. But, since it gets >broadcast, in wireless, I have heard concerns. > > Dave H. > >At 10:53 AM 2/20/2002, Bernard Aboba wrote: >>Over the last few months, we've collected quite a few issues for >>resolution in RFC 2284bis. Here are the list of issues that we have >>collected, and how I would propose to resolve them. Comments welcome. >> >>1. IANA considerations. RFC 2284 does not include an IANA considerations >>section, and RFC 2284bis needs one. Some thoughts on what might be in such >>a section: >> >> a. Reservation of some of the Type space for future use. Should this be >> a single EAP method (255) or more of the space (e.g. 127-255)? >> >> b. Statement that IANA should not allocate two Type codes for a single >> EAP method. >> >> c. Statement about reclamation of unused Type allocations. It looks >> like several of the alllocated Type codes have never been used. >> >> d. Allocation of an EAP Type code for "Vendor Specific". I have in >> mind something like what RADIUS does with attribute 26. This could >> take the pressure off the Type space. >> >> e. Statement on allocation of EAP type codes. Should this be on >> request? By expert review? (e.g. by sending mail to the WG) By >> designated expert? Assuming that we have a vendor specific code, >> the criteria might be different, (e.g. a specification and expert >> review might be required). >> >>2. State machine issues. There are a lot of these. RFC 2284 has only a >>short section describing in general terms what the protocol does. There >>is no detailed section describing the protocol exchange in more detail, >>or a formal state machine. These meaans that in many cases there is no >>clear answer to the question "what do you do if you receive packet X when >>you are in the midst of doing Y?" >> >>3. Not allowing data traffic prior to completion of authentication. RFC >>2284 doesn't state specifically that this is required, because it is >>required by PPP -- so it probably seemed obvious and not worth >>mentioning. But now that EAP can be used over a variety of media, this >>has become a point of confusion. >> >>Proposed resolution is to indicate that an authentication conversation, once >>initiated, must complete before data traffic can be sent. >> >>4. EAP Success prior to mutual authentication. RFC 2284 does not >>include a state machine, but it seems to imply that the peer should >>consider authentication complete on receiving an EAP Success. Bill Arbaugh >>has pointed out that a client requiring mutual authentication should not >>consider itself "on the network" until that mutual authentication is >>complete, so this is broken. >> >>For example, if the peer is authenticating via a method supporting >>mutual auth (EAP TLS, EAP SRP, etc.) and an authenticator sends an EAP >>Success in the middle, the recommendation is that the text of RFC 2284bis >>be changed to note that the client SHOULD NOT bring >>up the interface and SHOULD disconnect. Comments? >> >>5. Spoofed EAP Failure. Similarly, RFC 2284 seems to imply that a peer >>always considers themself disconnected when receiving an EAP Failure, >>although it does indicate that "alternative indications of >>success/failure" can be considered. What if an attacker spoofs an EAP >>Failure outside of an authentication conversation? What if other traffic >>is being received at the same time, indicating that the connection is in >>fact up? Can the peer ignore the EAP Failure? >> >>My recommendation is that the text clarify the meaning of "alternative >>indications" with respect to this scenario. I believe that 802.11 and PPP >>both have such alternative indications -- in the case of PPP, we have LCP >>Terminate, in 802.11 we have Disassociate or Deauthenticate. So typically >>the EAP Failure will be followed by an alternative indication, >>particularly if it occurs "out of the blue". I think that the EAP >>indicator can be ignored (sometimes? all the time?) if it is at odds with >>the alternative indication. >> >>6. Authentication of the EAP Success. Bill suggests that an authenticator >>be added to the EAP Success message. My inclination is not to accept this >>suggestion since existing proposals (PEAP, TTLS) already support >>authentication and encryption of the entire EAP conversation. Comments? >> >> >> >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap > > >Dave Halasz >Cisco Systems, Inc. >320 Springside Drive >Akron, OH 44333 > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From henry.haverinen@nokia.com Tue Feb 26 07:27:33 2002 From: henry.haverinen@nokia.com (henry.haverinen@nokia.com) Date: Tue, 26 Feb 2002 09:27:33 +0200 Subject: [eap] RFC 2284bis issues Message-ID: Hello Thomas, Dave, Identity privacy is an important issue especially on public access networks. However, I don't think we need to have a general requirement in RFC2284bis.=20 Anonymity support can be built in the EAP type.=20 Many EAP types, such as EAP/SIM, EAP/AKA, EAP/SRP, PEAP and TTLS,=20 already support anonymity. The first three use unlinkable pseudonym=20 identities. PEAP and TTLS protect the user identity with TLS. Regards, Henry > -----Original Message----- > From: ext Thomas Hardjono [mailto:thardjono@yahoo.com] > Sent: 26 February, 2002 01:55 > To: David Halasz; eap@frascone.com > Subject: Re: [eap] RFC 2284bis issues >=20 >=20 >=20 > Dave, >=20 > There are many levels of anonymity possible. The easiest way > would be for a Pre-Paid card type model, where the identity > is tied to the card. >=20 > I would put anonymity at a lower priority as it tends to complicate > the security protocols. >=20 > thomas > ------ >=20 >=20 >=20 > At 2/23/2002||03:48 PM, David Halasz wrote: > >One concern, of EAP and wireless, is anonymity. I don't have=20 > any ideas, of=20 > >how to "hide" the user id, in the identity response. But,=20 > since it gets=20 > >broadcast, in wireless, I have heard concerns. > > > > Dave H. > > > >At 10:53 AM 2/20/2002, Bernard Aboba wrote: > >>Over the last few months, we've collected quite a few issues for > >>resolution in RFC 2284bis. Here are the list of issues that we have > >>collected, and how I would propose to resolve them.=20 > Comments welcome. > >> > >>1. IANA considerations. RFC 2284 does not include an IANA=20 > considerations > >>section, and RFC 2284bis needs one. Some thoughts on what=20 > might be in such > >>a section: > >> > >> a. Reservation of some of the Type space for future=20 > use. Should this be > >> a single EAP method (255) or more of the space (e.g.=20 > 127-255)? > >> > >> b. Statement that IANA should not allocate two Type=20 > codes for a single > >> EAP method. > >> > >> c. Statement about reclamation of unused Type=20 > allocations. It looks > >> like several of the alllocated Type codes have never=20 > been used. > >> > >> d. Allocation of an EAP Type code for "Vendor=20 > Specific". I have in > >> mind something like what RADIUS does with attribute=20 > 26. This could > >> take the pressure off the Type space. > >> > >> e. Statement on allocation of EAP type codes. Should this be on > >> request? By expert review? (e.g. by sending mail to=20 > the WG) By > >> designated expert? Assuming that we have a vendor=20 > specific code, > >> the criteria might be different, (e.g. a=20 > specification and expert > >> review might be required). > >> > >>2. State machine issues. There are a lot of these. RFC 2284=20 > has only a > >>short section describing in general terms what the protocol=20 > does. There > >>is no detailed section describing the protocol exchange in=20 > more detail, > >>or a formal state machine. These meaans that in many cases=20 > there is no > >>clear answer to the question "what do you do if you receive=20 > packet X when > >>you are in the midst of doing Y?" > >> > >>3. Not allowing data traffic prior to completion of=20 > authentication. RFC > >>2284 doesn't state specifically that this is required, because it is > >>required by PPP -- so it probably seemed obvious and not worth > >>mentioning. But now that EAP can be used over a variety of=20 > media, this > >>has become a point of confusion. > >> > >>Proposed resolution is to indicate that an authentication=20 > conversation, once > >>initiated, must complete before data traffic can be sent. > >> > >>4. EAP Success prior to mutual authentication. RFC 2284 does not > >>include a state machine, but it seems to imply that the peer should > >>consider authentication complete on receiving an EAP=20 > Success. Bill Arbaugh > >>has pointed out that a client requiring mutual=20 > authentication should not > >>consider itself "on the network" until that mutual authentication is > >>complete, so this is broken. > >> > >>For example, if the peer is authenticating via a method supporting > >>mutual auth (EAP TLS, EAP SRP, etc.) and an authenticator=20 > sends an EAP > >>Success in the middle, the recommendation is that the text=20 > of RFC 2284bis > >>be changed to note that the client SHOULD NOT bring > >>up the interface and SHOULD disconnect. Comments? > >> > >>5. Spoofed EAP Failure. Similarly, RFC 2284 seems to imply=20 > that a peer > >>always considers themself disconnected when receiving an=20 > EAP Failure, > >>although it does indicate that "alternative indications of > >>success/failure" can be considered. What if an attacker=20 > spoofs an EAP > >>Failure outside of an authentication conversation? What if=20 > other traffic > >>is being received at the same time, indicating that the=20 > connection is in > >>fact up? Can the peer ignore the EAP Failure? > >> > >>My recommendation is that the text clarify the meaning of=20 > "alternative > >>indications" with respect to this scenario. I believe that=20 > 802.11 and PPP > >>both have such alternative indications -- in the case of=20 > PPP, we have LCP > >>Terminate, in 802.11 we have Disassociate or=20 > Deauthenticate. So typically > >>the EAP Failure will be followed by an alternative indication, > >>particularly if it occurs "out of the blue". I think that the EAP > >>indicator can be ignored (sometimes? all the time?) if it=20 > is at odds with > >>the alternative indication. > >> > >>6. Authentication of the EAP Success. Bill suggests that an=20 > authenticator > >>be added to the EAP Success message. My inclination is not=20 > to accept this > >>suggestion since existing proposals (PEAP, TTLS) already support > >>authentication and encryption of the entire EAP=20 > conversation. Comments? > >> > >> > >> > >>_______________________________________________ > >>eap mailing list > >>eap@frascone.com > >>http://mail.frascone.com/mailman/listinfo/eap > > > > > >Dave Halasz > >Cisco Systems, Inc. > >320 Springside Drive > >Akron, OH 44333 > > > >_______________________________________________ > >eap mailing list > >eap@frascone.com > >http://mail.frascone.com/mailman/listinfo/eap >=20 >=20 > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From aboba@internaut.com Tue Feb 26 14:40:51 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 26 Feb 2002 06:40:51 -0800 (PST) Subject: [eap] EAP methods and key hierarchy Message-ID: Several of the existing EAP method drafts have issues relating to generation of keys and key hierarchy. In general EAP methods cannot make assumptions about the ciphersuites that they will be used with. Some ciphersuites (PPP DESEbis, PPP 3DES, MPPE WEP) require only encryption keys. Other ciphersuites will require both encryption and authentication keys. Some ciphersuites require keys unique in each direction, others do not. As a result, it is a bad idea for EAP methods to include their own ciphersuite-specific key derivation within the method specification. That would require the EAP method to be revised for each ciphersuite. The EAP SRP -03 draft does this, for example. Rather, it makes more sense for the EAP method to supply generic "master session keys", from which ciphersuite-specific keys can subsequently be derived. In this approach, it is "master session keys" that are passed back from the EAP method, not the master key itself. The client and NAS can then derive ciphersuite-specific keys from these master session keys. This enables the AAA server to avoid having to implement ciphersuite-specific code. Instead this code goes on the NAS and client (both of which need to implement the ciphersuite). This insulates the AAA server EAP method from having to change in response to new ciphersuites. It also insulates the NAS from having to have any EAP method-specific knowledge. These issues are discussed in more depth in: http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-01.txt The goal of "master session keys" is to provide sufficient keying material to key *any* ciphersuite. For example, RFC 2716 specifies the derivation of 6 master session keys, each 32B in length. These correspond to Encryption, Authentication and Initialization Vectors, in each direction. RFC 2548 describes how two of these keys (the Encryption keys in each direction) are passed back from the AAA server to the NAS. In deriving master session keys from the master key, it is important that the 6 master session keys maintain cryptographic separation from each other. This is accomplished in RFC 2716 by deriving the master session keys from the master key via the PRF. IKE does something similar in RFC 2409 in its derivation of SKEYID_a, SKEYID_e and SKEYID_d from SKEYID: SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) I would like to suggest that EAP method specifications that derive keys need to describe how the "master session keys" (equivalent to SKEYID_d, a, e given above) are derived from the master key (SKEYID). I would also suggest that discussion of ciphersuite-specific key derivation, if present, be removed and put into a separate document. That way, ciphersuites can have a consistent method for deriving their keys from master session keys provided by *any* EAP method. Unfortunately, there is no "magic bullet" that can be used to provide a key hierarchy for a generic method. The formula above assumes a DH exchange with cookies, for example. It *may* be possible to adapt this for use by SRP, but in other cases, changes to the method may be necessary. In EAP GSS, for example, a nonce exchange had to be added, and even then, it's still not clear that the SKEYID equivalent has sufficient entropy in all cases. The lesson from all this may be that sound key derivation is quite difficult, and that rather than having each EAP method attempt to provide a sound key hierarchy, it may make more sense to use a cryptographic wrapper such as EAP TTLS, PEAP or PIC which both protects the method as well as providing key derivation in a well reviewed manner. Comments? From aboba@internaut.com Wed Feb 27 02:27:31 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 26 Feb 2002 18:27:31 -0800 (PST) Subject: [eap] Some Success and Failure issues Message-ID: RFC 2869 has some issues in handling of EAP that have turned out to be a big headache. RFC 2865 is clear that on the NAS/AP, the access decision is based on whether the client receives an Access Accept or Reject, *not* based on what is inside any EAP-Message attribute. This makes sense, since the NAS/AP is just supposed to act as a passthrough in EAP. However, it makes for some interesting corner conditions, because this implies that the following packets can be sent by the AAA server: a. Access Accept/EAP-Message/EAP-Failure b. Access Reject/EAP-Message/EAP-Success c. Access Accept/EAP-Message/Notification d. Access Reject/EAP-Message/Notification e. Access Accept (no EAP Message) f. Access Reject (no EAP Message) g. Access Accept/EAP-Message/EAP-Failure, Reply-Message h. Access Accept/EAP-Message/EAP-Success, Reply-Message i. Access Reject/EAP-Message/EAP-Failure, Reply-Message j. Access Accept/EAP-Message/EAP-Success, Reply-Message There are probably more corner conditions than this, but my fingers are getting tired :( a. This is a problem because the Accept says "grant access" while the Failure, if passed on to the EAP peer will make it think that authentication has succeeded. If there are alternate indications of success, one might argue that the peer will eventually figure it out. But this isn't true of all media. b. This is a problem because the Reject says "no access" while the EAP-Success passed to the peer makes it think it is successful. If there are alternate indications of Failure on a given media, the peer may eventually figure things out. But this isn't true of all media. c-d. These are an issue since the peer receives a displayable Notification, but no indication of Success/Failure. Alternate indications seem useful here too, but are not always present. e-f. Ditto, except no notification. g-j. These are a problem since Reply-Message is typically translated to an EAP-Notification, so in effect the NAS/AP has *two* EAP messages to send to the peer. Presumably the Notification has to be sent first, since the Success/Failure message terminates the conversation. Note that the Reply-Message doesn't come with an Identifier field, so presumably the NAS/AP has to make one up. But since the Success/Failure already has an Identifier field in it, what is the NAS/AP supposed to do, particularly if the Identifier field is incremented sequentially? The problems are obviously worse, if the Reply-Message is sent in the middle of the conversation, so that a simple Identifier swap wouldn't work. Some thoughts come to mind on possible solutions: 1. "Dr., it hurts when I do this". This approach says: these corner conditions are difficult to handle for media in which there are no alternate failure/success indications, so AAA servers SHOULD NOT send them. To keep NAS implementations clean, a-d should just be "passed through" if received. e-f will result in a timeout for IEEE 802, and g-j will cause confusion on any media so send the Reply-Message, get an ACK and then send the Success/Failure (or other EAP message) in the next round. 2. "Mr. NAS will make it better". This approach says: the NAS should make sure these corner conditions will not occur by "manufacturing" EAP Success packets on receipt of an Access Accept, and "manufacturing" EAP Failure packets on receipt of an Access Reject. This handles cases a-f, but has some undesirable implications for cryptographically protected EAP, as will be discussed below. The "Mr. NAS will make it better" approach comes back to bite when the EAP conversation is cryptographically protected, as it is in EAP TTLS, PEAP, etc. In such cases, it seems preferrable to send the EAP Success or Failure within the encrypted tunnel, and not have to send a cleartext Success or Failure as well. In any case, since EAP Success/Failure packets are not ack'd whether inside a tunnel or not, it's not clear to me how you'd be able to continue the EAP conversation after sending an encrypted Success/Failure packet anyway. But if the "Mr. NAS will make it better" approach is taken, then the NAS will swallow the encrypted Success/Failure packet and replace it with a cleartext Success/Failure. This undermines the concept of protection, which is to be able to authenticate and encrypt each packet in the EAP conversation. From aboba@internaut.com Wed Feb 27 02:35:30 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 26 Feb 2002 18:35:30 -0800 (PST) Subject: [eap] Some Success and Failure issues, take 2 Message-ID: RFC 2869 has some issues in handling of EAP that have turned out to be a big headache. RFC 2865 is clear that on the NAS/AP, the access decision is based on whether the client receives an Access Accept or Reject, *not* based on what is inside any EAP-Message attribute. This makes sense, since the NAS/AP is just supposed to act as a passthrough in EAP. However, it makes for some interesting corner conditions, because this implies that the following packets can be sent by the AAA server: a. Access Accept/EAP-Message/EAP-Failure b. Access Reject/EAP-Message/EAP-Success c. Access Accept/EAP-Message/Notification d. Access Reject/EAP-Message/Notification e. Access Accept (no EAP Message) f. Access Reject (no EAP Message) g. Access Accept/EAP-Message/EAP-Failure, Reply-Message h. Access Accept/EAP-Message/EAP-Success, Reply-Message i. Access Reject/EAP-Message/EAP-Failure, Reply-Message j. Access Accept/EAP-Message/EAP-Success, Reply-Message There are probably more corner conditions than this, but my fingers are getting tired :( a. This is a problem because the Accept says "grant access" while the Failure, if passed on to the EAP peer will make it think that authentication has failed. If there are alternate indications of success, one might argue that the peer will eventually figure it out. But this isn't true of all media (IEEE 802 and 802.11 have no such alternate indications). b. This is a problem because the Reject says "no access" while the EAP-Success passed to the peer makes it think it is successful. If there are alternate indications of Failure on a given media, the peer may eventually figure things out. On IEEE 802.11 a Disassociate from the AP would put things right, as would an LCP-Terminate in PPP. On wired IEEE 802 there is no alternate indication of failure. c-d. These are an issue since the peer receives a displayable Notification, but no indication of Success/Failure. Alternate indications seem useful here too, but are not always present. e-f. Ditto, except no notification. g-j. These are a problem since Reply-Message is typically translated to an EAP-Notification, so in effect the NAS/AP has *two* EAP messages to send to the peer. Presumably the Notification has to be sent first, since the Success/Failure message terminates the conversation. Note that the Reply-Message doesn't come with an Identifier field, so presumably the NAS/AP has to make one up. But since the Success/Failure already has an Identifier field in it, what is the NAS/AP supposed to do, particularly if the Identifier field is incremented sequentially? The problems are obviously worse if the Reply-Message is sent in the middle of the conversation, so that a simple Identifier swap wouldn't work. Some thoughts on possible solutions: 1. "Dr., it hurts when I do this". This approach says: these corner conditions are difficult to handle for media in which there are no alternate failure/success indications, so AAA servers SHOULD NOT send them for those media. To keep NAS implementations clean, a-d should just be "passed through" if received, with predictable ill effects. e-f will result in a timeout for IEEE 802, and g-j will cause confusion on any media. Better to send the Reply-Message, get an ACK and then send the Success/Failure (or other EAP message) in the next round. 2. "Mr. NAS will make it better". This approach says: the NAS should make sure these corner conditions will not occur by "manufacturing" EAP Success packets on receipt of an Access Accept, and "manufacturing" EAP Failure packets on receipt of an Access Reject. This handles cases a-f, but has some undesirable implications for cryptographically protected EAP, as will be discussed below. In such cases, it seems preferrable to send the EAP Success or Failure within the encrypted tunnel, and not have to send a cleartext Success or Failure as well. In any case, since EAP Success/Failure packets are not ack'd whether inside a tunnel or not, it's not clear to me how you'd be able to continue the EAP conversation after sending an encrypted Success/Failure packet anyway. But if the "Mr. NAS will make it better" approach is taken, then the NAS will swallow the encrypted Success/Failure packet and replace it with a cleartext Success/Failure. This undermines the concept of protection, which is to be able to authenticate and encrypt each packet in the EAP conversation. If the logic described above seems clear, then the recommended course is to: a. Write a section for RFC 2869bis warning against the corner conditions and clarifying NAS behavior. b. Clarify the implications of the "Mr. NAS" approach within EAP methods that would like to encrypt EAP Success/Failure. c. Request re-examination of the approach taken in the 802.1X state machine. From jacques_m_caron@yahoo.com Wed Feb 27 07:52:10 2002 From: jacques_m_caron@yahoo.com (Jacques Caron) Date: Wed, 27 Feb 2002 08:52:10 +0100 Subject: [eap] Some Success and Failure issues, take 2 In-Reply-To: Message-ID: <5.1.0.14.0.20020227084739.03a21118@pop.mail.yahoo.com> At 03:35 27/02/2002, Bernard Aboba wrote: >If the logic described above seems clear, then the recommended course is >to: > >a. Write a section for RFC 2869bis warning against the corner conditions >and clarifying NAS behavior. I think the easiest is simply to say that Accept/Reject messages SHOULD NOT contain EAP-Messages (or Reply-Messages either, if there was an EAP conversation at any point), and that NASes should send "canned" ones. Note that this "canned" version would only be needed for EAPv1 clients, EAPv2 clients would just ignore them. >b. Clarify the implications of the "Mr. NAS" approach within EAP >methods that would like to encrypt EAP Success/Failure. And use either of the alternatives (EAPv2-in-EAPv1 or EAP-Request/Success) proposed. >c. Request re-examination of the approach taken in the 802.1X state >machine. I'm not sure we need to break that one. If we move the "real" success/failure notification somewhere else, the "canned" notification is just needed for EAPv1 clients, and redundant for EAPv2 clients. Might just want to make sure that NASes are able to detect EAPv2 clients and know they don't need to send the "canned" message for those, but this is more cosmetic that anything. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jacques_m_caron@yahoo.com Wed Feb 27 07:47:06 2002 From: jacques_m_caron@yahoo.com (Jacques Caron) Date: Wed, 27 Feb 2002 08:47:06 +0100 Subject: [eap] Some Success and Failure issues In-Reply-To: Message-ID: <5.1.0.14.0.20020227083355.038390e8@pop.mail.yahoo.com> At 03:27 27/02/2002, Bernard Aboba wrote: >RFC 2869 has some issues in handling of EAP that have turned out to be a >big headache. > >RFC 2865 is clear that on the NAS/AP, the access decision is based on >whether the client receives an Access Accept or Reject, *not* based on >what is inside any EAP-Message attribute. This makes sense, since the >NAS/AP is just supposed to act as a passthrough in EAP. > >However, it makes for some interesting corner conditions, because this >implies that the following packets can be sent by the AAA server: > > a. Access Accept/EAP-Message/EAP-Failure > b. Access Reject/EAP-Message/EAP-Success > c. Access Accept/EAP-Message/Notification > d. Access Reject/EAP-Message/Notification > e. Access Accept (no EAP Message) > f. Access Reject (no EAP Message) > g. Access Accept/EAP-Message/EAP-Failure, Reply-Message > h. Access Accept/EAP-Message/EAP-Success, Reply-Message > i. Access Reject/EAP-Message/EAP-Failure, Reply-Message > j. Access Accept/EAP-Message/EAP-Success, Reply-Message There are also the Access-Challenge/EAP-Message/EAP-Failure and Access-Challenge/EAP-Message/EAP-Success which are possibly quite interesting. >a. This is a problem because the Accept says "grant access" while the >Failure, if passed on to the EAP peer will make it think that >authentication has succeeded. If there are alternate indications of >success, one might argue that the peer will eventually figure it >out. But this isn't true of all media. And some peers might have already disconnected upon receiving the failure message. >1. "Dr., it hurts when I do this". This approach says: these corner >conditions are difficult to handle for media in which there are no >alternate failure/success indications, so AAA servers SHOULD NOT send >them. To keep NAS implementations clean, a-d should just be "passed >through" if received. e-f will result in a timeout for IEEE 802, and g-j >will cause confusion on any media so send the Reply-Message, get an ACK >and then send the Success/Failure (or other EAP message) in the next >round. One problem is that NASes need to understand a bit of EAP to know that certain messages need to be acked and others not, based on the EAP type, and not on the RADIUS type. So the NAS is not transparent to EAP anymore. >2. "Mr. NAS will make it better". This approach says: the NAS should make >sure these corner conditions will not occur by "manufacturing" EAP >Success packets on receipt of an Access Accept, and "manufacturing" EAP >Failure packets on receipt of an Access Reject. This handles cases a-f, >but has some undesirable implications for cryptographically protected EAP, >as will be discussed below. As far as I understand it, this approach is the one used by 802.1X, which says the NAS (er, switch/AP) is to send "canned" success or failure messages upon reception of AAA Access-Accept or -Reject messages. >The "Mr. NAS will make it better" approach comes back to bite when the EAP >conversation is cryptographically protected, as it is in EAP TTLS, PEAP, >etc. Given the absence of any data allowed in failure or success messages (in theory, probably not in practice), I don't quite see how that packet can be cryptographically protected anyway (unless it is encapsulated into something else). >In such cases, it seems preferrable to send the EAP Success or Failure >within the encrypted tunnel, and not have to send a cleartext Success or >Failure as well. > >In any case, since EAP Success/Failure packets are not ack'd whether >inside a tunnel or not, it's not clear to me how you'd be able to continue >the EAP conversation after sending an encrypted Success/Failure packet >anyway. If we go for either the "Success is a new method" or "EAPv2 is encapsulated in a new method" approaches, we can decide that those success/failure messages (EAPv2 version) are ACK'd, protected, and whatever we want. Then the extra "regular" success message is just there for backward compatibility (of the NAS). >But if the "Mr. NAS will make it better" approach is taken, then the NAS >will swallow the encrypted Success/Failure packet and replace it with a >cleartext Success/Failure. This undermines the concept of protection, >which is to be able to authenticate and encrypt each packet in the EAP >conversation. Which brings us back to the alternatives I described in my mail from the other day, and which I have to put in draft format asap :-/ Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From sjosefsson@rsasecurity.com Wed Feb 27 09:51:07 2002 From: sjosefsson@rsasecurity.com (Simon Josefsson) Date: Wed, 27 Feb 2002 10:51:07 +0100 Subject: [eap] Fwd: I-D ACTION:draft-josefsson-eap-securid-01.txt Message-ID: --=-=-= I will be requesting that the SecurID EAP mechanism as defined in the draft announced below be published as an RFC. If the EAP expertise in these groups would take a look at it, I would appreciate it. -- Simon Josefsson RSA Security --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit Path: news.dynas.se!m2news!nobody Newsgroups: local.ietf-announce-list Approved: postmaster@dynas.se X-Sender: X-Received: urp.dynas.se!spirit.dynas.se!sdtihq24.securid.com!ebola.securitydynamics.com!dsf.dynas.se!mimir.rsasecurity.com!loki.ietf.org!loki.ietf.org!ietf.org Message-ID: <200202261204.HAA24395@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-josefsson-eap-securid-01.txt Date: Tue, 26 Feb 2002 12:04:10 GMT Lines: 85 Xref: news.dynas.se local.ietf-announce-list:16069 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The EAP SecurID(r) Mechanism Author(s) : S. Josefsson Filename : draft-josefsson-eap-securid-01.txt Pages : 10 Date : 25-Feb-02 This document describe a EAP mechanism based on SecurID. SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security, which is used for end-user authentication. The SecurID EAP mechanism can be used to provide authentication in protocols utilizing EAP, such as PPP, IEEE 802.11 Wireless LAN and possibly Bluetooth in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-josefsson-eap-securid-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-josefsson-eap-securid-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-josefsson-eap-securid-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225143020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-josefsson-eap-securid-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-josefsson-eap-securid-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225143020.I-D@ietf.org> --OtherAccess-- --NextPart-- --=-=-=-- From aboba@internaut.com Wed Feb 27 11:09:06 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Feb 2002 03:09:06 -0800 (PST) Subject: [eap] Some Success and Failure issues In-Reply-To: <5.1.0.14.0.20020227083355.038390e8@pop.mail.yahoo.com> Message-ID: > There are also the Access-Challenge/EAP-Message/EAP-Failure and > Access-Challenge/EAP-Message/EAP-Success which are possibly quite interesting. Yes, I forgot those :( Since EAP-Success/Failure are terminal messages, the peer will not reply, and therefore the RADIUS server will not receive another Access-Request to continue the EAP conversation. So the peer thinks it is successful/unsuccessful and yet the NAS has never been informed of a result. > And some peers might have already disconnected upon receiving the failure > message. Yup. In the EAP implementation survey, we didn't get much response for "alternate indications". I suspect that most peers will take the Failure as final and not consider alternate indications of success at all. > One problem is that NASes need to understand a bit of EAP to know that > certain messages need to be acked and others not, based on the EAP type, > and not on the RADIUS type. So the NAS is not transparent to EAP anymore. Can you elaborate? A NAS can just execute a "pass through" in all these corner cases, correct? This wreaks some havoc, but it's havoc that was caused by the AAA server, so presumably if "Dr., it hurts when I do this" then the answer can be "don't do that". > As far as I understand it, this approach is the one used by 802.1X, which > says the NAS (er, switch/AP) is to send "canned" success or failure > messages upon reception of AAA Access-Accept or -Reject messages. Yes. But if we decide that another approach makes more sense, there may still be time to get it changed. > Given the absence of any data allowed in failure or success messages (in > theory, probably not in practice), I don't quite see how that packet can be > cryptographically protected anyway (unless it is encapsulated into > something else). Right. It can be sent down an encrypted TLS tunnel (PEAP, TTLS). But there is no room for a MIC at the end.